Why is it that on HN when somebody posts a link to a cool project, the top comment is systematically something like "here's an alternative"? Can we just talk about the posted link instead of just stealing the light?
because HN isn't a place to merely advertise a product to gain traction and marketing. These alternatives and comments on other competitors shed light on the entire eco system, and prevent astroturfing as well as group think. It may even widen somebody's lack of knowledge.
Personally I think this isn't a good way to look at it. Nothing exists in a void and to contextualize things, it's often useful to compare it to other similar things. In the startup world, it's often explained in the vein of "Uber for X" type of companies. Since Graphviz is one of the oldest and most widely used pieces of software in this space it makes sense to compare any new developments against it.
I'd say that's one of the top reasons I like HN, as you can see what other people are using. Most of the time when I search the web for comparison between x and y, I find little useful info.
I clicked through on the comments to this because I'm looking for something similar to Draw.io and now I know about Graphviz as well. Once again, serendipity provides.
Even if a particular project isn't that interesting to me, the landscape surrounding the project may be. The community here provides some context for the world this project lives in and that's pretty valuable, IMHO.
I can't say I agree with you 100%, but I see your point. That is part of the reason I don't stop at the top comment. There's usually a lot of good information further down as well.
Graphviz has been the old standby forever. I had an internship in 1999 where my mentor used graphviz to debug the compiler he was working on. Everyone should have this tool in their debugging tricks library.
I'm actually doing the same thing right now. I had been using a textual output to make sure my AST was correct, but that is a real pain. Graphviz made it extremely easy it is so much easier to read.
I use asciidoc extension by the same author. It works well with kroki.io so you can do a wide variety of diagrams (including graphviz, plant uml and others)
How do the both of you make graphviz diagrams look decent?
I often resign myself to using it for generating the first structure, and then laying it out better in an svg editor. Of course that way I lose some of the maintainability of it.
I think this extension demonstrates the flexibility of VSCode and how easy it can be to extend the platform with an extension.
Although it's supported by Microsoft, it's heavily influenced by the Open-Source community. I believe that's the reason it's so popular and user-friendly for both developers and users.
Can you imagine someone trying to implement this extension on a proprietary platform like Visual Studio or IntelliJ? ... going through proprietary documentation with no access of the Source-Code to the underlying system... It would be a nightmare
Not to knock VS Code, but I suspect this has more to do with draw.io Desktop[0] and VS Code both being JS/electron apps and draw.io officially supporting an embedded mode[1]. IIRC, most of IntelliJ is open source but it is probably much harder to embed a JS app in a Java app.
it really shines when apps open their internals via a web-like API to allow embedding.
I wish more apps have such extensibility, so that it's easy to embed apps within, and that apps be made more modular so that they can be embedded.
Microsoft had the same vision with their COM architecture, which allowed apps to be embedded inside other apps. But sadly it's too complicated, and difficult to really use (so you won't have seen much other than microsoft's own apps using such features to embed other microsoft apps).
And the web would've been a great API/protocol level for an app to be embedded via such a way, but a lot of apps dislike being framed/embedded.
In theory, for a big system like intellij or VS you want to use the docs over the source code; both are projects with millions of LOC, at which point reading the code to write an extension becomes unfeasible.
That said, I do really enjoy being able to go to the source for libraries I use, recently in Go. What helps with that is that the code is consistent and readable no matter what project I open up.
> In theory, for a big system like intellij or VS you want to use the docs over the source code
Sadly for IntelliJ the documentation is lacking. There is some very general documentation online but they do not publish a generated API documentation, so as an extension developer you are often in the dark trying to figure out what classes / methods to use, unless you learn how to compile the documentation yourself.
WebKit doesn’t count? Google, BlackBerry, Amazon, Opera, Tizen, etc all maintain different derivations based off of Apple’s work with WebKit, with the most well known being Google Chrome.
(Although I’ll grant that WebKit itself is a fork of KHTML from the KDE project).
apple has plenty of messy approaches though. they simply aren't interested in creating anything that will itself run or allow creation of anything that is intended to be used outside of their devices and ecosystem.
> Although it's supported by Microsoft, it's heavily influenced by the Open-Source community.
Isn't it developed by an external studio in switzerland which just happend to be attatched with microsoft? I always got the impression this independance from the old Redmond-Cancer is a main reason why it could propsper so well.
By which I mean that in Redmond there seems to be some gangwars going on between the different departments, projects and generations of developers, which in external Studios seems to mostly non-existent. There was also that studio in israel which seem to propser quite well. Maybe Microsoft is accidently a perfect example for diversity in culture working out beneficial with software-projects?
The project has an embed mode, which was used in this case.
It needs a sequence embed, but basically you load draw in embed mode within an iFrame, do a handshake using postMessage, then load and save is direct between parent and frame, again using postMessage.
The idea is to be able to embed into hosts that are capable of storing the diagram data, without any code changes to draw. It can embed either the main site (which was renamed to app.diagrams.net), or a locally hosted/internally packaged version of the project.
Yes I've been using it offline with the electron app and on my phone as an offline website. It works really well that way. The advantage of the electron version is that for local files, it doesn't ask Everytime you want to save, where to save and if you want to overwrite, or save in downloads depending on browser settings.
I've been looking at draw.io and PlantUML - what has worked well for others? draw.io is much easier to get into, but I can see declarative diagrams making maintenance easier for long-lived docs.
Being a person who doesn't typically want to draw diagrams, I opted to go with draw.io as it looked very simple and easy. However, I was nudged to try PlantUML and to my surprise it was a lot simpler and faster to create diagrams. A point which you mentioned is maintaining the diagrams for long-term. We have a docs folder in our repository which includes all our PlantUML. It's quite easy to pick up as a language, and because it generates the diagrams for you, you don't waste minutes fiddling with getting the arrows all matched up. I would definitely give it a try - makes life so much easier!
Plus, there is a VS Code extension for it as well, which auto generates the diagrams when you save.
After having used both Draw.io and PlantUML, I prefer the latter. Far easier to get consistent drawings from the whole team without fiddling. And updating the drawings later is also easier because the language is much better than Draw.io's XML.
If we could get an extension like this for every file type VS Code could basically become your OS (desktop environment) or file manager at the very least.
It would be handy. I wonder if it is possible to create one that opens the file in your default OS way, and embeds that window inside a VSC tab. Can dream!
I guess the main reason is so you can see your file explorer while working on a file. You could put your file manager side by side with whatever program you're using also I suppose.
A better OS with beautiful lisp language already exists called emacs (which happens to be an excellent text editor as well), try it. VSCode is built on a foundation of electron which is riding on chrome v8 engine. If one day webassembly becomes common and vscode can shed it’s weight and become close to 50-60% of what emacs is, then it might be possible to think of it as OS, right now it looks 2-3 decades behind emacs.
It’s only popular among programmers who wants an IDE not a programmable environment like emacs. Emacs attract scientists and researchers and people who write OS, compilers, DB, language specs, HPC systems and algorithms, design algorithms, performant OS utilities etc. VSCode attract web development crowd which mostly spend time on building web forms (making it dynamic using JavaScript with some framework may be react) on top of database schema or some document storage. Given this I doubt it will be anywhere as programmable as emacs.
I am also an Emacs user, but please don’t be so dismissive of other people’s work. This looks like a great extension.
Despite my qualms about memory use and latency, VS Code is a fully programmable editor just like Emacs, except using Javascript in place of Lisp. I don’t see much of a difference, except that JavaScript is much more popular (and thus the VS Code ecosystem develops faster) and Electron is a much more modern runtime, which enables easier integration of visual tools.
I think rather than criticizing Code all the time, we should look and learn. Clearly, Code is doing a lot of things right. And it’s not just the web dev crowd. I have seen a lost of Rust folks go to either Code or IntelliJ.
> Emacs attract scientists and researchers and people who write OS, compilers, DB, language specs, HPC systems and algorithms, design algorithms, performant OS utilities etc. VSCode attract web development crowd which mostly spend time on building web forms (making it dynamic using JavaScript with some framework may be react) on top of database schema or some document storage.
Yeah, about that. What do you think those extensions do? Do you think they all cross-compile to Javascript and plug into the famed C-bindings for React? :-D
No need for elitism. I'm sure there are scientists and researchers perfectly happy with Notepad++ and I've worked with web developers who've used emacs.
I agree that VSCode is unlikely to reach the level of emacs in terms of being a fully programmable environment. But what it does offer is an easy and modern out-of-the-box experience.
VSCode is literally the only electron that doesn't bother me because it doesn't chew memory like Chrome, Slack, or every other electron app I've ever tried.
Better OS is highly disputable. Emacs has point where can win against against VS Code, as also points where is lose. It all depends on your demand and usage.
> Given this I doubt it will be anywhere as programmable as emacs.
Customizing can be a curse. Seeking it purely for the sake of customizing is an harmful poison. VS Code has some areas for improvement, but it's good enough as it is now. It doesn't need to be as programmable as emacs.
Readit News
For more information about graphviz: https://graphviz.org/
because HN isn't a place to merely advertise a product to gain traction and marketing. These alternatives and comments on other competitors shed light on the entire eco system, and prevent astroturfing as well as group think. It may even widen somebody's lack of knowledge.
Even if a particular project isn't that interesting to me, the landscape surrounding the project may be. The community here provides some context for the world this project lives in and that's pretty valuable, IMHO.
Dead Comment
Is it to draw the call graph? How it's actualy done, with printfs or some lib?
https://github.com/asciidoctor/asciidoctor-vscode/blob/maste...
I often resign myself to using it for generating the first structure, and then laying it out better in an svg editor. Of course that way I lose some of the maintainability of it.
[0] https://github.com/jgraph/drawio-desktop
Although it's supported by Microsoft, it's heavily influenced by the Open-Source community. I believe that's the reason it's so popular and user-friendly for both developers and users.
Can you imagine someone trying to implement this extension on a proprietary platform like Visual Studio or IntelliJ? ... going through proprietary documentation with no access of the Source-Code to the underlying system... It would be a nightmare
[0] https://github.com/jgraph/drawio-desktop
[1] https://github.com/jgraph/drawio-integration
I wish more apps have such extensibility, so that it's easy to embed apps within, and that apps be made more modular so that they can be embedded.
Microsoft had the same vision with their COM architecture, which allowed apps to be embedded inside other apps. But sadly it's too complicated, and difficult to really use (so you won't have seen much other than microsoft's own apps using such features to embed other microsoft apps).
And the web would've been a great API/protocol level for an app to be embedded via such a way, but a lot of apps dislike being framed/embedded.
https://github.com/JetBrains/intellij-community
That said, I do really enjoy being able to go to the source for libraries I use, recently in Go. What helps with that is that the code is consistent and readable no matter what project I open up.
Sadly for IntelliJ the documentation is lacking. There is some very general documentation online but they do not publish a generated API documentation, so as an extension developer you are often in the dark trying to figure out what classes / methods to use, unless you learn how to compile the documentation yourself.
(Although I’ll grant that WebKit itself is a fork of KHTML from the KDE project).
Isn't it developed by an external studio in switzerland which just happend to be attatched with microsoft? I always got the impression this independance from the old Redmond-Cancer is a main reason why it could propsper so well.
By which I mean that in Redmond there seems to be some gangwars going on between the different departments, projects and generations of developers, which in external Studios seems to mostly non-existent. There was also that studio in israel which seem to propser quite well. Maybe Microsoft is accidently a perfect example for diversity in culture working out beneficial with software-projects?
It needs a sequence embed, but basically you load draw in embed mode within an iFrame, do a handshake using postMessage, then load and save is direct between parent and frame, again using postMessage.
The idea is to be able to embed into hosts that are capable of storing the diagram data, without any code changes to draw. It can embed either the main site (which was renamed to app.diagrams.net), or a locally hosted/internally packaged version of the project.
Additional information on the embed format:
https://github.com/jgraph/drawio-integration
https://desk.draw.io/support/solutions/articles/16000042544-...
Very neat!
Plus, there is a VS Code extension for it as well, which auto generates the diagrams when you save.
[1] https://marketplace.visualstudio.com/items?itemName=jebbs.pl...
[2] https://github.com/RicardoNiepel/C4-PlantUML
[3] https://c4model.com/
Do you create actual UML diagrams or just use the shapes and constructs available in PlantUML to create a more ad-hoc diagrams?
> waste minutes fiddling with getting the arrows all matched up
I can resonate with this!
However sometimes PlantUML does not lay things out optimally (for a person) and the layout can only be tweaked so much.
That being said, for most of my purposes non-optimally laid out PlantUML diagrams were effective enough for the communication I needed to get through.
mermaid js website : https://mermaidjs.github.io/#/
It’s only popular among programmers who wants an IDE not a programmable environment like emacs. Emacs attract scientists and researchers and people who write OS, compilers, DB, language specs, HPC systems and algorithms, design algorithms, performant OS utilities etc. VSCode attract web development crowd which mostly spend time on building web forms (making it dynamic using JavaScript with some framework may be react) on top of database schema or some document storage. Given this I doubt it will be anywhere as programmable as emacs.
Despite my qualms about memory use and latency, VS Code is a fully programmable editor just like Emacs, except using Javascript in place of Lisp. I don’t see much of a difference, except that JavaScript is much more popular (and thus the VS Code ecosystem develops faster) and Electron is a much more modern runtime, which enables easier integration of visual tools.
I think rather than criticizing Code all the time, we should look and learn. Clearly, Code is doing a lot of things right. And it’s not just the web dev crowd. I have seen a lost of Rust folks go to either Code or IntelliJ.
https://code.visualstudio.com/docs/languages/cpp
https://code.visualstudio.com/docs/languages/java
https://code.visualstudio.com/docs/languages/csharp
https://code.visualstudio.com/docs/languages/go
https://marketplace.visualstudio.com/items?itemName=rust-lan...
Yeah, about that. What do you think those extensions do? Do you think they all cross-compile to Javascript and plug into the famed C-bindings for React? :-D
VS Code is used for a lot of things these days.
I agree that VSCode is unlikely to reach the level of emacs in terms of being a fully programmable environment. But what it does offer is an easy and modern out-of-the-box experience.
MS has done an amazing job optimizing VSCode.
> Given this I doubt it will be anywhere as programmable as emacs.
Customizing can be a curse. Seeking it purely for the sake of customizing is an harmful poison. VS Code has some areas for improvement, but it's good enough as it is now. It doesn't need to be as programmable as emacs.