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

81–90 of 114 posts

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

#81

Post by wswope »

Someone wrote: post #60
wswope wrote: post #54

Earlier quoted context omitted.

I can see how you got that impression and don’t fault you for it in the slightest, but that’s not accurate. It’s not the language name for all Graphviz syntax; it’s only the syntax for renderings made with the dot engine. Each engine has its own DSL, basically.

> Each engine has its own DSL, basically. Does it? There are slightly different DSLs for directed and non-directed graphs, some features only work with some output formats, but AFAIK, everything in the DSL in independent of the layout engine.

Looking at the docs again with fresh eyes, I think you and fulafel are on the money.

The specific engine syntaxes are by & large mutually incompatible, but DOT does seem to be the label used for the overall lang as well as the dot-engine-compatible dialect.

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

#82

Post by j2kun »

ctenb wrote: post #2

This is a cool example of how specializing a generic algorithm to a specific subspace can yield much better results. This is quite often the case in my experience, but we often don't bother utilizing properties that are specific to our problem space, and just apply the generic algorithm out of convenience (and because it is often good enough)

Came here to say this, but with caveats. The particular domain has extra properties that allow their "stupider" algorithm to work better in their case. But a general graph drawing system has to deal with the inherent generality of the domain.

Usually there is a good middle ground: heuristic analysis of the input to see if it fits well with special-case "stupid and fast" algorithms, and sophisticated optimizations that are the fallback and work for everything and come with guarantees.

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

#84

Post by tunesmith »

Wonder how it compares with elkjs? I had written a few things that wrapped dot, which felt clunky, but have since had good success writing react components that use elkjs. Elkjs has a stupid amount of configuration options, some of which aren't very clearly documented, but I've been able to get decent output for use cases like argument mapping and choose-your-own-adventure maps.

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

#85

Post by kylereeve »

j2kun wrote: post #82
ctenb wrote: post #2

This is a cool example of how specializing a generic algorithm to a specific subspace can yield much better results. This is quite often the case in my experience, but we often don't bother utilizing properties that are specific to our problem space, and just apply the generic algorithm out of convenience (and because it is often good enough)

Came here to say this, but with caveats. The particular domain has extra properties that allow their "stupider" algorithm to work better in their case. But a general graph drawing system has to deal with the inherent generality of the domain. Usually there is a good middle ground: heuristic analysis of the input to see if it fits well with special-case "stupid and fast" algorithms, and sophisticated optimizations tha…

That's how all application-specific specializations work though, take advantage of domain properties that make you need a less generic algorithm.

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

#86

Post by kiitos »

this article is confusing, it appears to conflate graphviz (an umbrella term/tool that collects a set of layout engines and output formats) with both dot (a specific layout engine) and sstangl/iongraph (a specific tool that transforms a particular SSA/AST input format to a specific dot output format)

it also seems to conflate how a DAG is expressed, with how that expression is rendered

strange

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

#87

Post by kiitos »

jerf wrote: post #47
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,…

"Ultimately I found that visualizing large graphs is rarely helpful in practice; they can certainly look nice for some well defined graphs, but I rarely saw well defined graphs in the wild." Yes, I'm with you: https://jerf.org/iri/post/2025/on_layers_and_boxes_and_lines... Since writing that I'm finding my frustration at the inability of diagrams to link out or be linked into is growing. In hindsight it seems a super…

> There are three basic types of “boxes and lines” (as I derisively refer to them) diagrams:

the point of a boxes-and-lines diagram is to express relationships between components at a single layer/level of abstraction

the best metric for the "quality" of a diagram isn't the number of boxes, rather it's the number of edge-crossings, where >0 is a pretty reliable signal that either (a) the diagram is trying to show too much, or (b) the architecture is sub-optimal

any non-trivial system will always require multiple boxes-and-lines diagrams to be accurately described, one per abstraction-layer

and not really sure that linking between diagram and code is a core requirement, diagrams will generally include identifiers that are unambiguously grep-able, i guess...

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

#88

Post by taeric »

dfabulich wrote: post #70
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…

I would go further. The fundamental problem is the idea that there is a fundamentally correct representation of something. This actually goes further than even the visualization of the graph. Symbolic representations have the same trap.

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

#89

Post by taeric »

bvisness wrote: post #34
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,…

I agree that we haven’t gained much yet from looking at large graphs. Usually we can reduce any problem of interest to something small. Still, Graphviz produces very ugly results even for small graphs, whereas this is where iongraph shines. To be clear, what I think makes the latter graph more readable is particularly that the wires are easier to follow. Yes, it’s subjective, but backed up by my own personal experien…

I confess I found the graphs GraphViz made for me in https://taeric.github.io/many_sums.html oddly pretty. :D

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

#90

Post by nirava »

a_t48 wrote: post #11
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 ...

I used mermaid for https://basisrobotics.tech/2024/11/24/basis-robot-02-softwar... (autogenerated) and it worked out pretty well, but notably I wasn't trying to handle loops. There have to be mermaid to png renderers out there. Beyond that, I view svg/html output as a huge advantage - I can restyle it and it's copyable.

Mermaid is great in its niche, and being web-first has been its greatest asset. But that is also a great frustration because anytime I try to do anything out of the web-world with mermaid, it becomes a massive PITA thanks to needing a full headless browser.

I used graphviz to generate graphs for code structures, and that worked out great.

https://niravko.com/blog/visualize-cpp-data-structures#resul...

Post reply on HN