Here's why Raphael.js and SVG totally rock.
trottercashion.com
trottercashion.com
http://stackoverflow.com/questions/588718/jquery-svg-vs-raphael
The version of Raphael I used at one point had to be in complete control from object 1 and could not import SVGs. So let's say I generate an SVG via graphviz and then want to make some of the nodes interactive (or at least animate). I get a good amount of tweening via the jQuery interface, including the ability to load up the externally created SVG.Anyway, for comparison, here is the jQuery SVG interface:
http://keith-wood.name/svg.html
Why have I used the SVG? It animates smoother in HTML4 on iPhone's Safari and on my linux distro's Firefox than when I tried canvas manipulations.More recently, I noticed the HTML5 canvas stuff being smooth for both. Still, the benefit of the SVG is having the ability to treat each object as its own DOM element, where you have to rig all that framework yourself for graphical objects you create on the canvas.
The only criticism I could make of jQuery SVG is that the docs often assume that you know a lot about SVG, but that is pretty minor.
edit: I should mention that I moved to jquery-svg and have been happy ever since. :)
Also, the article mentions that IE doesn't support the <canvas> tag. While this is true, you only need to add the excanvas JS library to use <canvas> in IE.
However, I do wish that protovis is based on Raphael and jQuery.
It's worth the effort though - works on iPhone/iPad out of the box, and is super snappy even on OS X (unlike most Flash charting solutions, including Google Viz.)
but the demos are pretty impressive.
I did want to add though: does anyone know why this is, or if it's slated for a future (2.2?) release?
This makes interaction with sprites pretty neat when you attach events to them.
It would seem that SVG has a bright future.
Oh, sweet, a moving square.
To get a moving square on the desktop twenty years ago took more lines of code, arguably harder to change to a twirly throbbing square, and usually copied to disk (or emailed) to show someone else by sharing the executable that may or may not run.
The last part is stunning and does not exist outside of browsers.
It is also more likely to get faster in the future, as browsers might implement GPU acceleration for it. I wouldn't hold my breath waiting for GPU acceleration for SVG, since SVG is not as easily mapped to drawing primitives, like Canvas is.
When you animate an SVG image, you update the DOM. The browser then needs to parse the DOM (attributes) again, then clear the screen and draw each element again. This is a lot more work than just mapping the drawing primitives of Canvas to the lower-level GPU functions.
Check this presentation for the two technologies compared in terms of how much work is required for animation: http://www.slideshare.net/madrobby/i-cant-believe-its-not-fl...
I guess it's good to have the choice though - for some things Canvas looks a good choice, for others SVG is better.
There's also a toggle in Firefox's about:config that turns on hardware acceleration on Windows.
So if you want to do an online image editor I'd probably go with canvas. For something that needs multiple objects with their own individual event handling - SVG looks a lot easier to me.