Live data from Hacker News

SVG vs. Canvas: Which technology to choose and why?

jointjs.com

1–10 of 12 posts

Re: SVG vs. Canvas: Which technology to choose and why?

#2
As a frontend developer, you are often faced with the difficult decision of what technology to use in your next project.

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

Re: SVG vs. Canvas: Which technology to choose and why?

#7
Glad to see a pro-SVG piece. There's a steady trickle of folks switching to Canvas, and frameworks using Canvas (Flutter). But there's so many pro user pro internetworking advantages to using a higher level DOM instead of code to drive your media. I'd love if SVG folks could figure out how to better share & show off what they did too.

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:

https://news.ycombinator.com/item?id=36217098

Re: SVG vs. Canvas: Which technology to choose and why?

#10
This is good. I learned some stuff.

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 . Yeah, you check it in the DOM, like everything else.

Post reply on HN