I'm one of the lead developers of GoJS [1] (#4 on the page) and would be happy to answer any questions.
A lot of our library additions are from fulfilling customer requests and needs (see the change log from 1.4 to 1.5 to get an idea[2]), so if anyone finds functionality particularly lacking in the diagramming libraries they use, I'd love to hear about it.
dagre is a layout library which implements graphviz in javascript, and renders it in d3. d3's force-directed layout is great for demos, but I've never found it good enough when trying to represent real data.
Have used Highcharts, MxGraph and Dagre-d3 in work projects and I should say with more support (active development) to Dagre-d3 it would be way too good. While considering for one of our projects (https://github.com/caskdata/cdap/tree/develop/cdap-ui) our first choice was dagre-d3 but since the github page for it clearly says No Active Development going on, there was a bit of hesitation. Turned out to be pretty good! :)
OP can definitely consider taking adding Dagre-d3 to that list, its free and it figures out the space problem (how to space out your DAG) based on the input. We don't have to figure out where to draw which node and how to draw the edges!
If active development is a concern, you may want to consider ZingChart (http://www.zingchart.com )
They release new builds on a quarterly basis. The support is pretty responsive, too.
Thanks for the heads up. I will have to check out dagre-d3. In the past we have used visjs. That being said, we have never really had much success with it as the networks, above a trivial size, never seem to settle in. i.e. the nodes keep bouncing around (and at visually sub-optimal edge lengths).
Seeing this, thought I'd share a prototype of mine. For the minecrafters out there who use worldedit: here's a javascript library prototype that lets you draw minecraft scenes. Demo is a doodling of a skeleton grinder: http://babylon.pp19dd.com/ that I made the other year.
Code example goes like something this:
// var scene = (some babylon js stuff here, - sorry, messy)
var WE = new Worldedit(scene);
WE
.select([-4, 0, -4])
.set("cobblestone")
.move([0, 2, 0])
.select([0, -5, 7], [-1, -1, 6])
.set("dirt")
Suppose I should consider finishing this library, namely porting it from BabylonJS to three.js, finishing worledit functions, etc but thought it was a fun exploration of babylonjs and raw files from minecraft (the textures are just extracted from the minecraft jar file).
I'd prefer it if these libraries were split into a non-graphical and a graphical part. Basic functions such as computing a layout from scratch, or computing an updated layout (rerouting or adding an edge), etc., belong in the first library. And UI stuff belongs in the second library. This way, users can decide if they like the user-interaction, and write their own if necessary.
d3 is pretty much of the first type, it binds data with DOM elements. The DOM elements can be of various types. With your proposal, what we miss is something akin to Bootstrap, but for data visualizations, styling SVG elements for instance.
I have used FLOT, it's one of the best open source Canvas based chart JS libraries. It is based on JQuery, that is the only downside (at least for my purpose). http://www.flotcharts.org/ From my experience it was more lightweight than D3 and offered compareable results to highcharts library.
I've been studying some frameworks and trying to make a visual tool for creating diagrams and mind maps.
I'll try GoJs (I would prefer if it uses SVG).
interesting things!
visual languages for the web are increasingly important, I discussed some viewpoints on this with d3js and processingjs here: http://thinkingonthinking.com/visual-languages/
d3 is sure useful and I have used it for displays of custom seismic data, but I wouldn't use it for all situations.
Furthermore, To base a decision on which to use soley by star count would be ignoring all the more advanced and use case specific features the other libraries bring.
A lot of our library additions are from fulfilling customer requests and needs (see the change log from 1.4 to 1.5 to get an idea[2]), so if anyone finds functionality particularly lacking in the diagramming libraries they use, I'd love to hear about it.
[1] http://gojs.net/latest/index.html
[2] http://gojs.net/alpha/doc/changelog.html