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.
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.
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.
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.
> 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)
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.
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.
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.
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.
> 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.
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
Semgrep is another great option to get value out of static analysis checks against both the language and a few common frameworks. It remains a popular choice for security folks writing static detection rules (and contributing them to the commons).
since the underlying storage is an LRU, I just ignored dead keys. Nope there's no client re-request or retries. That is left upto the "updater" function
Just imagine if we didn’t use heuristics to fix arbitrary inputs and instead we used some sort of learning algorithm that was trained on producing valid looking json - then all we’d need to do is add a prompt and start with some random noise… :P
Not the fort-knox implementation it claims on the tin.
'LocalSend uses a secure communication protocol that allows devices to communicate with each other using a REST API. All data is sent securely over HTTPS, and the TLS/SSL certificate is generated on the fly on each device, ensuring maximum security.'
How do they achieve maximum security while generating X.509 certs on device?
'When encryption is on (HTTPS), then the fingerprint is the SHA-256 hash of the certificate'
Confusingly there is a HTTP non encrypted mode, and the docs claim the fingerprint only used to avoid discovery collisions.
Out-of-band [visual comparison / QR code scanning step] sharing of fingerprints COULD be acceptable to prevent 'man in the middle' attacks, however the documentation doesn't seem to indicate that this detail is surfaced or shared with the user.
The discovery protocols look 'hella sus', but most local media sharing and discovery is.
Reminds me of https://tinygo.org/ - a project that brings Golang to embedded devices, browser (wasm) contexts. Do you converge or diverge from that project?
Neither, though the final result can be similar, but at project level, tinygo and pcz has very different approaches to achieve the final result:
- tinygo chose the hard path to write a llvm backed toolchain with some custom behavior that compiles Go code (using official std) to llvm targets.
- pcz chose the easy path to write a stdlib from scratch that compiles to desired targets using the official Go toolchain.
One major benefit of pcz's approach is you can import packages from the pcz std module like you do with any other Go package, the development experience can remain unchanged.
I’m chatting with a founder who started building a moderation pipeline with gpt-4 w/ embeddings to save credits & time. Seems like something that will become ubiquitous.
A tip for your context window problem: prefer ‘editing’ a previous message to add whatever clarification is required - rather than having a ‘chat.’ Definitely helps keep it on the rails.
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.