I find a bit strange not to have contributed in svg.js ( http://www.svgjs.com/ ). Not Invented Here ?
Same question. I was using Raphael.js earlier and had to switch to svg.js for SVG specific features, and it's quite a nice library, though perhaps not as developed as Raphael in terms of documentation.
The only possible conflicting goal I can imagine is that one of svg.js' goals is to be as small as possible (e.g. generating an instead of a to increase code reuse between the circle and ellipse shapes[1]).
This is awesome. One of the problems I've had with Raphael is that it's explicitly not supposed to be an SVG library, so SVG-specific features tend to go unsupported. SVG groups are probably the most obvious example of this.
Without knowing this fact about Raphael, I was about to reply to another comment prematurely. I was going to complain that having the same author as Raphael doesn't explain why Snap.js exists, instead of a better version of Raphael. Thank you.
There's a helpful "Why Snap?" page that points this out, as well as that it supports animation.
Libraries like this come up on HN on a regular basis it seems. As I read through the site I kept asking myself "this looks great and all, but can I depend on it in the long term?". Then I came across the "about" section where it says it was created by the creator of Raphael.js[1]. Say no more.. I'm in! [1] http://raphaeljs.com/
Hopefully it doesn't get acquired by Sencha as well. I'm done with all things Sencha.
Without knowing this fact about Raphael, I was about to reply to another comment prematurely. I was going to complain that having the same author as Raphael doesn't explain why Snap.js exists, instead of a better version of Raphael. Thank you.
There's a helpful "Why Snap?" page that points this out, as well as that it supports animation.
Alas, I was suffering from TLDR syndrome. I will definitely give Snap a try, along with seeing if it plays well with Raphael for graceful degradation for older browsers.
I feel like whenever one of these gets posted, it should have a compare / contrast with d3.js
This is a drawing lib, not a data binding lib. d3 is largely rendering agnostic. You wouldn't use them in the same way like you wouldn't compare contrast a car with an engine.
I find a bit strange not to have contributed in svg.js ( http://www.svgjs.com/ ). Not Invented Here ?
The author actually just gave a talk (actually finishing it) and he explained: he did not like the code style (svg.js does not use semicolons at the end of the lines). Well that is what he said. But I believe having created Raphael.js in 2008, much before svg.js existed, also influenced his decision.
This is awesome. One of the problems I've had with Raphael is that it's explicitly not supposed to be an SVG library, so SVG-specific features tend to go unsupported. SVG groups are probably the most obvious example of this.
Without knowing this fact about Raphael, I was about to reply to another comment prematurely. I was going to complain that having the same author as Raphael doesn't explain why Snap.js exists, instead of a better version of Raphael. Thank you.
That's the point, RaphaelJs is to allow SVG use on IE by converting it to VML.
Without knowing this fact about Raphael, I was about to reply to another comment prematurely. I was going to complain that having the same author as Raphael doesn't explain why Snap.js exists, instead of a better version of Raphael. Thank you.
There's a helpful "Why Snap?" page that points this out, as well as that it supports animation.
SMIL is the SVG animation markup. Sadly very few people have every used it. SvgWow.com has a bunch of great examples like:
http://svg-wow.org/camera/camera.xhtml
Without knowing this fact about Raphael, I was about to reply to another comment prematurely. I was going to complain that having the same author as Raphael doesn't explain why Snap.js exists, instead of a better version of Raphael. Thank you.
That's the point, RaphaelJs is to allow SVG use on IE by converting it to VML.
Aye aye, coupled with Modernizr, it should solve (most) use cases.