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.
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].
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?
?? 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.
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.
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.
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.
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.
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.
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 ...
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....
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. :)
Looks like a good replacement for the vector side of flash and is partnered with Adobe. The SVG looks very clean and it is nice to have it load SVG files and create on the fly. Also awesome that it is made by the developer of the Raphael library.
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.
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
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.
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]).
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.
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.
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"
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/.
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.
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.
This library really looks great; I was wondering if charts (financial, statistics,...) are supported, for example, by connecting to data sources in JSON, etc
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...
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.