SVG and Canvas Tags
Due to some very intriguing conversations over potential future projects, I have been very motivated to dive into the world of “drawing” in HTML5 and I would like to share the high-level view. So the following is not an in depth look at graphics frameworks but rather is a concise yet comprehensive perspective of the two incredibly awesome drawing tools available to front end developers: canvas and SVG (Scalable Vector Graphics). Oh, if only we had these tools ten years ago . .
The Similarities: Drawing
So before we go into all the differences, what do these two “new” tags have in common? Well they both allow a developer to “draw” programmatically and they both are supported by all modern browsers plus IE 9 and above. Animation is quite possible in both but there are clear advantages to either choice in different contexts. The canvas API is directly manipulated using JavaScript while JavaScript can be (and often is) used to manipulate the XML structure that is SVG. They both also come in pretty colors.
So basically, the two tags have little in common but that they both “draw.”
The Differences: Many
Core Code Structure
The most fundamental difference between SVG and Canvas is how they are stored by the browser. Canvas is simply a bit map and its JavaScript API helps you update all the lovely bits. This is useful when utilizing complex images (like from a Photo!) and allows you to save the image programmatically using the “toDataURL()” function. However, this requires a lot of bookkeeping and can be very slow when you are managing a “large” canvas.
See also: A quick Canvas on Mobile Demo
In contrast, an SVG graphic is communicated to the browser using a specific XML format describing an object model similar to HTML as it uses hierarchical system of elements with styles and attributes. This XML could be loaded from the server or there are many libraries that will help you build this XML on the fly. So unlike Canvas, SVG could be used without JavaScript, but that would eliminate much of its flexibility.
Core API
So really, the difference is not JavaScript (Canvas) vs XML (SVG) because you are probably going to use a JavaScript based library or at least your own scripts to manipulate the SVG XML as well. However, it’s important to note that the core APIs set out by the W3 consortium are quite different for both. Please note one reason there are so many SVG JavaScript libraries is that the core API is on crack:
Meanwhile, there is reduced crack usage for Canvas:
Relationship to the DOM
But don’t let me gloss over one of the most important advantages to SVG. With a graphic drawn in SVG, each element is truly a part of the DOM. So by simply grabbing reference (ID/Class) to some node within the SVG XML, you can, amongst other things, actually receive user events. In contrast, a Canvas element is really just a part of the DOM in its totality so you have to use alternative methods to determine if one part of the canvas was clicked vs another such as floating divs over the canvas area. So, if you need the user to interact with your graphic, there would be many advantages to using SVG.[1]
Resolution Considerations
Another major advantage to SVG is that it will have the same quality at any resolution because it is based on vector graphics. The arcs, points, lines and other “geometric primitives” will have the same relations to each other no matter how much you “zoom” as they are resolution independent. Meanwhile, the canvas tag is considered a raster graphic because it is based on a bit map and is therefore resolution dependent. So if you are going to be adjusting the size of the given area that the graphic tag is rendered in, there might be some serious advantages to SVG.
Animation
The differences between raster and vector graphics also affect the ability to animate. I have not done enough research to address the topic of animation in totality with these two tags but let’s consider the basics. In general, canvas is considered better for animation because the “fire and forget” updates to the bitmap require very little processing. However, that is assuming the actual amount changes to the bit map are relatively isolated. In contrast, if you are changing a graphic representing half of the full screen, you might be better off using SVG because you would be updating millions of bits otherwise. Its important to remember that processing requirements of SVG have nothing to do with the actual size (again, it is resolution independent) but instead is a product of the number of elements and their dependencies that would need to be updated. So some articles refer to SVG having “medium animation” abilities and I am surmising this is because using simpler graphics in certain circumstances provides significantly better performance. But Canvas is given the label “high animation” abilities because the more common scenarios require little processing time from the raster graphics format and is the much better choice.
All the Rest
The remaining factors you might want to keep in mind is that :
- Canvas has a 3D “context” (mode) available
- Text rendering is higher quality in SVG, but there are many reasons to use text in Canvas (see many of the Memes you see online)
- SVG is properly layered while you’d need two separate canvas tags to have a layered effect
Conclusion
So I hope you agree that both Canvas and SVG tags offer tremendous graphics capabilities to the front-end developer. Neither one is superior but both have different advantages. So for your most advanced needs, you might want to consider using both!
See also:
[1] Although some canvas based libraries will help you work around these challenges such as: http://kineticjs.com/
