Hacker News Reader

Comment by bastawhiz | Hacker News Reader

Exactly. Tools to build visually appealing diagrams well appeared. I remember how fun it was diagramming in Visio for the first time.

Why would someone (especially someone non-technical) spend the time to learn and write what's essentially code to make a diagram when the alternative is drag and drop? That's not to say UML is without value, but to me it comes down to the difference between CLI and GUI tools: when the latter is broadly available to the masses, the former is only going to be used by power users who want the flexibility.

Another personal nit: I've never seen a "pretty" UML diagram. The value of aesthetics is obviously not critical, but if I'm looking to make a nice diagram to show my boss and the options are UML and Whimsical, I'm going with Whimsical every time.

View on HN

I’m of the opposite predilection. I want to be able to manage my architectural diagrams in code review. I like having a tool where I can edit it in one pane and have the diagram be a live preview beside it. Ideally the wiki tool would be able to render it.

GUI tools I find aren’t as good for iteration/living in source control/embedding in a wiki nicely. “As code” ecosystem is very immature - automatic live preview is frequently non-existent, resulting diagrams are ugly and hard to layout.

PlantUML is great but suffers from having a very difficult to customize layout, finicky styling, ugly default style, and a bit of a mess of a language that’s evolved organically.

> PlantUML is great but suffers from having ... ugly default style ...

I quite enjoy the C4 diagram stylings: https://github.com/plantuml-stdlib/C4-PlantUML

That’s interesting. Does it have an atlassian plugin?

> Why would someone (especially someone non-technical) spend the time to learn and write what's essentially code to make a diagram when the alternative is drag and drop?

An advantage, depending on context, is that it brings the diagrams closer to the code that they're modeling, making it possible to version control them and include the diagram generation in documentation build automation.

They're not modeling code in many cases, they're modeling processes, products, and user flows. If you're building an app, your diagram is going to look a lot more like the things your users see in order rather than the code to make those UIs appear. E.g., the code for react-dom-router routing is going to look very different from the actual navigation patterns built on it (tree structure versus linear flow).

The primary need for diagrams is drifting further from the use case you're describing.

Reply on news.ycombinator.com