Goodbye Flash world? Hello SVG world?

In the end, it’s probably Steve Jobs’ fault.

Back in April 2010, when Jobs explained why the iEmpire line wouldn’t be supporting Flash, a subset of the developer community was anticipating HTML5 as giddily as a Twilight sequel, but the majority were only marginally aware of its existence. The first preview version of IE9 had just been released. Firefox had advanced support for many HTML5 elements, but only those early-adopting developers were really paying attention.

Once Jobs made his announcement, though, all that changed. Suddenly project managers and business developers were talking about HTML5, and some people had started to look at Flash as though it might make off with the good silver if nobody was paying attention.

A debate quickly sprung up over the merits and drawbacks of Flash and HTML5, and given the iProducts continued recalcitrance, it continues to this day. Most of this focused on the HTML5 <canvas> tag, and on video delivery, but ignored Flash’s core functionality and its original reason for being: vector graphics and the animation of same.

However, <canvas>’s retiring sibling, <svg> does just that. It hasn’t gotten quite the hype of <canvas>, but it’s equally important. Here’s a vector graphics standard with full penetration through the set of modern browsers (including iOS)

But why should we care about SVG (other than the iPhone issue, of course)? Why not keep using Flash? It’s a proven technology and has deep market penetration. Why mess with success? Simple answer: because, in my humble opinion, it’s a better approach, at least in theory.

SVG is just markup.

<svg>
<path fill="orange"
d="M 10,215 210,215 110, 42 z
M 10,100 210,100 110,273 z"/>
</svg>

An SVG file (or html document fragment) is no more than a dialect of XML. This has all kinds of positive repercussions:

• It allows for all of the text indexing and manipulation methods of a simple xml document; it’s searchable and internationalizable. It can be optimized for accessibility. (I know all of these are possible with Flash, but they tend to require workarounds and extra steps)
• It’s part of the DOM. This means it can be styled with CSS. It can be accessed and manipulated with javascript. You can add events to individual SVG elements: shapes, groups, text. No more clunky ExternalInterface calls.
• It’s open and visible. It’s part of the document. Admittedly, this may introduce security problems which in the past would have been handled by Flash’s internal security manager, but it’s certainly beneficial for development. No need to go back and recompile or add extensive logging. Everything is right there in the browser and inspectable in Firebug or Chrome.

But what about the drawbacks? Isn’t Flash’s compiled file format faster? More compact? Better supported? Well… yes and no.

The most popular benchmark of Flash’s performance vis-a-vis SVG’s is a 2D particle simulator which counts the number of “frames” per second it’s able to render. It isn’t an accurate benchmark of anything in particular, since it doesn’t distinguish between rendering times, calculation times and document modification times, and it’s also dependent on the author’s ActionScript vs. Javascript implementations, but it is a living demonstration of the current state of affairs, since you can see the tests play right in front of you on a variety of browsers. What I see when I look at them is that, with minor quirks, SVG is more or less in parity with Flash, except on Firefox (I’m looking at v11), where Flash is still the clear winner. Here’s a summary of results from early 2012.

One problem that this comparison does turn up is that the performance of different implementations of SVG varies widely. Where you could at least expect that any browser with a Flash plugin would perform equally well on a given machine (IE and its ActiveX architecture excepted), now we’re seeing differences across browsers on one machine. Until that gets normalized to some extent, widely-targeted sites using SVG may be slow to appear.

As for breadth of support, as of this writing inline SVG is supported by 62.48% of browsers in use, according to StatCounter GlobalStats (+/- your degree of skepticism over usage statistics). By all accounts Flash continues to hold steady with numbers in the upper nineties, at least in the non-mobile market.

So it looks like SVG is not quite ready for prime time. Perhaps with one more generation of browsers its use will be a no-brainer, but at the moment, most will prefer to stick with the tried-and-true.

My prediction: the .swf format will continue to be around for some time. Organizations have invested heavily in it, and it’s mature and works well. But its slow eclipse has begun.

The Flash editor, on the other hand will probably get another life as an HTML5 editor, generating SVG/SMIL/javascript, and possibly canvas as well.

And it will be Steve Jobs’ fault.

Postscript: What if I actually want to develop with SVG? You haven’t said anything about that.

First you’ll want to have an understanding of the basics of the document format, and how it fits into the DOM. The best, most complete and accessible resource I’ve found is http://www.w3.org/Graphics/SVG/IG/resources/svgprimer.html

Of course, most of the time, drawing images using markup is going to be tedious. To save time, people will use vector-graphics editors like Adobe Illustrator, the open-source Inkscape or, yes, Flash.

And javascript libraries like Raphael will be useful for higher-level manipulations of the SVG elements.