Drawing Libraries for Diagramming: A Survey of Tools and Trade-offs

When building a diagramming tool, the choice of underlying drawing library becomes a foundational architectural decision that influences everything from developer experience to output quality. The Lobsters community recently surfaced a fascinating collection of tools spanning decades of computing, each embodying different philosophies about abstraction, control, and the relationship between code and visual output.

The most immediately practical recommendation comes from jjasghar, who champions Mermaid.js as a modern workhorse for diagramming. This library has gained significant traction in developer tooling, particularly within GitHub and Obsidian ecosystems, where its text-based syntax allows diagrams to be version-controlled alongside code. The appeal lies in its balance of simplicity and capability—users can create clean box-and-line diagrams without wrestling with low-level graphics APIs, and the output remains readable enough for documentation purposes. For someone building a narrow-scope diagramming tool, Mermaid represents the current industry standard for text-to-diagram conversion, offering a proven model for syntax design and rendering.

For those willing to embrace older paradigms, romforth points to PIC, a domain-specific language that has persisted through generations of UNIX systems. PIC operates within the troff/groff ecosystem, making it remarkably portable across UNIX-like systems, including Windows via WSL. Its longevity speaks to a particular philosophy: that diagramming should be expressible as a textual language with precise, deterministic output. The tool's resilience suggests that well-designed DSLs can outlive the platforms they were born on, though modern developers might find its syntax and tooling integration challenging compared to contemporary alternatives.

On the JavaScript front, abetusk offers a nuanced perspective on two.js, a 2D drawing API that sits between low-level canvas manipulation and high-level frameworks. Two.js provides primitives for drawing shapes and lines while maintaining SVG export capabilities—a crucial requirement for many diagramming applications. The library's "warts," as abetusk notes, reflect a common tension in graphics programming: the trade-off between convenience and control. Two.js doesn't impose a heavy mental model, allowing developers to build their own abstractions on top, but this freedom comes at the cost of writing more boilerplate code. For interactive 2D work, abetusk mentions Pixi.js as a more robust alternative, though it sacrifices SVG export—a reminder that specialized tools often optimize for specific use cases at the expense of others.

Perhaps most intriguing is apg's mention of pict, a Haskell library that embodies a functional approach to diagram composition. Pict's higher-order operations—like (beside x y) for horizontal arrangement—represent a fundamentally different mental model from imperative drawing libraries. This compositional approach aligns naturally with diagramming tools where relationships between elements matter as much as the elements themselves. For someone building a layouting tool, pict's philosophy might offer valuable inspiration: treat diagrams as composable values rather than sequences of drawing commands.

The diversity of these recommendations reveals deeper patterns in how we think about visual representation. Mermaid and PIC represent the DSL approach, where a specialized language describes diagrams declaratively. Two.js and Pixi.js embody the library approach, providing building blocks for programmatic creation. Pict suggests a third path: treating diagrams as algebraic structures that can be transformed and combined.

For the original poster's narrow-scope diagramming tool, these choices suggest several architectural considerations. If the priority is ease of use and broad compatibility, Mermaid's model offers a proven path. If control over rendering and portability across decades matters, PIC's longevity provides reassurance. If the tool needs interactive capabilities or specific performance characteristics, JavaScript libraries like Two.js or Pixi.js become necessary, though they require accepting certain constraints around SVG export or mental model complexity.

The conversation also hints at an unspoken challenge: the gap between drawing primitives and diagram semantics. Libraries like Two.js provide shapes and lines, but building meaningful diagrams requires layering on layout algorithms, connection routing, and visual hierarchy—exactly the "narrow scope" the original poster mentioned. This suggests that the most successful diagramming tools often emerge from combining a low-level drawing library with domain-specific logic for layout and semantics.

Ultimately, the choice depends on the tool's intended audience and use cases. A tool for technical documentation might prioritize text-based input and SVG output, making Mermaid or PIC compelling. A tool for interactive diagramming might require JavaScript libraries with canvas rendering. A tool built by someone who values functional programming might find pict's approach most natural. Each library represents not just a technical solution, but a philosophy about how humans should describe visual relationships through code.

The Lobsters discussion serves as a reminder that in graphics programming, as in software generally, there are rarely perfect solutions—only trade-offs that must be weighed against specific requirements. The most pleasurable drawing experience often comes not from the library with the most features, but from the one whose mental model aligns most closely with how you think about diagrams.