draw.io VS GoJS, a JavaScript Library for HTML Diagrams

Never heard of Backlight Gem, sounds like a flashlight up your ass... Use this, it's free: https://www.drawio.com/

Just wanted to mention this here. You don't need a PC with lots of resources these days. Anything that can run a browser can also be used to edit images, create graphics, or even resumes. I think with those tools, you could even use a crappy library PC as long as it has a modern browser running.

Protip: get draw.io if you want to edit that file. Or just use the online https://www.drawio.com/ (previously diagram.net?)

On work, I use mostly tools like Draw.io and some colleges more Excalidraw (looks more fancy but less powerful). Those are easy tools to create a diagram with existing extensions for VScode. This helps to create an editable diagram which can be saved as an image. I like to use to save my draw.io file as a *.drawio.png file. So I can open it with draw.io to edit and when viewing the file from a browser, you see the PNG image. In this case, I never forget to export the latest state into my docs.

We get asked sometimes to add features to support new kinds of exports, e.g. to create network diagrams or to integrate with Home Assistant. Some time ago, we made the Fing Desktop and Fingbox Local API free for everybody to play with their device data locally. No cloud involvement, only local secret authentication needed.

https://github.com/jgraph/drawio/discussions/3309 asked here too, is this broken?

See https://github.com/jgraph/drawio/wiki/Getting-Support for official routes to get support.

Check this: https://github.com/jgraph/drawio

Awesome! Next please add a collaborative/multiplayer mode ❤️ In every team you want to have the chance to work together on a flow diagram. Even draw.io does not support it until now, so if you get it working that would be huge news and a USP for Svelvet: https://github.com/jgraph/drawio/issues/1396

used goJS in one project and konva in another

I built GoJS, which is one of the most popular commercial JS diagramming libraries: https://gojs.net

I built carefulwords, a very fast thesaurus and quote site for inspiration, used by... tens of people a day. Eg: https://carefulwords.com/gift https://carefulwords.com/solitude

I mostly made it for myself, me and my wife use it all the time. I am slowly editing down the thesaurus to managable size.

I built a 12x16 "Goose Palace" barn out of local pine timbers, which taught me timber framing, and taught my tiny baby who turned 2 years old while doing it that this is just the kind of thing that people normally do, build barns in their driveway. Some context: https://simonsarris.substack.com/p/the-goose-palace

Some photos of building it with the baby: https://twitter.com/simonsarris/status/1584169368203956225

I designed my house, and have been writing extensively about that. Maybe this is the most impactful, since photos of it are all over Pinterest and other sites, now. The first post on that: https://simonsarris.substack.com/p/designing-a-new-old-home-...

I am not sure what is most impactful. Maybe ultimately it is building my family.

I made a pull request for GoJS (https://gojs.net)

I have been building this canvas-based graphing library since 2011, and it contains a good number of features around customization and interactivity that are not found in other libraries. It is commercial for non-academic use however.

I am really surprised by this guy's opinion. I make GoJS (https://gojs.net/), a diagramming library written in TypeScript. The project began in 2011 and we converted it to TS in 2018. It's been a huge plus. The sole downside was the initial time it took during conversion, but even in doing so we caught bugs with incorrect input types, documentation mistakes, etc.

On our end, it enforces type safety better than the Google Closure Compiler. There has scarcely been a problem with type complexity that was not ultimately our fault. Just a couple minor things that TS amended later. For that matter the TS experience has only gotten better, generally.

On our users end, we can now give them a .d.ts file that's much richer and easier for us to produce to aid their autocompletion. And we can use that .d.ts file to ensure that all the methods we intended to expose/minify are getting exposed. The advantages with the .d.ts and documentation make it feel almost essential to me for library developers to consider TS.

TypeScript has only made debugging easier, much easier since it catches errors at time of typing unlike the closure compiler. The sole exception is that debugging is a bit slower since I have to transpile instead of just refreshing the browser. But I have tsc set to compile a relatively unminified version of the JS. But if the slowness gets to me, I can just edit the JS output until I solve the issue, and then carry those edits over to the TS. This has never felt like a problem, though maybe his library is significantly more complicated.

Feel free to ask me anything if you have questions about library design + TS.

GoJS might work for you: https://gojs.net

Although the focus of the library is interactivity and not setting up sequences of animation, but that is possible too.

My livelihood has been primarily building a Canvas diagramming library since 2010 (https://gojs.net), if anyone has any questions about 2D Canvas use in the real-world I'd be happy to answer them.

roundRect is great. Though you don't need 4 arcTo in order to make a rounded rect, you can use bezier instead (we do). Their example is also 1% amusing because they set the `fillStyle` but then call `stroke` (and not `fill`). I'll have to do some performance comparisons, since that's the operative thing for my use case (and any library author).

text modifiers are very welcome. It's crazy how annoying measuring still is, especially if you want thinks to look perfectly consistent across browsers. Though the chrome dominance is making things easier in one way, I guess.

context.reset is kinda funny. Most high-performance canvas apps will never want to use it. For that matter you want to set all properties as little as possible, especially setting things like context.font, which are slow even if you're setting it to the same value. (Or it was, I haven't tested that in several years).

I'm sure most users know this by now, but generally for performance the fewer calls you make to the canvas and the context, the beter. This is even true of transforms: It's faster to make your own Matrix class, do all your own matrix translation, rotation, multiplication, etc, and then make a single call to `context.setTransform`, than it is to call the other context methods.

I'm not the only developer but I made (and still make) GoJS, an interactive diagramming library for the web.

https://gojs.net

Most of its popularity is with large companies building their own internal tools where they need diagramming visualization capabilities (layouts, save/load, undo/redo, data binding, etc). So you won't see it too often in the wild, but under the surface it's used in every industry.

I love it, and I love HTML Canvas, which I wish was more popular.

I actually make a diagramming library for the web, called GoJS: https://gojs.net

So I make all kinds of diagrams, mostly as demonstrations. When developing an API itself, especially one where there are phases (objects must measure themselves and draw in a certain order, and not more than they need to), state machine-style and flowchart-style diagrams are awfully helpful.

GoJS