I work on the D2 project ([0]) and we switched from other Javascript runners (v8go) to Goja. Using a JS runtime with a dependency on cgo means your Go program loses the (huge) benefit of cross-compiling to different architectures, since at build time it gets linked to the current system's libc.
If you're interested in some production code with Goja, this is our code for calling RoughJS ([1]) from Go in order to produce the hand-drawn diagram look: [2]
Congrats on the launch! I'm the author of D2 (Terrastruct). I won't comment on comparisons you want to make as it's your launch, but just to clarify, we do have a programmatic API:
Hi and congrats on the launch! I run a company that also does software diagrams and we've often been posed the question of generating automated diagrams. We've never done so, primarily because I've never found auto-generated diagrams helpful yet. Code dependency graphs have existed for a generation now and I've just never seen one referenced by anyone. I wonder if things have changed now with LLMs.
The examples in your youtube video look good. I'm curious how they're generated. "We were surprised to find that a small fraction of code can generate a very accurate representation of the system." is a surprising statement to me. It's not been my experience that the code can reveal an accurate representation of human-understandable architecture beyond the call graph. The backend system generated from OpenHands (in your video) also looks pretty different from their own architecture diagram in their README: https://github.com/All-Hands-AI/OpenHands/tree/main/openhand... . How do you reconcile what an LLM says an architecture looks like with what maintainers prescribe? Is there a way to give feedback to it? (similar to pthangeda's comment on customization)
I wish there was a way to point this at a repo to test its efficacy. Though I understand that that'd be prohibitively expensive to do for free on the landing page.
Great points/questions. I suspect that information relevant to codebase architectures follows the 80/20 principle. For example, a router and index file in a React App will usually give you around 80% of what's needed to infer high level container info.
In terms of generating architecture diagrams, we follow the c4 model, with top level nodes defined as separately deployable units of software, and lower level component nodes being a set of functions wrapped behind a common interface. As the product develops, we'd like to include a way for feedback/fine tuning, but ideally the definition of an architecture diagram would be rigorous enough that there is no ambiguity, this is what we're aiming for. If you'd like to try it out on a specific repo, you can always use our extension for further analysis.
You're right to notice the similarity with CodeSee. Ultimately we're looking to focus on improving the developer experience without needing to leave the IDE. The idea is that CodeViz can replace or augment search and directory tree by providing a more intuitive interface for navigation!
> If you'd like to try it out on a specific repo, you can always use our extension for further analysis.
VSCode extension marketplace doesn't have the best security rails or reputation for security, and with this being closed source, just personally, installing and running it on my machine isn't something I'm comfortable doing.
> The idea is that CodeViz can replace or augment search and directory tree by providing a more intuitive interface for navigation!
That to me is a different goal than the one in your post (maybe it's just phrasing or I didn't understand the OP correctly), and is something I'd be excited to have!
> ideally the definition of an architecture diagram would be rigorous enough that there is no ambiguity
Rigor is a big "if" in software ;). See: UML's attempt. C4 is some very loose guidelines. IIRC, a big part of its attraction is the lack of rigor/formal standards.
Anyway, best of luck! Feel free to reach out if you'd like to chat diagrams
Sounds good, thanks for the feedback! Would open-sourcing CodeViz change your willingness to give it a try?
Definitely agree that rigor is a tricky term here, do you think the open-ended nature of C4 diagrams is a feature, not a bug? We've found in practice that top level diagram generation is both an art and a science, maybe it ought to stay that way.
In any case, shooting you a PM to set up some time to chat, and thanks again for the input!
> Would open-sourcing CodeViz change your willingness to give it a try?
Yup. Or a web app that I can point to an open-source repo.
Regarding C4, I'm no expert. I know the guys at IcePanel, an earlier YC-cohort company (https://news.ycombinator.com/item?id=34338995) that specializes in C4 diagrams, and they're very friendly, so if you haven't yet, they'll be much more equipped to chime in on C4 stuff.
I'm not sure where you got the impression that the paid layout engine is the primary backend for it.
We set out to make our own layout engine, which we charge for, true. However to say it outcompetes the efforts of all open-source ones including ones used by Graphviz (dagre) and university researchers (ELK) is quite the compliment, and not one that we've ever made ourselves. There are simply different use cases for each: https://d2lang.com/tour/layouts .
In fact we specifically de-weight our own layout engine, making it a separate install and not referenced anywhere in the D2 project. The vast majority of D2 users aren't paying a penny.
And like another comment says, we make it abundantly clear our own layout engine is not open-source everywhere that it's mentioned.
Your claim that this is a commercial post is also unfounded. I opened HN today as a reader and was surprised to see this post.
> I'm not sure where you got the impression that the paid layout engine is the primary backend for it.
I got this impression once I failed to reproduce the examples in your documentation with free backend.
> However to say it outcompetes the efforts of all open-source ones including ones used by
> Graphviz (dagre) and university researchers (ELK) is quite the compliment,
I did not mean to say that your engine outcompetes the open-source ones, but rather that d2 gives inferior results with them.
> Your claim that this is a commercial post is also unfounded.
I keep seeing thinly disguised d2 promos on the front page and this raises a few questions. This is fairly niche product, and far from unique in its capabilities. Why would it keep showing up among highest-ranked posts?
> I got this impression once I failed to reproduce the examples in your documentation with free backend.
This is easily verifiably false. All the examples have direct links to the playground to reproduce, except the few explicitly called out in the layout section as belonging to TALA's. If you still claim this, simply provide a link to an example that doesn't explicitly say it's made with TALA in the docs (d2lang.com).
> I did not mean to say that your engine outcompetes the open-source ones, but rather that d2 gives inferior results with them.
I'm not sure you understand the role layout engines have. All languages like PlantUML etc just abstractly represent nodes and connections and choose some styles for them. The rest is layout engine.
> Why would it keep showing up among highest-ranked posts?
You're engaging in conspiracy theories and there's nothing further I can prove short of an HN mod telling you these are legitimate unrelated posters and upvoters.
It was unmaintained for a long time (maybe considered done implementing the algorithm it set out to), but recently a Google engineer has revived it: https://github.com/dagrejs/dagre
And I wholeheartedly endorse and love D2, as well as the Terrastruct Studio web interface for it. Although Iainly use the VSCode extension now and the local TALA install.
Now if I could only get Posit to put D2 into Quarto alongside Mermaid and GraphViz, I would be set.
I'm confused... Figma can seemingly do all of this already, from a rendering perspective. And it's outrageously performant. It's one of the most performant web apps I've ever seen.
A long time ago a small startup used unusual tooling in the industry. The startup was small, but the tooling had some great qualities, which allowed the startup to compete with bigger teams feature for feature, spending less efforts to produce the same functionality as their industry peers. Eventually the startup had a successful exit, the founders become rich, and one of them even started sharing his experience in a rather systematic manner. Happy end.
Is it so that SVG requires to use all the features of it, or is it possible that you can mix and match, choosing what's important now and what's not, while benefiting from already existing SVG features? Is it possible that SVG followers don't do something which SVG does for them? Aren't there features, sufficiently aligned with SVG, which outperform directly working with other layers?
Figma is excellent at many things, but they struggle with accessibility. It's been a year since they wrote a blog post about their accessibility efforts so I don't know how far they've managed to solve the issues they identified - https://www.figma.com/blog/a-step-forward-in-our-accessibili...
It's hard to get as performant as Figma does, not as straightforward as a rendering medium switch. What if webgpu lets me get Figma performance with my little 6 person startup team without the massive engineering man-hours Figma has spent on performance?
Anyway, if it were high priority for us, we'd have done it already (switching to canvas/webgl). But right now it feels like buying a Quest when the Vision Pro is coming soon.
Open the windows or move. Your tap water is unaffected, you'd have to be on a well to be impacted. But activated carbon water filters work to remove it.
