EDIT: Seems to be answered in the FAQ: "We have decided to use the Canvas object as the main backend for now because it is faster than SVG and allows us to implement and optimize our own Scene Graph / Document Object Model. We will be offering SVG (and hopefully PDF) importing and exporting in the future."
But it seems hard to believe that doing vector->bitmap rasterization in JavaScript is going to be faster than using the browser's SVG implementation (written in C++).
It was also abandoned as soon as Adobe acquired Macromedia, and thus Flash, meaning that there was no longer any reason for Adobe to push for a Flash alternative. There have never really been any good implementations, and it seems as though the spec wasn't written by anybody who'd have to eventually write an implementation.
Raphaël on the other hand, provides a simple system for making relatively "static" vector images with very good support for a lot of browsers (IE6 support, even). If you need user input, I think I would've tested out Paper and most likely ended up with that.
So basically: Raphaël for vector images that may be scaled and simple, dynamic images. Paper for animations and e.g. games.
If you have a similar situation on your site/application, I think it's perfectly reasonable not to support anything other than modern browsers, but you have to look at your own stats.
RaphaelJS has IE covered.
Given how clunky SVG can be, it's surprising that this technique works so well. I believe the performance gain comes from batching everything you want to render into a single ginormous round trip between JS and native code. With Canvas, you don't have that option, so you have to cross the grand canyon with every call. The equivalent in SVG would be making a series of tweaks to the SVG DOM, and that's even slower. Much better to rebuild the entire DOM yourself in text and overwrite the old one.
As a bonus, you can take the same approach in IE using VML. Though the markup is different, the SVG and VML models are close to isomorphic - not close enough to abstract over without an annoying impedance mismatch, but much closer than either is to Canvas. Thus this technique affords a good way to get graphics performance out of both the modern browsers (SVG) and the pre-9 IEs (VML) for as long as the latter are around.
I'm pretty sure Paul Irish's talk [1, 2] is where I read about this.
We've tried all the alternative techniques you mention (with HTML DOMs, that is - I don't think any of them work with SVG) and had disappointing results.
var a = new Sprite(); var b = new Sprite(); a.addChild(b); b.x = 100; a.rotation = 45;
Which ideally should rotate both a and b by 45 degrees clockwise, with b offset in the rotation around a's axis by 100 px.
All that aside, it does appear that in the newest version Grant has finally caught up to almost where my code was about a year ago, and since I haven't maintained the project for almost two years, that's saying a lot =) Great work Grant! If I had a serious HTML5 project, I'd just loooove to use your code for it =\ hah. Although I'm sure if one of those arises I could write something better in a few hours.
The trouble is, right now there is still nothing to be gained from writing something on a Canvas. It's too slow to play on an iphone, and there's no point in using it on a desktop when you can use Flash. And now anybody can release a game in html5 w/o any coding whatsoever, guaranteed. Grant: We are both pissing on the same lamppost in hopes of adding a tiny pile of sodium to it. Who gives a fck. Seriously, God Bless, just "rule the universe in HTML5". I only wrote my code a couple years ago to prove it was slower than the same thing in Flash. You want to make a life's work out of it? 3.2 major revs? Go ahead man.
[EDIT] Slightly sharper eyes.
Wouldn't it be great if someone did all the RaphaelJS examples in PaperJS, and vice versa, so we could compare performance and ease of use?
