Sorry I’m unqualified to answer your question… never used JS modules, I think they will have some usefulness (of course), but right now what seems important to me it’s how much of the code of an interactive graph we can keep in Prolog. In particular, we should be able to react to events and modify parts of the graph, without writing JS.
Now, I really like JS, one of the better languages, I think, but when programming in Prolog, should be handled just as glue, with a minimum syntax impedance - and JSON should be enough for this.
What could be a simple way to extend html_write for seamless bidirectional integration ?
(I know, should never answer a question with a question…)
Some time ago, I took briefly a look to Jasonette, contrasted to React Native (via Expo.io). React take a ‘rewrite’ approach, while Jasonette an interpretive one. Guess we are in position to make a choice now…
To better understand the meaning of that I guess it would be better if the goal of what the code is meant to do and how it is to do it is known. I suspect your goal and mine are different.
For my purposes the current goal is to create graphs for better understanding of some data, (currently Prolog module relationships), but for some complex graphs the layout algorithms of GrahpViz are not laying out the graphs in a means that is easy to comprehend, as such generating the graphs with Cytoscape.js gives me the option to move the nodes as necessary.
I am currently looking at how to use several of the layout algorithms for Cytoscape.js (see demos) and am starting to consider that some parts should use one layout algorithm and parts another. Another option worthy of study is bubblesets
So my goal is not to use Prolog to draw the graphs or to manipulate the graphs. However using a Prolog database for the data is one of the easiest and most intuitive means of representing the data I know. Also Prologs ability to select and transform data in preparation for display is also hard to match.
At present I am not even considering the use of Prolog to generate the pages, the pages will just be boilerplate code as was done in the prototype code.
Thanks. I will take a look at these but don’t think I would need such.