D2: A new declarative language to turn text into diagrams
d2-lang.com
d2-lang.com
Seems like it could have been cool, but likely will not seriously try it because of these limits.
Shame. Mermaid works almost okay and often looks like garbage. I wish there was an open source effort somewhere to do better, or even a paid locally runnable tool that has no service connections.
That said, over time a diagram's value will diminish regardless if you have auto-layout or not, since the codebase will always outpace documentation.
Gotta find a way to do an "open core" or similar.
Just because HN isn't Reddit doesn't mean ads aren't thrown in with all the curated "content"
Like other said, maybe it will inspire someone to take this and make an open-source version
> if it wasn't paid.
Maybe you intended to say 'if it wasn't closed', or similar.
I think the author of this page started with the assumption that of _course_ given their business and product, a 'language' for diagrams is only giving users access to something that maps on to whatever internal representation their tool already uses, and allows technically inclined users to work with text and fewer clicks. To them, the assumption seems to have been that readers will already be users of their product, and the assumption that the 'language' is built into their tool _and nowhere else_ is so far in the background that it's only somewhat obliquely addressed as the last question in a FAQ.
I mean, I agree, that "new" is marketing speak for "alpha/beta", but -to me- there is a difference between a "language/tool" and a "Single-Vendor-WebService". Or is my understanding of the semantics of the English language outdated?
Even patents aside, why wouldn't this D2 thing qualify as:
COMPUTING
a piece of software that carries out a particular function, typically creating
or modifying another program.
While it isn't creating or modifying a program, I'd consider "parsing text in a specific syntax to create a diagram" more like a compiler than a site that just provides information or crud sites with some forms. I'm not entirely certain how where it runs affects it's tool status, but it certainly is a consideration to be made while evaluating it for any particular use case.
(also from define tool:
a thing used in an occupation or pursuit.
I can think of quite a few single vendor languages - various IBM mainframe languages like JCL, K, matlab, multiple .Net and MS languages until recently, applescript, etc.
> When it's more stable, we will be open-sourcing the language.
If thats the case, that only the language will be open-sourced, not the visualization, then I'm not entirely sure what that really gets you, beyond perhaps alternative editors?
But its the layout algorithms that are actually notable.
edit: I've updated the docs to make this clear
But when the project is trying to compare itself to others, it's only fair to compare based on what's true of the project currently vs what's aspirational. I would guess that for many potential users, the temporary limitations trump most of the stuff in the comparison portion of the FAQ, or the "current shortcomings" section.
And the "Getting Started" section could also say "create an account and familiarize yourself with the existing terrastruct product" or whatever.
If they made the core open and allowed users to use this language independently of their online service, there's still a ton of value they could have added with premium services on top of this. For writing the docs, sharing with teams, comments / versioning, etc. Visual figma type features essentially. A team bought into the specification would very likely pay for this.
But it's hard to imagine it taking off being completely locked into their service. Ah well, a fine idea and looked pretty well executed.
EDIT: maybe that's on their roadmap "When the language is more stable, we intend to open source D2. This will happen sometime in 2022.". Ok, back on board
> INFO: It's currently in alpha. During this time, it's only housed on Terrastruct, which provides the most well-supported interface (IDE) for it. Once we have a stable v1, we'll release and continue development of it in open source and make local options available.
If not, I won't use it for anything serious.
When I want to make diagrams graphically, I use diagrams.net. when I want to make diagrams from code, I use PIC. What else do people use? PIC works pretty well, but it has its limits and it's ancient.
An alternative implementation with good docs.
Is a modern implementatiom that's pretty nice.
And there's C4 Model for Visualising Architecture [0] that has upcoming tool support, for instance Structurizr DSL [1]. It has an online editor [2] that can export to Mermaid, PlantUML and other formats. And has various open source repo's, like this Java codebase for the DSL itself [3].
[1] https://structurizr.com/help/dsl
1. D2 will be open source and usable outside of Terrastruct. Terrastruct will remain the best interface to D2, with bidirectional updates from GUI, but we already have vscode and vim plugins ready for local editing. We're a small team and working on one thing at a time.
2. We're aware of PlantUML, Graphviz, Mermaid, of course. These are mature offerings, but I see plenty room for improvement that we intend to tackle with D2. https://d2-lang.com/tour/faq#how-does-this-compare-to-mermai...
Feel free to ask any questions!
> This reveal caught us off guard
Hmmm
I, like others, will keep an eye out for when it becomes open source mainly to see which license.
I do think you could have made it obvious in the Getting Started section that this is not a local runnable language. I spent some time looking for how to install it only for me to realise that it is some form of SaaS.
Open source can mean more than just a license. It should mean more than just gifting a code base once you think you're done.
I don't mean to come across as bitter or entitled. I just question the value of waiting till the last minute. For now, the promise only stands as a way to pull people into the fold. I've seen this kind of promise many times before in projects much like this.
It reminds me of that adage, "Start your business, the tool you build to run your business is now your business"
PIC is designed to be embedded inside of TROFF, so it's... not pretty, to say the least. It does have the -> arrow thing, and the label: value syntax, though. For as hideous as it is, it's surprisingly easy to use.
Any honest open source project would not say such a thing categorically, and would welcome and support community improvements that take it to an even higher level.
But instead it sounds like you will rig the game, with "open source" just meaning "let's get people to work on our proprietary product for free, and we can fly the banner of open source while we're at it!".
It also brings to mind the JavaScript library d3, which, while not strictly for making diagrams, can easily lend itself to the purpose.
Calling this thing "D2" seems potentially confusing.
"D" the programming language [0]
"D" the data language specification [1]
"D" the programming language for DTrace [2]
"D3" the javascript library [3]
"D4" library/tool for Declarative Data-Driven Documents[4]
"D4" implementation[5] of the data language specification[1]
Overall, I think "D2" is objectively the best choice here. We have at least three "D"s, two "D4"s, and one "D3", so it makes sense to put it in as "D2". I certainly wouldn't want another "D" or, heaven forbid, a "D5".
[0]: https://en.wikipedia.org/wiki/D_(programming_language)
[1]: https://en.wikipedia.org/wiki/D_(data_language_specification...
[2]: https://en.wikipedia.org/wiki/DTrace#Description
[3]: https://d3js.org/
I could have never maintained the diagrams I used for other developers on my teams or folks on the audit/regulation side of thing without it.
The default styles are really unprofessional looking and I think a lot of folks look the other way once they see that. C4 diagraming with PlantUML is also a breeze for systems diagrams.
Also playing with 11ty and this to replace our home grown tooling based on markdown with embedded dot.
To try it out, just open a new github issue and add
```mermaid
graph TD;
A-->B;
A-->C;
B-->D;
C-->D;
```
Firstly, neither its parser and its visualiser can be extracted from the library. You can't process a grammar on a backend and then render out an SVG. You can't generate an SVG as part of a CLI tool - not without spinning up a web browser in automation mode.
Secondly, the grammar is messy. Really really awkward. Flowcharts are OK because they were the first Mermaid usecase, but other grammars are quite weirdly written, brittle, and try to be a mismash of other DSLs. Which in turn leads to very awkward token choices to avoid stepping on the toes of parts that are UML-like, parts that are DOT-like, etc etc
My impression reading Mermaid's issues is that it was built from scratch by a JS developer who hadn't any previous experience with DSLs, parsers, or language design, and largely learned as he went along. That's acceptable for a proof of concept. But as a finished product Mermaid is a lumbering mess
In this D2 example (https://d2-lang.com/assets/images/intro-example-a917149ff3b7...), the diagram is nicely designed to be centered on the nexus node crawler. But the choices of which side the tributary nodes are on is not. You might want cron below and ps->express below - or to the sides.
The grammar can be extended to accommodate this (maybe already has been), but what is the semantic meaning of above, below, left or right?
One semantic choice is made: the "persists" arc is unidirectional, and is presented left-to-right - a natural order for many languages.
(Technically, "declarative" needn't be "semantic", but arguably is the most useful one)
But if that diagram drawing tool does not graduate to allowing me full control over every detail of the output (albeit that might be verbose or awkward) then it cannot grow with me as my requirements become more complex and it is good only for toy-sized or throw-away projects.
I think it'll be more like ordered keys in JSON - not ordered, according to the spec, but very useful in practice, because easier to compare, locate keys by eye etc. This order might not merely be "the same" as the input happened to be, but an order customarily used - and there might be a semantic reason for that order in the first place, used in some original, non-JSON, representation.
Tenuous.
https://structurizr.com/ - diagrams as code
https://c4model.com/ - C4 model for visualising software architecture
The consistency of structurizr + c4 is great for sharing information across scaled teams of teams.
The XState Visualizer generates nice looking statecharts.
Click See an example in the left pane, then click Visualize at the bottom of the right pane.
On the roadmap are visualizations for XState's actors facility, i.e. multiple statecharts interacting with one another.
If you login, you can save/fork statecharts and get shareable links for them. There doesn't seem to be a way to export the diagrams (as PNG or SVG) but maybe that will be added in the future.
It does look like a material upgrade from Graphviz, but even so...
So, could you please elaborate?
I think this can be really difficult...?
I was fiddling with RDF and N-ary relationships some time ago, but the easiest way to express a complex relationship is to pre-define the whole relationship as an entity, and relate it to actual entities. This ends up with something similar to function call (e.g. score(subject: playerA, object: playerB, using: weapon, when: time)) or RDBMS tables.
But "no DSL-in-DSL" should be a right direction. The core language should be carefully designed to allow modular approaches.
This notation is pretty similar to the notation in the FOSS tool (admittedly that I wrote) over here: https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h...
Fortunately, no need for accounts or payment there.
Use this all the time for my work and the ability to share a diagram with a url is a killer use case
Like feedgnuplot [1] but not only restricted to graphs.
[1] https://speakerdeck.com/ajstarks/decksh-object-reference [2] https://speakerdeck.com/ajstarks/dchart-charts-from-deck-mar...
How much of your life were you planning to dedicate to scrolling from one side of the image to another?
And there's a link to a gallery with even bigger ones, so #NumberOfNodes alone does not seem to be the main limiting metric. Maybe combined with the choice of rendering layout.
But more seriously, a careful webgl implementation gets you maybe halfway there, and most I've seen break well before then. It gets tricky with browser js memory limits and raw perf. We are looking into hitting more 100M level with interactive speeds... But takes creativity & opts I wouldn't expect for a diagramming tool :) and, if your kind of thing, we are hiring :)
Hoping the community will work more on declarative 2D diagramming methods and tools.
Is this project basically the New Mermaid? Why not go in a new direction. People want diagrams, not just networks, not just series-parallel graphs. Anyway, ML is changing everything. Can Stable Diffusion make crossings at right angles? Just wondering.