“I don't pretend to be unbiased either, it's probably impossible. However I've worked on large projects using both technologies, and believe me I know why I'd pick SVG blindfolded any day now.”
You are free to choose your tools, and so am I (unless our clients decide otherwise :-)). Never in my article did I say that SWF was better than SVG. The whole point of this article is to make the readers think and consider their options. If they come to the conclusion that I’m wrong, that’s fine.
I too use SVG--whenever I see it fitting the job better than other solutions. I don’t worship the XML idol, I only use certain technologies where they make a positive difference.
“- In the section "SWF Is Unreadable to the Human Beings, But Does it Have to Be?", you state that being able to read the source of an image format is not a feature, irrespective of the content. I beg to differ. SVG, despite some darker areas, is very much readable. “
Sure, but not without training. You cannot sit someone who’s never seen the SVG specs in front of the source of an SVG file and expect him to understand what it does. He wouldn’t understand SWF either, even if it was decompiled for him. I hope you’ll agree that readable != easy to understand (without proper training).
“That doesn't matter for garden variety animations, but as soon as one wants to develop a complete and complex application, it is of incredible help to be able to simply peek at the code and see where the bug is. For debugging, for clarity, it's a must. The fact that one can in fact edit SVG in one's text editor is also a feature.”
I agree, but for me it’s not much of an Earth-shaking advantage. When I see a bug in my SVG code, I still need to go back to the code that generates it (I very rarely code SVG by hand). Similarly, when I find a bug in an SWF file, I go back to the code that generated it.
In both cases I find the bug and go back to the application that generated it. So what makes SVG “better”? You can edit PostScript in a text editor, but are you seeing many people doing it. Anyway, SVG used in enterprise environments is not created by hand, but generated and parsed by machines. So can be SWF.
“Obviously, no one is going to create complex vectors that way, but there's a lot more to SVG: style, positioning, animation, scripting. All that can be -- and in fact is -- typed straight into a text editor. I know that's the way I do it, and I know it works. Using the object inspector in an authoring tool just can't beat that. “
That’s just a matter of choice. When SVG will be created with advanced authoring tools, it will become increasingly harder to dig through code using just a text editor. Remember how people complained that FrontPage cluttered HTML documents with tags that did nothing but take up valuable space? I bet the same will happen with SVG authoring tools. And then, we’ll need those object inspectors, or whatever gizmos we’ll be given by developers :-)
“- Later you also state that using XML is practically useless, that it is akin to "trying to shoot mosquitoes with ICBMs". “
No, I am not saying XML is useless! I am only saying that there are applications where XML is more trouble than it’s worth. You may no like it, but XML is not the answer to every ill of this world.
“Again, that manifests a rather incomplete view of what can be done with vector graphics. As someone that has developed cartography apps where vectors were of a fairly high complexity, I can tell you that XML is a big bonus. As soon as you enter the XML pipeline you can reuse apps you know, apps you've worked with in other situations, which you can easily tune and predict. XML can package *any* kind of data, and producing SVG from an XSLT stylesheet being fed dynamically generated XML is trivial. It doesn't get any simpler. Take five weeks and a single developer to create a full-fledged interactive map editor in SWF. Then try the same with SVG as the target format. At that point you might get an idea of what I mean ;) “
I know what you mean. But there are many applications where vector graphics are can be safely rendered in SWF, because it makes them more accessible (at least, at this point in time). SVG is a _good_ choice for the enterprise, because it fits nicely into the flow of data--same tools, same semantics, same everything. But there is a point in the flow of data, where it has to be delivered to the public--those unwashed masses who consume “garden variety animations”. Would you rather ask everyone to download the SVG plug-in, or would you rather publish it as an SWF file knowing that your viewers already have the Flash Player plug-in? I am not saying one solution is better than the other, but it is an important question, and SVG is not always the answer to it.
“- You also make a dodgy comparison between SVG and any random XML format that stores data. You also state that the data can't be converted any further than to another graphic format. On both accounts you are wrong. SVG data can be meaningfully (and easily) converted back into other data that is not meant for graphic consumption. I've extracted data from animated paths to send them back to a server that would use them to feed a database. The user would create or modify a path, and the data would be used later to make all sorts of calculations, none of which had graphical displays.”
Yes, that’s very interesting, but you are talking about an application, and I was talking about using SVG as yet another vector graphics file format. In your case, you controlled every stage of the process. I am thinking about a situation when I’m being given an SVG file and a bunch of standard XML tools and I’m told to convert a SVG business chart back into a balance sheet. It is easer with XML, than with SWF or any other vector format, but that’s a really weird this to do. I was talking about using SVG as the “last mile” solution, you are thinking of it as a central point of you application.
Why am I talking about using SVG for such dumb tasks as storing vector graphics instead of being used as the foundation for killer applications? Because it will take time before people learn to use it that way. Do you remember the time when anybody who bough a 100--page book on HTML could make thousands a month doing awful HTML web pages? Do you know why it was possible? Because HTML was easy. It will take more time to train tens of thousands of web designers to do with SVG what they now do with Flash. And until that happens, they will go the easy route and create vector images using their favorite vector illustration program and embed them into their HTML/XHTML pages. Not quite what we’re hoping to achieve with SVG.
SVG needs a true killer app that lets people do all the cool things that it promises like mixing XHTML, MathML, SVG, and other “fooMLs”, and DHTML and whatever other acronyms we can throw into the XML alphabe soup. SVG has a great potential but it needs a truly new kind of authoring application, something that goes beyond Flash MX, something that integrates all those markup languages and ECMAScript. You cannot tinker with it in vi or emacs forever!
SWF looks dated, but look at what you can do with it with the right tools. The day we can do the same (and more) with SVG, people will dump Flash and SWF. Not before.
“And at the same time SVG is a target language. Even if it were hard to extract non-graphical data out of it, the simple fact that it is XML means that you can produce it using any tool in your XML toolset, amongst which XSLT.
That brings us directly to your statement according to which "This is, after all, yet another variation on the Web page templates theme, albeit more complex." That is very very true. With SVG you can use the tools that you have always used, that you know and cherish, that you can extend easily. You can use XSLT, Perl, PHP, JSP, CFML, ASP, hell, you can use bash if you want. And it'll just work. No need to learn, set up, understand, and eventually debug new tools. Everything you know as a web developer can be immediately relevant. That's not a reason to think that SVG and SWF are equal, but a rather good one to prefer SVG.”
By all means, use the tools you know!
But you must consider one thing: if SVG ever becomes as popular as SWF for Web site/application design, it will be used by designers who couldn’t care less about all of the advanteages brought by XML (e.g. structure, namespaces, and other paraphernalia), but they will care about things such as the “look and feel.” They will not go near the tools you know, but will expect to use the tools they know. Excel won because it was similar to 1-2-3 and made it easy for the users to exchange spreadsheets with 1-2-3. Similarly, if SVG is to win the designers’ and developers’ hearts, it ought to make it easy for them to migrate their Flash skills to the XML promised land. Again, it needs a killer app.
“- Regarding mobile devices, SVG is already there in prototypes, and interests the giants of the sector (which have contributed very actively to the spec) more than SWF. We now have SVG targetted for mobiles and a host of players implementing the spec, which I expect to see on the market when the usual innovation time is over (it often takes 12-18 months for a new mobile to hit the real market). And that's without counting the SVG-Binary efforts”
But these efforts don’t address the real problem faced by the developer who’s being asked to create the same application for different platforms. Today, he essentially repeats his work over and over again. I have yet to see a solution that truly helps developers write one application and deploy it on many platforms. And no, I don’t consider Flash Player to be the answer to my dreams. I see two solutions to this problem: the mobile hardware catches up with the desktop (yeah, right!), a technologically inferior--but inexpensive to implement--solution will win (see cHTML and i-mode).
It’s good to see SVG being cut down to work on mobile devices, but we have yet to se any killer apps using it. As for SVG-Binary, it’s nice to see that this project is taking a leaf from the SWF’s book. As I wrote in my article, I am hoping SVG and SWF will meet halfway, eventually.
“- "SWF can carry more data encoded using the same number of bytes than SVG. Compared to SWF, SVG is a bandwidth hog." I don't mean to be rude but that's just blatant ignorance, of the kind I would hope not to see published on such a high quality site. SVG enforces gzip encoding on its players. It has been proven and shown over and over and over that when equivalent documents are expressed in SWF or SVG, gzipped SVG comes out between 5 and 30% smaller than SWF, most of the time closer to 30%. Add to that the fact that gzip is free, tested, and almost omnipresent -- which is not the case of SWF toolkits however good they may be -- and you have clear superiority of SVG on this side. Gzip is even available within most web publishing toolkits such as AxKit so that you don't even have to worry about it. And again, if you wanted to you could use bash to gzip your output... If you want your comparison to work, then compare SVG with FLA in terms of size, and then get back to me. Again, I don't wish to appear harsh but FUD really tends to piss me off. “
No offense taken, but you should know that Flash MX can compress SWF’s using--surprise, surprise--gzip compression. Also, internally, earlier version of SWF did use the gzip algorithm to compress bitmap image data. As for other ways to make SWF’s smaller, you can share the same JPEG encoding table among multiple JPEG images. The point is, you can fine-tune and optimize SWF quite a bit. Go, read the SWF specs. I am certain that you can produce SWF files smaller than their SVG equivalents.
“- "the Web design community have chosen Flash and that's a fact". No contradiction here, but does it matter? For certain, people that create more or less garden variety animations do not need to switch to SVG, and in fact they probably shouldn't, yet. “
Yes, it does matter. You don’t tell the designers of your promotional brochures to use the tools you like—they get to choose their tools. It’s a similar thing with web designers working on your website—if they choose Flash, then you don’t go to them and tell them to throw Flash away just because you think SVG is better. If they know Flash better than SVG, and can achieve the same effect with Flash, they will use it.
Never underestimate the power of huge numbers of people using technology that you see as inferior to what you are using. I don’t wish it, but it may happen that SVG with its XML goodies will be confined to the enterprise ghetto, just like SGML, which never really caught on outside its own town. It had to be “dumbed down” and become HTML, before Joe Public starter using it (and some still don’t know they’re using SGML :-))
“On the other hand all the applications that could have used vector graphics previously but didn't or did so at huge costs -- and trust me I've been there -- because SWF, however well exposed by a library, is a painful format that's alien to most developers are now becoming possible. “
Of course, SVG has great “vector enabling” potential, but it also has a long way to go before we can “package” it the way we can SWF.
SWF is optimized for machines, not for humans, that’s why it is “painful”. One you master it, it becomes quite easy to work with, especially when you have the right tools. It was the same with XML before people understood it and developed nice tools to handle it.
“More than possible, they're being implemented. SVG will not take the world over through the small homepage and brochure websites. It'll take over through the enterprise (sorry for the horrible word) where it is already being accepted as a natural solution. I expect that from there it'll go over the border and flood the web.”
Maybe, maybe not. I try to remember the lessons of Betamax, or SGML—great ideas that failed in the “real world”.
SVG must win the masses or it will be confined to its own golden cage--comfortable, but with not many friends to talk to.
Believe me or not, I do care what happens to SVG, and I hope it will become as popular as SWF, because it is good to have a choice--but it will take time.