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.
I agree - I tried Raphael but actually found it a bit limiting. I can live without IE support (I can use Flex for that) so jQuery SVG looked like the better choice.
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.
I'm in enthusiastic agreement. I tried to use Raphael for a hobby project that required efficient scaling of a lot of elements, and I thought Raphael would be ideal for this. Unfortunately, Raphael's list-like data structure (I forget exactly what it's called) doesn't take advantage of SVG's natural advantages in this area. It loops over all the elements in the list and scales them individually, rather than putting them all in one <g> node and scaling that. It's horribly slow for large groups.
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.
I'd second this. We've been using GRaphael for the reporting graphs on MinuteDock, and we had to manually hack in a bunch of things - like rotating the labels on the x-axis correctly if they were too long, and even drawing both axes on some graph types.
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.)
Sorry to be pimping my own stuff, but for the moment I think Grafico is more mature/offers better charts than gRaphael: http://grafico.kilianvalkhof.com/ Worth taking a look regardless :)
When is this stuff coming to Android? I want it, now! It would be perfect for an Android game idea I had, but it doesn't appear to work. I could just write it in Java I guess...
Anyone have any comparison between this and flot or jqPlot? I'm going to be implementing client-side graphs on my site, preferably using JSON as my data format, and I'm trying to make sure I'm on the "right side of history."
Raphael.js definitely rocks. I've finished a little coding project (it's a visualisation of an algorithm; didn't release it yet, though) and it was really a pleasure to work with the framework. You can do really a lot of cool things with it. The demos on the Raphael.js page are also quite impressive, and run pretty fluid on almost every browser (my project runs pretty fast in Chrome, but loses it a little bit in IE, perhaps because of the layer added by excanvas). That said, I have to admit that I love Raphael.js, too. It's surely not the last time that I've worked with it.
Great link! I have looked into using SVG for mapping applications. It would simplify development of mapping apps. However, size of a country map with some detail can be pretty big, around 2Mb so it wouldn't play well on e.g. mobile apps where the vectors could come to use. Anyway, there are many free maps here to play with http://commons.wikimedia.org/wiki/Category:SVG_maps
One of the things that has been missing from RaphaelJS that annoyed me was the arrow function. They even mention it in their documentation, but as an empty function. I finally got my version working so I will hopefully post it on HN later tonight. Lots of math involved, probably why it was never done in the first place!
I have seen that before in another language, the box read:
"click here for your bonus".
Jokes aside, that's pretty good for so little code. Well documented too. Makes the previous language it was written in look like a slug.
SVG is currently supported in all major browsers except IE, and SVG 1.1 support is slated for IE9. (AFAIK, Chrome Frame also supports SVG, as a stopgap for pre-9 IE.)
Does Adobe Flash support exporting to SVG? Adobe should capitalize on all this SVG hype and make an advanced animated SVG / javascript editor, because there aren't any right now AFAIK.
I can't be the only one disturbed that the standard for graphics online is roughly the same as the standard for graphics on the desktop twenty some years ago.
Yes, a moving square, from a couple lines of code, that can be easily changed to a twirly throbbing square, and can be shown on anyone's computer or mobile phone in the world by sharing a URL.
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.
A moving square, from a couple lines of code, distributed to millions of computers, smart phones, other devices running various operating systems and zillions of different hardware configurations.
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.
What about printing? Does canvas maintain resolution independence like SVG? ... I.e., can you print your beautifully drawn graphs and expect to get quality output?
Not exactly. SVG syntax describes a scene, it does not draw on screen directly.
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.
Canvas is pixel oriented whereas with SVG you have a hierarchical document structure to work with.
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.
SVG is easier out of the box, but you can also use a "scene graph" JavaScript library to create an object abstraction on top of Canvas. In my experience managing the scene graph in JS turns out to be much faster than letting the browser handle it with SVG.
SVG is better supported and has some content creation tools already such as Illustrator and Inkscape. Also: SVG stuff can be used on IE (aparently...) via a flash conversion tool.
Anyway, for comparison, here is the jQuery SVG interface:
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.