Should example ECMAScript code use modules? (Related to Ctyoscape.js code for drawing graphs)

In creating some Cytoscape.js code that will be posted in Generating Cytoscape.js graphs with SWI-Prolog there is a decision to be made about using ECMAScript (think JavaScript) modules or not.

Currently the prototype code does not use modules, but it could.

Since the code is meant as example code for others, would the code be of more benefit using modules or not?

My personal view is that the code is easier to understand without out modules, but real-world ECMAScript should use modules.

I can also make versions to demonstrate both.

Feedback desired.

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 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


As the data for my need originates with Prolog, predicate_property/2 and import_module/2, the data is converted to JSON and the boilerplate JavaScript code that knows how to use the JSON to render the graph is used.

With my goal, the graphs are meant to only be use used via a browser, thus the JavaScript, and have the ability to move the nodes, thus the change from GraphViz to Cytoscape.js.

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.

My take on the use of JSON is that many of the properties for defining a graph with Cytoscape.js can be passed as JSON - the elements (nodes and edges), the style (CSS), and the layout. At present I have not found a need for more than some simple boilerplate HTML with JavaScript to host the Cytoscape.js code and define the elements, style and layout as JSON.

I first started using JavaScript when it was still beta in the 1990s and then used it for a few years in production. Then never really used it for about 20 years and now coming back to it have to learn about all of the extensions and the best way to use them. JavaScript modules was one of those extensions.

In my sample code I was passing the data as JSON but wrapped in a JavaScript variable because at the time I wanted the web pages to run on a local machine without the need for a web server. In further reading it seems that to use modules the code has to be served up via a server, (currently using node.js because of its simplicity to use), but still need to understand this more before I would say that is a fact.

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.