Comment by tbiehn | Hacker News Reader

Comment by tbiehn | Hacker News Reader

This project (and others like it) are graphviz wrappers - they do some really cool stuff to emit styled .dot files that look better than writing and rendering raw gv.#

Allowing specification in Python offers very little advantage - in theory you think, hey, I've got hi-lighting, autocompletion, and so on from an IDE. It'll play nice in VCS. Maybe I can interrogate orchestration layers and so on to produce dynamic views.

In practice diagrams are produced by folks who might not want to use or learn python [or golang, their other implementation]. Instead a lean purpose-build DSL, maybe even an extension of graphviz dot, is easier and more portable for some audiences to pick up. Secondly, we can't JUST graft a DSL front-end onto these tools because the styled components are baked into the project.

My personal experience with layout engines is that they work OK for very small architecture diagrams, but become ugly or inelegant at useful scales.

I (and the teams I've worked with) settle on draw.io, either the desktop app, or committed as part of confluence, as the best way to describe intent/design - and rendering graphviz with a style up top for anything dynamic.

Would welcome seeing a true extension to the dot language that can unlock reasoning engines (like to do threat modeling) and render-time styling.

I have a love/hate relationship with diagrams, and diagrams-as-code-things (plantuml, mermaid, etc). As a programmer, I find myself trying to turn everything in to a software project: everything must be version control-able. Same with these diagramming solutions -- except I nearly never know what I want the digram to look like, when I start "writing" it. This means I nearly always end up on something like lucid.app just sketching out the solution, and thinking to myself that I'll turn it in to a beautiful diagram with one of the earlier solutions, later -- that never happens. So now I have a diagram I can link to (yay), but can't version control (boo).

Then, I discovered excalidraw[1]: it lets me sketch like lucid, but isn't nearly as polished or robust: you can throw together simple shapes, draw lines between them, and the lines stick to the shapes, so you can move them around and the lines move too. You can also group things together, and draw freehand, and also include text -- what more do you need?

The cool thing about excalidraw is that you can share your drawings, and export them as SVG files -- yay! I can version them again. You can also self-host it, which is a massive plus in my book.

/rant

[1]: https://excalidraw.com/

Nice (and MIT Licensed!) - I'll give this a shot.

Another thing these types of tools bring is multiplayer support. Which I found my distributed teams really benefiting from over time.

Excalidraw seems to boil down the important parts of Miro into an even neater and user friendly package. And it seems really modular and have a really interesting API as well. You can use it as a react component for example.

I've been mostly using the VS Code Excalidraw plugin. Any file with name ending on `.excalidraw.svg` or `.excalidraw.png` is an Excalidraw-editable image of the respective format. This means you can save it alongside your markdown docs and embed them directly, but also edit the exact same file on the IDE.

Big Excalidraw fan and I had no idea you could do that...this might be the version controllable solution I've been looking for. Also have given up trying to get mermaid and other solutions to work well.

drawio and its vscode plugin supports the same

There's also a draw.io VSCode extension, for anyone who prefers that.

I would push back against DSLs. It means year another language to learn and that is a barrier to adoption.

The concepts of internal DSLs and external DSLs is relevant here. The article is an internal, to Python, DSL. It runs in the language the tool is written in. Mermaid is an external DSL. You can’t build a Mermaid renderer in Mermaid. For diagrams I’d rather have an external DSL or a macro system than an internal DSL because it looks cleaner IMO. But it’s nice to have syntax highlighting already working in internal DSLs.

I hear you, oh my how I hear you.

I’ve finally found a happy middle at work where I version control the markdown based “user manual” and API specs/docs, but the design pages, rich with graphs and diagrams are going to live on the corporate wiki and require that I just learn to be disciplined to keep them up to date.

Surely I can just do that and not everything has to be… I dunno what to call it… that thing where us programmers love to see every human process problem as requiring a technical solution.

I'd end up with something like this if I ever had the time. Instead of a corporate wiki, though, I'd probably use something like sphinx to compile PDF files, and store them on the public workspace.

> and export them as SVG files -- yay! I can version them again.

However depending on how the resulting SVG looks like this may not be different than just putting a PNG into a git repo

Is your concern about committing a binary object that is difficult to diff or not being able to recreate/edit the diagram.

Particularly in the latter cases, most of these tools embed the machine readable diagram inside of the PNG. So you can just open the PNG inside of draw.io or excalidraw (if it was created by that tool) and edit the diagram. This is because the plain text file is embedded.

It’s great that lots of tools are going this way. Notably, if you’re doing image generation with Stable Diffusion or Flux, you can just drag a PNG from ComfyUI into the ComfyUI window and get the same whole workflow. It’s a great learning tool.

As for diffs? Well, that’s hard - even if you were diffing the “source” text files for excalidraw or plantUML, a lot can change that makes it nearly impossible to understand. When all that really happened might’ve been a small styling change and moving a node.

Yeah, the most important part of versioning should be the code used to create the diagram, IMO. The result files, whether SVG or PNG, should be packaged as a "release", if you were to use Github.

> the plain text file is embedded

Hold the phone -- some PNG files have plain text representations embedded within? That's nuts, I had no idea!

Yeah it’s a container format. :)

