I've been working with SVG so much these past few months that I'd completely forgotten just how badly rotten SWF/Flash was.
SVG's a treat. To being with, it's all XML. That makes content generation (dynamic or static, even for the latter XSLT makes things extremely easy) trivial using typical ultra-powerful tools such as AxKit (I guess it's pretty much easy as well with templating systems). Debugging's easy, just look at the source that was output and see what's wrong.
SVG also supports all that SWF does, and much much more. Viewers are forced to support gz encoding (which means small files) and, should you need to throw in some raster pics, PNG and JPEG images (which guarantees that you can get your job done with no patent problem). Some things are not native, but all can be programmed into it. And of course, it benefits from all the usual XML things: availability of a huge toolset for parsing, validation, filtering... full-blown I18N, text based, strict syntax with high glue capacities, powerful extensibility (you can create your own extension syntax in a different namespace), metadata, and so on. Of course, I'm only scratching the surface here.
One thing I expected to suck about SVG was the fact that when one wants very elaborate client-side interactivity (anything less can usually be done using raw SVG or SMIL, ie pure and simple XML) it is normally programmed in EcmaScript (formerly Javascript, albeit without all the proprietary fudge). I'd been there in the web browsers, and didn't feel at all like going back.
Well I must say that I was pleasantly surprised with what I saw. When you don't have all the "working around browser bug and/or differing implementation" problems, it gets a lot easier already. When in addition you have a rock solid implementation of the entire EcmaScript spec, things are even better: arrays that actually have the ops you've come to expect with Perl, almost complete Perl regexen, not too bad string handling, asynchronous HTTP POST and GET, etc... Add to that the fact that Adobe implemented almost the entire SVG DOM (which is huge) full with events and all sorts of nifty shortcuts then manipulating SVG becomes a blast, and one can even forget some of the more painful shortcomings of EcmaScript (the major one being that it's a type-based language and not a class-based language, which has the nasty tendency of making everything global)
Also, you can create EcmaScript libraries which detect special extension tags in a namespace of your own and perform actions in answer to that (eg tooltips, drag-and-drop, etc...). This makes things a lot more reusable, allows one to separate code from behaviour (and to have someone code while someone else designs), and is a generally great way of creating elaborate GUIs rather easily. A former co-worker of mine (Antoine Quint, known on #axkit as graouts) is about to start a series of articles on xml.com about precisely that (and he's very good with it). I think they're going to be very interesting (judging from all the stuff I've seen him do previously).
In any case, that lousy old ugly format that was only good enough to clutter up websites' first pages -- namely SWF/Flash -- has clearly reached the point where it ought to go play in the microwave oven to see if it's nicer in there. If you do graphics stuff, or know people that do (even the eye-candy GUI people, Adobe will most likely very soon release a GUI product to make SVG, and Illustrator can already export it), I can only wish that SVG will convince you and that we'll see a BurnAllFlash campaign soon enough.
