SVG vs. Canvas: Which technology to choose and why?
jointjs.com
jointjs.com
At risk of sounding like those old CGM-Is-The-Only-Real-Vector-Format[0] guys, I'm coming down hard on the SVG side as well.
SVG's got problems - not gonna lie, I fight blown up SVGs every day, particularly those with thousands of parts - but those implementation problems (which are largely just bad design decisions) shrink in comparison to the basics.
The DOM visibility and the accessibility issues are the dealbreakers here.
I do want to underline a systemic limitation of hooking up your content to the Canvas train.
Both SVG and Canvas use primitives - boxes, dashes, etc - but if you are making publications with vector art, how much visibility do you have into whatever defines those primitives?
The SVG primitives are locked down to various issues/revs of SVG - you can at least say how different SVG dashes will be from, say, LockBoNorthRay's Mandated Official Sanctified Dashes (.1mm space/2mm dash or somesuch). And then you can design accordingly[1]. The Canvas primitives, I can't even figure out where their geometry is defined to even tell the difference so that I can get a grip on the problem. There's nothing I can point to when presenting a solution to homo executus. I have a funny feeling that Canvas users wouldn't even try and build something for a company that whips out rulers to measure dashes on a printed page.
[0] Who strangely all work for the same two software companies. What are the odds?
[1] Regardless of what the old crusty CGM guys say, yes, you can lock down SVGs and get full reportability via the DOM or, hell, via xquery. Waaahhh no SVG doesn't have an ISO WebCGM profile, oh no what do you do <concerned_face_pikachu>. Yeah, you check it in the DOM, like everything else.
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.
Right now Figma & Google Docs (for the doc itself, the chrome is almost all html) are the two posterchild apps everyone knows where canvas seems like an acceptable tradeoff. I think there's some valid uses, but it feels like a niche tool with huge downsides that I think most folks should avoid: keep your gui declarative, keep it legible in html, if you can.
Discussion on Felt switching to Canvas yesterday:
The last thing you want is to choose a particular technology and later realize that you should have chosen another option for one reason or another.
In our latest article, we compare SVG and Canvas and give you a fresh perspective on this choice based on over 10 years of experience in web development.
After reading it, you will have a better idea of: • The key principles of both rendering engines • The differences between SVG and Canvas • Accessibility of both technologies • Performance comparisons illustrated by specific use cases • Testing and how both technologies make developers' lives easier. • Utilizing foreign object as a way to create HTML-rich elements • The synergy of SVG and CSS • The impact of both technologies on other business areas such as SEO or coordination between team members