Gordon, formats, runtimes

No big news here… just tying together observations on different types of file formats, and how they interact with different types of local runtime engines.

Last week Tobias Schneider released a project named Gordon, a JavaScript library which parses a SWF and renders some all SWF1 tags [demos]. It’s in the spirit of the previous “SVG in SWF” work from Helen Triolo, Claus Wahlers, Brad Neuberg and others — rendering one file format in a runtime designed for a different file format. Geeky, and admirable.

I liked seeing Gordon arrive, because it proves that SWF, SVG and such are just file formats, interconvertible with varying degrees of fidelity — of the same species. Neither is a black box, both have been publicly specified for over a decade, and different types of code can produce, consume, and work with them. Anybody can use either, do whatever they want with ‘em. SWF and SVG are both useful and flexible file formats.

But some of the reaction was a little strange — I’d rather not embarrass people by linking to articles, but (edited) titles like “Gordon Lets You Run Flash On Your iPhone” and “Open Source JavaScript to Replace Flash?” give a flavor. Much of the initial commentary did not seem to distinguish between a file format as a set of instructions, and a runtime as the clientside engine which executes those instructions.

Using instructions in unexpected ways is fun. Different examples include Microsoft Gestalt (writing Ruby or Python in an HTML page), Flash Pro (the announced ability to export ActionScript as iPhone-native), much of the Flash 3D work (taking the Collada modeling file as a datasource). On the flip side, XML is a file format which was expressly designed for universal use.

But each of these file formats is then processed by an engine of some type, often a clientside runtime. It’s the interaction of format and runtime that determines the actual feature set, the actual performance, the actual deployment cost.

Here’s an example of the confusion: “While the open source Gordon is available to all, it still doesn’t solve one of Flash’s biggest problems. These SWF files still hog the CPU. One demo, a simple vector graphic of a tiger, throws my desktop browser up to around 100% CPU usage.”

Do you see the problem? The author assumes that his performance is controlled by the content — the instructions — rather than the way those instructions are processed in his environment.

Another example: “This frees Flash from requiring a plug in. But it’s also a proof of concept that shows that you can do all the cool, propritary-plug-in stuff using just plain HTML.” Even if this JavaScript library could acceptably handle all the SWF10 tags (instead of some all SWF1 tags), it would still be a JavaScript library, downloaded afresh each time. Sending your runtime code as file format is not as efficient as using a native local runtime engine.

Perhaps the most concerning type of theme: “Any developer wishing to get their Flash files to work on iPhone just needs to ensure they include a HTML wrapper and through the power of Gordon it should ‘just work’.” Here there seems to be an assumption that all runtimes are interchangeable, and that certain file formats are more magic than others.

When a Gordon project “runs on an iPhone”, it’s actually a SWF being parsed by JavaScript instructions which are executed by Apple’s Safari runtime engine. Although this SWF file format is being used, it’s more properly a Safari app than a Flash app by that point.

It’s fun to use file formats in unexpected ways. But different runtime engines are tuned for different jobs, optimized for different types of instructions. Flash’s textfields can display HTML, but you wouldn’t use that to replace your local dedicated HTML-eating runtime engine. Different runtimes are engineered to take best advantage of different file formats.

I like the Gordon project, because it shows there’s nothing mysterious about SWF. Just like HTML, the file format definitions have been public for over a decade. They’re of similar nature, similar usability.

There are differences — SWF is binary, rather than text — that’s a meaningful difference. Another difference is that HTML is about hypertext, while SWF has been designed from the start for rich-media interactivity. Or you could argue that Adobe has provided saner governance over SWF than the WhatWG Consortium has over “HTML5″. The biggest difference between SWF and HTML is likely in the predictability of the runtime engine.

There are differences between HTML and SWF, but even a JavaScript engine can understand simple SWF files… nothing mysterious or alien about it.

[Update: Changed "some SWF1 tags" to "all SWF1 tags"... my apologies to Tobias, I had forgotten that the FutureSplash Animator version had only a dozen logic elements!]