I really wish the computation would be offloaded to web workers though. Right now it completely freezes the browser when updating very large graphs (above around 1.5k edges and .5k nodes in my experience).
Eg of a much larger graph after 15min trying to stabilize: https://i.imgur.com/f06n9Ic.jpg
I wonder if some of the variety you're seeing comes from different approaches people take to keeping the problem tractable.
- In a hierarchical layout, supporting custom layering and sequencing to ensure that certain nodes will appear in a given layer, or that within a layer the order of nodes is fixed. This is fairly easy to add, since layering and sequencing have to be done anyway.
- Support for grouping, where nodes can be enclosed in a box, which requires the layout to keep them close to each other and also ensure that no other nodes protrude in that box (and preferably prevent edges from passing through as well).
- Customizability of edge routes, where you could, for example, say that edges have to leave a node on the bottom and enter from the top, instead of having that property implicit due to the layout direction and choosing to pur ports in the center of nodes.
- Some applications don't concern themselves with interactivity and thus don't care about algorithms that, for example, would ensure that after incrementally changing the graph, the resulting image would still look similar to the old one (when adding a node to a tree you don't want the order of subtrees higher up to change completely just because of that change).
- Any features you add may interact with each other and further complicate the implementation to ensure that each one still works (and results in acceptable runtime).
Generally, due to the breadth of features that can be supported/implemented in a given implementation, you sometimes have to study the documentation closely. If all you care about is getting a nice result with default settings, then that's often easy to test, though. But the nature of graph drawing is sadly that the most visible effect of an algorithm is what you see.
Looking at the actual characters risks having different alignment for different nodes, which would look bad as well.
We have DAGs that cause graphviz to choke (tens of minutes running time, if it ever finishes). So far I'm not aware of anything that scales better than graphviz with similar results to the dot layout engine.
This approach can be combined with lazy loading data as you expand a node as another performance enhancement.
With some effort you can add this interactivity to vis.js or d3. I have previously used a commercial product called KeyLines  which has this feature, uses WebGL to run the layout in gpu.
- Nodes are rectangles that have width and height (they'll later be rendered as HTML divs) and should not overlap
- If possible, edges should not overlap with nodes / cross any node's boundaries
I really just need the positions as I would like to have precise control over how and when things are rendered. So far, I've been using WebCola for this and while it works ok, it tends to become quite slow in some situations.
So, yes, I see that it can be useful.
When you do this, you're guaranteed that the resulting graph is acyclic.
Everything else tends to be force-directed which just doesn't work very well.
So the ideal library should be running the layout on the backend and the frontend should be plain dummy, simply showing each graph node at the position co-ordinate sent from the back-end.
I would agree that building a distributed architecture that achieves this is a distraction for most solutions- oriented teams. Before you get to the benefits, most/all teams would drown from the complexity.
Client side interactivity without network delay is a valid use case for these libs. Client side encrypted data also.
It's a surprise that there is no robust backend library that does graph layout.
There's even a d3-node package available to generate a static SVG or png.
Additionally, grouping or binning the data may be something to consider when dealing with a visualization with 100+ nodes. Never tried that with DAG datasets, not sure how that would work, but it's interesting to think about.
Also agreed on subsets. About 1-10M nodes can still work in the frontend (and we're pushing upper end of that). But around 100K-1M nodes, more about seamless & interactive abstractions... and reinforces why integration w/ smart backend matters.