All these graph layout algorithms should ideally be run on the backend. Most of these js libraries are missing the point in trying to run layout in Javascript on the frontend. If you have a huge graph, you can't view all of it at once anyways and you're viewing a subset of it any 1 moment.
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.
We find that is ok if you build it right for the bulk of business settings. The intuition is that if you can do youtube, streaming layout updates should not be a problem.
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.
Most humans can't make much sense of anything more than 50-100 node graph at a time. At a graph size of containing 50-100 nodes or lesser which is a rather small graph, huge variety of graph algorithms are not very helpful.
These libraries are good to experiment with each layout algorithm but ultimately a graph analysis most of the time involves exploration and querying, like a repl and making sense of that. Most frontend js libraries will not be helpful in doing that.
It's a surprise that there is no robust backend library that does graph layout.
You can run d3 on the backend with node. It shouldn't be too difficult using it with a layout to constrain the potential visualization to a more comprehensible data set.
There's even a d3-node package available to generate a static SVG or png.
[edit]
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.
Graphviz can easily be used as a backend layout system to output SVG or PNG. It's just not very interactive; you can do mouseover annotations but you can't drag nodes around.
Yep, that's how we architected Graphistry, and then some. GPUs frontend for rendering, GPUs backend for layout, analytics, etc.
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.
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.