ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Article:
  SWF Is Not Flash (and Other Vectored Thoughts)
Subject:   comparing macromedia shockwave to svg+xml+dom+ecmascript
Date:   2002-05-22 14:46:02
From:   flursn
i'd like to share some comments on different aspects of the article:


"swf is not closed":


true, people are free to implement their own parser for swf files. [start sarcasm] and yes, they are free not to update their parsers every time macromedia decides to change minor or major aspects of their standard, resulting in a branch.


"swf is extensible":


whether another player might be better than macromedia's one is not the point. people just want to be able to handle their custom elements without the need to switch to a new player (parser). svg does provide that kind of extensibility through the use of custom renderers, i.e. any valid svg parser just handles over your custom content to an external renderer/parser. this is not breakthrough technology, this is today. when will the flash player offer custom handlers?


"sfw is not fla":


let's talk for real: developers mosten often resist to offer insight in their marvelous work because ... well, with given respect for the folks at macromedia, but the whole architecture is foreaging, and many inner workings present in the most recent version of their project format might need some refining.


"swf is unreadable ...":


it states that 'graphics _or_animation_' were different from html, going on with a discussion about the comprehension of binary data composing an _image_.


that's a major difference. does macromedia market it's shockwave/flash technology as an architecture for viewing images, or is it merely a toolset for building 'rich', 'interactive', 'dynamic', 'data-driven' and whatever websites?


anyone who has ever discovered how easy it is to build interactive elements or animations with sole svg in any text editor, or even in combination with ecmascript, knows what i'm talking about. no, you can not interpret the binary stream of a swf file even if you read ten books about designing flash animations, but yes, you can do so with svg once you are familiar with some basic concepts which should fit in no more than five letter-sized pages.


the bottom line is:


i've followed macromedia's product line for some 6 years, and with changing pace they developed their tools in the right directions, i.e.:


- people don't want to build websites or animations or [insert here] by doing monkeywork such as predefining keyframes for every state of the interface. macromedia realized that, so they gave swf actionscript, later adding all features ecmascript as a standard had always provided.


- people need to access data on the server during runtime. so macromedia added support for accessing and parsing xml through dom. with the new player it should be the complete set. (can you say: 'attributeNode'?)


- people want to rely on proven interface guidelines, no need to reinvent the wheel or confuse the user if you just need a simple contact form. so macromedia added more and more 'built-in' form and layout controls (ever programmed a scrollbar feature in flash?).


- ... and i'm quite sure macromedia will incorporate some sort of css 1+2 (incomplete, of course, in the first attempt) for all your layouting needs.


you see: macromedia was not foolish enough not to turn their galeon towards the right direction and adopt proven and standardized technologies every time the devoloper world was nearly out of sight. but alas, svg is already here, and it has all the features 'out-of-the-box'. go browse around oreillynet.com or xml.com and you'll find a bunch of resources and hints to start developing right now. no need to wait for the delivery of a '400-bucks-complete-developing-environment-to-build-the-future-of-the-web'.


i could go on w/ my ranting, but enough for today ;o)


cheers,
niko