Snap – A JavaScript SVG Library(snapsvg.io)
snapsvg.io
Snap – A JavaScript SVG Library
http://snapsvg.io/
59 comments
There's a great little node.js-based tool called SVGO for removing the fluff and optimising SVG files: https://github.com/svg/svgo
Check your mobile device performance with two quick demo links:
snap.svg coffee demo (click wheel to animate) http://snapsvg.io/demos/#coffee
d3.js chart demo (click buttons to animate) http://bl.ocks.org/mbostock/3943967
snap.svg coffee demo (click wheel to animate) http://snapsvg.io/demos/#coffee
d3.js chart demo (click buttons to animate) http://bl.ocks.org/mbostock/3943967
Wow. Snap looks beautiful. Nice one, Dmitry.
I've been enjoying working on my own SVG library, Pablo[1]. It's inspired in part by the fun I've had using Raphael, and wanting to explore what can happen when SVG is a first-class citizen of a library.
[1] http://pablojs.com
I've been enjoying working on my own SVG library, Pablo[1]. It's inspired in part by the fun I've had using Raphael, and wanting to explore what can happen when SVG is a first-class citizen of a library.
[1] http://pablojs.com
When I added the ability to import existing SVG images into Pablo, and to export the generated SVG in different image formats[1], I was pretty thrilled by the possibilities of having a JavaScript bridge between the design tools and the web app, the designer and the developer. And I see that Snap is also totally aligned to this kind of interaction between the web app and the external graphics tools, like Illustrator, Inkscape and SVG Edit.
The obvious next step is for a drop-dead simple visual interface to choreograph the graphics and the animations, with hooks into the rest of the JavaScript application. It could might be a game, interactive art, a visualisation or anything with graphics. Flash is dead, but there is nothing that exists for the open web that is as intuitive and fun to use as the Flash IDE was.
It must be just a matter of time before a tool as brilliant as the Flash IDE comes along for the open web, and I can imagine it makes a lot of sense for Adobe to be in on it.
[1] http://pablojs.com/api/#Import-Export
The obvious next step is for a drop-dead simple visual interface to choreograph the graphics and the animations, with hooks into the rest of the JavaScript application. It could might be a game, interactive art, a visualisation or anything with graphics. Flash is dead, but there is nothing that exists for the open web that is as intuitive and fun to use as the Flash IDE was.
It must be just a matter of time before a tool as brilliant as the Flash IDE comes along for the open web, and I can imagine it makes a lot of sense for Adobe to be in on it.
[1] http://pablojs.com/api/#Import-Export
Snap.svg being able to parse existing SVG:s I've generated with Sketch is totally awesome. Even more awesome would be the day when Sketch lets me play around with animations and timelines and then generate Snap.svg instructions.
Are blend modes other than "normal" usable in browser SVG yet? https://bugzilla.mozilla.org/show_bug.cgi?id=437554
I don't see the animations on iOS 6 and Android mobile devices. Why not?
According to this advanced SVG is not supported by Android.
http://caniuse.com/#cats=SVG
http://caniuse.com/#cats=SVG
Be sure to also follow our Twitter account @snapsvg for updates!
-JD @jonathanAdunlap
-JD @jonathanAdunlap
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/
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.
I came across the snapsvg announcement in a Tweet by the creator:
https://twitter.com/DmitryBaranovsk/status/39305298289322393...
> Here we go: new SVG library from Adobe by yours truly Snap.svg. Snapsvg.io
I didn't know Dmitry was Raphael's creator nor that he was working for Adobe. So all I saw was "Adobe" and thought "Flash" and then, "Nah"
https://twitter.com/DmitryBaranovsk/status/39305298289322393...
> Here we go: new SVG library from Adobe by yours truly Snap.svg. Snapsvg.io
I didn't know Dmitry was Raphael's creator nor that he was working for Adobe. So all I saw was "Adobe" and thought "Flash" and then, "Nah"
Adobe seem to put out some pretty sweet HTML5 stuff. They know flash is going and are jumping on the next big thing in a healthy way.
That IDE he's using in the video is called brackets[1] and it's originally from adobe. I'm watching it closely to jump from sublime to it.
[1]: http://www.brackets.io/
That IDE he's using in the video is called brackets[1] and it's originally from adobe. I'm watching it closely to jump from sublime to it.
[1]: http://www.brackets.io/
I hear you on the Flash stigma, but you have to figure an open source library written in a widely used language to interact with an open standard that is largely adopted won't make you suffer the same as Flash?
Suffer the same fate as Flash?
The fate of sustaining comfortably for more than a good decade you mean?
The fate of sustaining comfortably for more than a good decade you mean?
?? I never wrote "Suffer the same fate as Flash". Please reread my comment. I was referring to the previous poster's apparent pain with Flash. Not the fate of Flash itself.
Sorry then, I guess I picked up a subtext which you (or the grandparent post) did not intend.
Why not just release a new version of RaphaelJS and stop supporting anything before IE9?
He now has two very similar (but not compatible) libraries to support.
Raphaël.js is great, btw.
He now has two very similar (but not compatible) libraries to support.
Raphaël.js is great, btw.
I saw Dmitry's presentation yesterday over SnapSVG.
Raphael was, and is, meant to support older browsers. This comes with a cost of not being able to fully use everything SVG has to offer. Thus, Snap was born. He simply can't put everything into raphael to make it compatible with older browsers.
Raphael will still be getting bug fixes as the come in but is overall feature complete. In fact, Snap shares some of the same code raphael has, so maybe some bugs found in snap will be fixed in raphael as well.
Raphael was, and is, meant to support older browsers. This comes with a cost of not being able to fully use everything SVG has to offer. Thus, Snap was born. He simply can't put everything into raphael to make it compatible with older browsers.
Raphael will still be getting bug fixes as the come in but is overall feature complete. In fact, Snap shares some of the same code raphael has, so maybe some bugs found in snap will be fixed in raphael as well.
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.
Well that is what he said. But I believe having created Raphael.js in 2008, much before svg.js existed, also influenced his decision.
why not forking then ?
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 <ellipse> instead of a <circle> to increase code reuse between the circle and ellipse shapes[1]).
[1]: http://documentup.com/wout/svg.js#elements/circle
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 <ellipse> instead of a <circle> to increase code reuse between the circle and ellipse shapes[1]).
[1]: http://documentup.com/wout/svg.js#elements/circle
I've found svg.js unusable for any project I've had as it requires all svg content to be created with svg.js and no imports.
why not edit it? it's open source.
Is svg serialization supported? I looked in the doc but couldn't find anything.
*Edit - toString()?
*Edit - toString()?
I feel like whenever one of these gets posted, it should have a compare / contrast with d3.js
The OP's description makes it pretty clear. This is a library that seems specifically geared toward those who create SVGs in programs like Illustrator. That it is described as "jQuery for SVGs" should imply that it serves a different need than D3, as one usually does not call or think of D3 as the "jQuery for SVG data visualizations"
The moment we start calling things "the jQuery of..." we're no better than startups that are "the Facebook of..." :)
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.
Agreed. And, I think it would be helpful (and increase credibility) for the Snap creators to include a comparison with D3.js at http://snapsvg.io/about/.
I had a really time figuring out what this is, but the "Getting Started" page shows off the API a bit. Wonder why they didn't just call it Raphael 3.0.
Raphael has a really complex abstraction that does loads of magic to make it work on IE.
So I'm guessing this way they can map directly to SVG and not worry about breaking APIs and compatibility.
So I'm guessing this way they can map directly to SVG and not worry about breaking APIs and compatibility.
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.
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
There's an awful lot of Javascript backing that animation, I can't see where it's being turned into SMIL. At the very least it's definitely not static on the page, since the definition of the animation is entirely in JS: http://svg-wow.org/camera/camera.js
Does it write SMIL somewhere near the end and then let it run, or does it just run in JS? Skimming through I couldn't tell, but I don't really have time to read more closely.
Does it write SMIL somewhere near the end and then let it run, or does it just run in JS? Skimming through I couldn't tell, but I don't really have time to read more closely.
Some JS is still used, certainly. However you can define the animation steps, timings, recursion, panning, zooming and many other facets purely in SVG/SMIL. When I wrote a financial world map visualization and drill down tool, 95% of the animation logic was in SVG/SMIL. The JS just called start/stop on the various animation elements.
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.
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.
This library really looks great; I was wondering if charts (financial, statistics,...) are supported, for example, by connecting to data sources in JSON, etc
I wouldn't mind taking a closer look at that. They do have a data API to store individual key value pairs http://snapsvg.io/docs/#Element.data
Definitely different than what I'm used to in D3js, but worst case scenario you would have to loop through each key value pair. Worth testing out.
Definitely different than what I'm used to in D3js, but worst case scenario you would have to loop through each key value pair. Worth testing out.
You're right, noahmarc, it's the same for me, I'm now too used to working with D3j, that I definitely need to find my way in Snapsvg library, as it really looks promising; maybe it'd be better to arrange a high level specialized class library to handle not only worst case scenario, but even common chart functions, as the Api itself looks quite low level code...
This may cause confusion with the Snap Framework [1].
[1] http://snapframework.com/
[1] http://snapframework.com/
These two products are far from the only ones to use the name "Snap."
Or the snap visual programming language:
http://snap.berkeley.edu/snapsource/snap.html
today i recovered this http://web.archive.org/web/20080426161839/http://www.fragmen... via waybackmachine. i coded this in 2006 (its optimized for IE6 and the (at that time cutting edge now for a long time deprecated) adobe svg plugin). basically a LOGO like language in svg and js.
the good news is: it still works (webkit), the bad news is that i still dont believe that SVG is the future. fool me once ...
the good news is: it still works (webkit), the bad news is that i still dont believe that SVG is the future. fool me once ...
Care to share why?
personal disappointment is pretty high up on the list: i was an early adopter SVG ninja, i believed in the revolution, and the revolution didn't happen.
and i understood why: SVG is a technology invented and specified by a committee built upon a technology invented and specified by a committee (XML). now combine this with the most anarchistic technology in the internet, i'm talking about the one technology that is still untamed in it's raw from, mischievous and sometimes plain dumbevil in it's details, yes, i'm talking about the DOM. that's why working with SVG always felt clunky and massochistic to me.
so if you touch SVG always use a high level clever abstraction. and well this seems the point of snap.svg. maybe i will give it another try. but the thing is, whenever i use a high level abstraction i will sooner or later go down into the pits again, because i want to know how it works and whatever else i can make it do, and then i will probably hate myself again for giving svg another shot....
and i understood why: SVG is a technology invented and specified by a committee built upon a technology invented and specified by a committee (XML). now combine this with the most anarchistic technology in the internet, i'm talking about the one technology that is still untamed in it's raw from, mischievous and sometimes plain dumbevil in it's details, yes, i'm talking about the DOM. that's why working with SVG always felt clunky and massochistic to me.
so if you touch SVG always use a high level clever abstraction. and well this seems the point of snap.svg. maybe i will give it another try. but the thing is, whenever i use a high level abstraction i will sooner or later go down into the pits again, because i want to know how it works and whatever else i can make it do, and then i will probably hate myself again for giving svg another shot....
That's like saying you don't believe in memory allocation and pointers because they're "untamed" and "mischievous". Sure, low-level APIs/formats are a pain to work with, but that's the whole point of abstractions like this. If you hate yourself for learning how something low-level works, that sounds like a personal problem. :)
Nice and being made by Raphael author certainly does not hurt, still, the examples section could really do with bit of work: out of the 4 examples only 3 works proper for me and only the simply coffee maker and mascot bits are really smooth. The game is jerking about and not working proper on FF24: http://snapsvg.io/demos/#game
[deleted]
SVG integration with JS and the DOM has been elusive and underdeveloped in the past. Between this and d3, there's finally a lot happening in this space. These are very slick libs, they are thorough and comprehensive with very sophisticated authors.
I have capable and deep server-side SVG generation libraries I've written for CAD/CAM applications. I've always wanted to use them for generating all-or-mostly SVG web UIs. I can generate an SVG view straight from a model, and it's not an HTML+CSS cludge. The SVG's relationship with the data object is much more clear. With better JS manipulation support from libraries like this, the possibility of a rich and full-featured implementation is closer.
Not to mention that the browser vendors are FINALLY putting effort into truly supporting SVG, after 10+ years. It's good to prod them in this direction by demoing. Maybe we can help encourage an SVG-support vendor battle like what's going on for JS engines.
Time for me to get started on open sourcing my libs. They need to be completely broken out and made more general but I think it's time to join in and support these excellent efforts.
I have capable and deep server-side SVG generation libraries I've written for CAD/CAM applications. I've always wanted to use them for generating all-or-mostly SVG web UIs. I can generate an SVG view straight from a model, and it's not an HTML+CSS cludge. The SVG's relationship with the data object is much more clear. With better JS manipulation support from libraries like this, the possibility of a rich and full-featured implementation is closer.
Not to mention that the browser vendors are FINALLY putting effort into truly supporting SVG, after 10+ years. It's good to prod them in this direction by demoing. Maybe we can help encourage an SVG-support vendor battle like what's going on for JS engines.
Time for me to get started on open sourcing my libs. They need to be completely broken out and made more general but I think it's time to join in and support these excellent efforts.
I just watched some demos of this at the HTML5 Dev Conference - there are some cool uses.
The game on the PBS homepage uses a prototype version of the library:
http://pbskids.org/
The game on the PBS homepage uses a prototype version of the library:
http://pbskids.org/
In a comment on a thread about SVG libraries recently, here on HN, I opined that the world was long in need of a library that takes pre-made, artist created SVG and manipulates it: a jQuery for SVG.
And here it is and I am very grateful. Thank you, Dmitry. Thank you, Adobe.
We also need a world where once again Adobe create great open technologies and fund their development by building superb commercial tools for them.
I eagerly await new tools that work with Snap!
And here it is and I am very grateful. Thank you, Dmitry. Thank you, Adobe.
We also need a world where once again Adobe create great open technologies and fund their development by building superb commercial tools for them.
I eagerly await new tools that work with Snap!
One problem with intensely declarative content is bad naming, verboseness and strange groupings/ordering. Silverlight had this problem and SVG has it a bit in terms of content from other programs like Illustrator, SVG exporters etc. Adobe will probably be developing tools to edit this maybe? SVG support is still a little lagging and the web is missing vector frameworks since Flash has been sidelined with mobile.