I can't say your article was bad, in fact it does indeed look like an honest attempt to compare two technologies.

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. It simply scales a lot better. It's much more flexible. It integrates a lot better with other tools which programmers are used to working with.

Here are a few points answering some extracts of your article:

- 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. 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. 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.

- Later you also state that using XML is practically useless, that it is akin to "trying to shoot mosquitoes with ICBMs". 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 ;)

- 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.

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.

- 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.

- "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.

- "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. 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. 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.