[hk__2]

> Maybe it's not too bad for very simple diagrams but unmanageable for anything complex

On the contrary, I use drag&drop tools for very simple diagrams but prefer using PlantUML for anything complex because its text-based interface makes it easy to generate, diff or store in a git repository. The best of both worlds would be a text-based tool to hold the semantics of your graph, and then a drag&drop interface to fix the layout.

[agileAlligator]

> The best of both worlds would be a text-based tool to hold the semantics of your graph, and then a drag&drop interface to fix the layout.

Exactly this, I wonder why no one has come up with it yet. Maybe you could embed the layout details like coordinates of elements inside the markup in a separate section?

[Pxtl]

I've seen tools that work like this - Microsoft's earlier kicks at entity framework tried to do it for SQL table block diagrams. They would constantly get out-of-sync as merges happened and were generally a pain to manage.

I'd rather a tool just let me give it hints of "this is an important block put it somewhere high visibility" and "this is semantically the root of a tree" and stuff like that, then just focus on having a good clean layout engine.

[agileAlligator]

The issue with graph engines that manage the layout themselves is that it becomes very messy the higher the number of nodes you have. I've experienced this with Mermaid.js and Obsidian.

[Pxtl]

Still, I'd rather have textual hints about layout than explicit drag-and-drop. Stuff like "boxes a1, a2, a3 should be presented sequentially" or "box b1, b2, b3 are tightly related and should be presented close to each other" and "box c is the root of its tree" and stuff like that.

[agileAlligator]

I'm saying it should be a mix of the two. The output should be interactive and change the code on interaction.

[Exuma]

How does plantUML compare to this