Hmm, and also a super convenient exfiltration format… never thought of that.

You can export from Lucid to SVG. It also has its own version history. For me it has been working OK.

Is this a recent addition? I recall attempting to do this some years ago, failing, and putting the tool out of my mind as a result. Maybe I was doing something wrong.

> you can share your drawings, and export them as SVG files -- yay! I can version them again

Out of curiosity, does anyone know of a drawing tool -- like Excalidraw, Lucid or Draw.io -- that has the option of exporting diagrams to code, i.e. something like PlantUML or Mermaid?

Not a diagram tool, but can be used like one, since it converts Python functions into nodes that you can connect to each other and export the resulting layout as images (PNG, SVG, SVG inside an HTML page) or as plain Python code: https://github.com/IndiePython/nodezator

full disclosure: I'm the creator and maintainer of the tool (but this is no advertising, as I released it to the public domain since day 1)

> except I nearly never know what I want the digram to look like

That is the point of diagrams as code. You focus on the semantics, not on what it will look like and you let the tool decide for you.

Do you know how excalidraw compares to draw.io? I've used draw.io in the past, but see excalidraw mentioned quite a bit too. I'm not good enough at using draw.io to be against switching for future projects.

> In practice diagrams are produced by folks who might not want to use or learn python [or golang, their other implementation]. Instead a lean purpose-build DSL, maybe even an extension of graphviz dot, is easier and more portable for some audiences to pick up

This is so absolutely ludicrously absurdly wrong that it's comical.

No one wants to learn a new programming language. Cf. all of the old algol languages that are still around and all their "replacements" that are no longer around.

Some people (not even a majority) are willing to learn a new language if compelled by force or incentive. Diagramming is absolutely not enough incentive to learn a new language.

I agree with both of you, but I still don't want to use Python to generate my diagrams.

Diagrams are a visual thing. I prefer a visual designer. I can send that to some random nontechnical person for a presentation and they can edit them, etc.

I find with things like this, it works pretty well until you want to do something off the beaten path, then it's a pain where you're trying to figure out how to get it to render like you want it to.

Reminds me of the ole "just move it 2px to the right" in the CSS of yesteryear

> This is so absolutely ludicrously absurdly wrong that it's comical.

Quite the hyperbole, but I do agree that python isn't so wrong of a choice, but the problem is diagrams eventually interact with non-technical people and that's where it gets tricky.

I LOVE mermaid, d2, but at somepoint I hand the diagrams off to someone who knows nothing about markdown and honestly they shouldn't have to know it to interact with a diagram.

All these "diagrams as code" are great for an isolated group. I can pump them out WAY faster than manual drawing programs (draw.io, etc), but then run into the iterop wall w/ other teams.

I'd LOVE a place that could be like AWS's graphical editor that sort of goes in between the two. It's a hard problem I 100% agree and would require yet another DSL, ugh.

I upvoted you for the hyperbole but absolutely don't agree.

People who don't want to learn a new special purpose language are basically saying that 'I've got a hammer and everything is a nail' is fine, which is (to your point) absurd. Languages are tools, use tools to solve problems the tools were designed to solve.

Where I do agree is what you haven't said clearly: it isn't obvious what problems 'diagrams as code' solve. The idea is cool and I've used plantuml with some success, but in the end the diagram is supposed to be consumed visually (including changes - to preserve spatial relationships between versions).

I love python and I found diagrams fine but after tried for a few time , it comes down to me that diagrams as code only good for diagrams that are already sketched out on how it would look like in design tools like draw.io . Diagrams need a Visual editor. Designing using code is very hard to visualize how it will look like by just looking at code and running , editing , looking back is not fun. Since code provides easy versioning and search and replace , refactoring is easy , what we need is visual editor that generates code and so we can keep that code versioned in github.

See https://Schematix.com

Has a graph query capability which is like a reasoning engine. And beyond that, can run simulations on the models.

Multi user, version control with branch and merge, time shifting, etc.

It's for diagramming whole environments, not just discrete diagrams.

This is incredibly cool! I've been using Neo4j to hack something like this together but the UI on this is amazing. I honestly believe that tools like this should be as fundamental to IT as double entry bookkeeping is to accounting and CAD is to engineering and blueprints are to construction.

At a glance this looks pretty nice for people like me who already know python, hate doing things manually, and have to make and update diagrams sometimes.

Sure it’s probably not worth learning python for, but it is a python library, it’s for pythonistas, not everyone.

If you decide to try the visual language DRAKON (https://drakon-editor.sourceforge.net/) you will notice that it always produces non-ugly diagrams by literally not allowing you to draw anything ugly. It has some basic rules how to compose the diagrams but once you get the concept - everyone will love your diagrams. Here are a few examples of my diagrams - https://postimg.cc/gallery/Z4SbScg

Reply on news.ycombinator.com