Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Who needs Graphviz when you can build it yourself?

spidermonkey.dev

Post reply on HN
Print view View original

61–70 of 114 posts

Re: Who needs Graphviz when you can build it yourself?

#61

Post by realityfactchex »

The greatest thing about Graphviz is indeed the dot language. A nice thing about using dot is that the graph definition is *portable among all applications that support dot*.

Dot is such a simple and readable format (particularly if using the basic features). Thus, it can make a ton of sense to define graphs in strict dot, even if you will be rendering with another tool than Graphviz.

These days, there are other popular options, too -- Mermaid, etc, as TFA indicates. Nonetheless, Graphviz/dot will remain for the long haul, IMO, because dot is so, so good.

So, you need Graphviz for its syntax definitions primarily, and because it is a standard that could be recognized/run anywhere.

Re: Who needs Graphviz when you can build it yourself?

#62

Post by tauchunfall »

nirava wrote: post #9

anyone working on this space easily gets a +1! I have struggled with code to diagram tools for a while [mermaid and graphviz], and usually return to figjam when I need the readabilty and aesthetics. graph-viz is MASSIVE and a binary. mermaid requires the browser's svg rendering system to work. I just need something that builds diagrams from description easily ...

>graph-viz is MASSIVE and a binary. mermaid requires the browser's svg rendering system to work.

I succeeded to use resvg-js [1] with dagre/graphlib [2] to render graphs. resvg-js uses a 4 MB node library to render SVGs. dagre is used by mermaid for graph layout (for some of the diagram types). if you disable loading system fonts in resvg-js it just takes milliseconds to render the SVG.

I know that mermaid is well-known and very useful, but I don't like the code quality (especially consistency) and the bloat of dependencies. Last time I went through the code I assessed it requires significant refactorings to make it work with resvg-js, i.e. server-side graph layout and rendering.

There is also nomnoml [1], which is so great, it should deserve at least the same amount of attention as mermaid. the nomnoml codebase is a joy to read. the author even converted the dagre/graphlib codebase to typescript [4].

[1] https://github.com/thx/resvg-js [2] https://github.com/dagrejs/dagre [3] https://github.com/skanaar/nomnoml [4] https://github.com/skanaar/graphre

---

Edit: One of the refactorings to make mermaid work with resvg-js is related to measuring svg text width. It's needed to determine the width of the graph node boxes. mermaid needs to be able to also use `resvg.getBBox()` to make it work with server-side rendering.

Re: Who needs Graphviz when you can build it yourself?

#63

Post by dllu »

For those who are interested, the Will Evans course on graph drawing [1] covers a lot of cool graph drawing algorithms. Graph drawing is very interesting and many applications get it wrong. I once contributed [2] some small bugfixes to the Dot lexer for the Open Graph Drawing Framework, which has fast implementations of some amazing graph drawing algorithms, and my experience is that the OGDF draws graphs vastly better than the various algorithms in GraphViz (fewer crossings, faster, etc).

[1] https://www.cs.ubc.ca/~will/536E/

[2] https://github.com/ogdf/ogdf/pulls?q=is%3Apr%20author%3Adllu...

Re: Who needs Graphviz when you can build it yourself?

#64

Post by RationPhantoms »

hawk_ wrote: post #53
phplovesong wrote: post #39

D2 "should" handle most cases OP was annoyed about. Its written in Go, so its really fast too. I never had to wait for it to finish, but that said i never produced huge diagrams that i could imagine a compiler would.

When should one use D2 vs graphviz?

I stumbled upon this link that should help: https://text-to-diagram.com/

Re: Who needs Graphviz when you can build it yourself?

#65

Post by zvr »

embedding-shape wrote: post #44
fulafel wrote: post #25

Earlier quoted context omitted.

It's a bit confusing. Dot apparently is both the language name [1] for the Graphviz syntax, and one of the layout engines [2], possibly with different capitalizations. [1] https://graphviz.org/doc/info/lang.html [2] https://graphviz.org/docs/layouts/dot/

I've used GraphViz/Dot (I call `dot` in my terminal, but the package to install is `graphviz`) for probably two decades at this point, and what is what is still not clear to me, kind of like the whole imagemagick/convert thing which is similar, at least to someone on the outside. Not sure why they can't come up with new names, use those, then when you invoke the program in the terminal, call the binary the same thing…

> Not sure why they can't ...

This is exactly what they have done. You can call "dot" and it runs the dot layout engine, but you can also run "neato", "sfdp" or any other -- with the same input.

The "graphviz" package installs all these executables.

Re: Who needs Graphviz when you can build it yourself?

#66

Post by anotheryou »

looking at the spagetti: neither is readable, but I'd say wonky graphviz wins because you have a chance following some of the lines.

I love how bitwig solved it: gravity, color coding, stiffness, directionality (ins on the left, outs on the right).

https://polarity.me/img/bitwig-course-02-whatisthegrid-3.jpg

Re: Who needs Graphviz when you can build it yourself?

#67

Post by housel »

HarHarVeryFunny wrote: post #29
frumiousirc wrote: post #22

Looks nice. Two things on my wish list: 1. Make graphs from Clang's AST. 2. Invent some style flourish to help follow an edge that becomes part of a bundle of many edges.

If you can get the AST output into a text file, then it should be easy to convert it to the DOT input that GraphViz takes, which at heart is just a list of node connections (A -> B).

"clang -Xclang -ast-dump=json" will take you partway there.

Re: Who needs Graphviz when you can build it yourself?

#68

Post by bvisness »

realityfactchex wrote: post #61

The greatest thing about Graphviz is indeed the dot language. A nice thing about using dot is that the graph definition is *portable among all applications that support dot*. Dot is such a simple and readable format (particularly if using the basic features). Thus, it can make a ton of sense to define graphs in strict dot, even if you will be rendering with another tool than Graphviz. These days, there are other popu…

"I love the status quo! My favorite thing about it is that it is the status quo."

Re: Who needs Graphviz when you can build it yourself?

#69

Post by OisinMoran »

This is great! There are surprisingly few tools that actually output anything nice when it feels like such a doable problem.

One small improvement they could probably make is the ability to rearrange outputs at the bottom to reduce crossings. Just from the very first example it seems flipping the 0 and 1 outputs on the bottom graph would be nicer.

For anyone else interested in this general area, Steve Ruiz and Lu Wilson from tldraw often tweet a lot of fun nitty gritty edge cases in graph drawing.

Re: Who needs Graphviz when you can build it yourself?

#70

Post by dfabulich »

le-mark wrote: post #24

This is a great write up and thank you to the author! Just a note that graphviz dot is not purely Sugiyama’s, there is a paper on the site that details the actual implementation. Also judging from the final two images (dot vs iongraph for the same large graph) it’s clear that dot is optimized for minimal area where iongraph does not. That’s the trade off. The author claims one is more easy to navigate than the other,…

Visualizing large graphs is a "tarpit idea," one that initially seems appealing but never succeeds in practice.

Fundamentally, the problem is that visual aids can only really represent a few dozen things before they become as complicated as the thing you were trying to understand in the first place.

And when analyzing messy node diagrams, it’s not just the nodes we’re trying to visualize, but the lines connecting the nodes (the “edges”). We can only visualize a few dozen of those, and that typically means we can visualize only a handful of nodes at a time.

Visualization only works in trivial examples where you don’t need it; it fails in complex environments where you need it the most.

Post reply on HN