| The point of this article is to steer people away from GoJS. It reads as a dupe of a prior article of theirs: https://www.jointjs.com/blog/jointjs-vs-gojs but without any direct references to GoJS. The emphasis on the foreign object tag in this most recent article ties in with their latest release, in which one of the selling points is the ability to embed HTML elements inside SVG elements. What they fail to mention is that an even more flexible approach, not supported by JointJS, is to render HTML elements as the vertices and embed SVG inside the HTML. The article does make some valid points but on the whole comes over as slightly disingenuous. "A painful amount of code" has to be written to support a `:hover` class with canvas may be a true statement, but done properly it only has to be written once, and most likely not by the customer of a diagramming library vendor but by the vendor themselves. It's true also that a basic canvas setup "doesn’t preserve clarity when resized" but I've read a few things written by the author of GoJS in which a clear strategy is presented to mitigate the issue. There are many other small points like these peppered throughout. Regarding accessibility, I have also wondered about this since seeing Google switch over to canvas for docs. It seemed extremely unlikely that they would have done so and abandoned accessibility, and a cursory search shows that they're currently using a 'side DOM', ie. maintaining a DOM that contains only accessibility stuff. This is again not something that a user of a library should expect to have to maintain themselves. You'd expect to add a vertex to some library and for that library to handle the side DOM, using accessibility information that you've provided, and that you would have needed to provide had you used a library that renders to SVG instead. |
I don't think you can deny that any article, demo, post, etc that appears on a company website is inherently some kind of self-promotion. It's the same for every company. The important thing for us is that the content can stand alone if it appears under another name, on another website. In that sense, we are happy with it, and think the content is reasonable and valid. We use SVG, and are satisfied with our tool of choice. There isn't any conspiracy here.
The article doesn't focus on using libraries, because we wanted it to be accessible to everyone, including beginners. If we want to write about a specific library, we would do so in a straightforward and forthright manner just like in the article you linked here. That article was born out of questions from our customers which is why it covers additional stuff like prices, support, open-source, etc. Again, nothing too strange about that. Both articles do have some crossover in terms of themes, but so does every comparison article about SVG and Canvas, so it's not surprising. There are only so many things to discuss.