Ecmascript 4.0: Death by Committee, so much for Open Standards….

by troy on December 1, 2008

I didn't realize is that Ecmascript 4.0 is dead. Thanks to Hank Williams for covering this on his blog. As I suspect is often the case, agreement on standards are political battles more often than technological battles.

Part of this really sucks, especially for RIA developers pushing the boundaries, as in the end as engineers we have to build ontop of weaker rather than better languages.

A little history, back in late 2000 I got into Flash again as I was losing my life in the Cross-Browser compatibility hell, I would have honestly thought that close to a decade later that things would have settled down. As outlined at MAX 2008, the opposite has happened, with the mobile space there are *more browsers than ever* to support and a huge variance in supported features:

HTML 5.0 is ages away, it's complicated, implmentation will be inconsistent for sure. One could argue that Ecma4 is similar, but I think it's unrealistic comparison as there was a working version in the Tamarin that could have been used as the base.

With the rapid innovation on javascript runtimes, I wonder how much now even javascript implementation too is fragmenting, at some point whether or not your Javascript interpreter is fast enough to run the application seems to be as important as whether you have javascript enabled or not.

One of the concerns the committee had is that javascript is easy for beginners. I can appreciate the concern. At the same time, I wonder how relevant that concern is for future versions of javascript. javascript doesn't seem particularly scalable, it's not designed 10K-100K lines of code from multiple code bases, multiple domains, some trusted some not.   Browsers I suspect won't ever get away with 'breaking the web' so maintaining backwards compatibility being required for some time to come (much as the flash player). Ecma 4 has features that address that which are used in more mature languages from many camps, Java and C# to address similar concerns.  On complex apps, bytecode would load much faster, be less subjective, and in theory could have more predictable unit testing of cross platform runtimes.   Stricter typing allows for more solid debugging and memory useage.  Almost All RIA apps (including many in flash) fail these longevity tests, they need the best tools and runtimes available.    Summarizing: They seem like completely separate solution spaces, but now the Ecma4 is dead we are left we are only left with the low road.

Rant 2:
I liken this to frosting vrs cake. IMHO, a good cake has frosting as thin layer...this is the applications you build, they should be sweet, the color you want, textured in the right places. Atop a moist basic flavor solid choclate, vanilla or yellow provided by the base language and libraries, sitting atop a rock solid platter.    In the end you can't construct skyscraper cakes with purely frosting...but in the real world, we end up building super complicated frameworks and these end up performing sluggishly as there are so many layers of icing on top of each other, so distant from the bare metal.

Many Flash technologies potentially fit into this: Flex, Cairgnorm, the Tween effects built into Flash. OOP fetishes, Design patterns for the sake of design. Grant Skinner at the Unconference at Max put this nicely talking about Flex vrs Flash. It's a useful tool, but why have ground beef when you can have the whole cow? Flash given it's limitations has always been a choice of pick 2 of 3.   In an ideal world the JIT and code compiler via inlining could render much of this a design or runtime choice, but with weaker languages there are more layers of frosting that the runtime has to wadethrough...only so much can be done.

On the brightside, as much as I like opensource, it often ends up in these messes. I'm a fan of benevolent dictatorships/architects when those in power are gifted with vision. Some good ones are HaXe, ReBOL.

That said, I'm honestly I'm not particularly worried.

My hope is that untethered to standards body and a stable runtime of their own, that Adobe can better tie the production tools (e.g. Flex, Flash...soon the entire Creative Suite) to the best performance possible, without encumberance. There is a significant amount of community feedback into the flash development, so I don't feel it's 'closed source' and that's the community that counts.  If anything Adobe is already moving so quickly I find it hard to keep up with the rate of change.

There are 2 golden rule in web development are:

  • "they who control the creative pipeline, create the rules". most web creative apps are dominated by Adobe tools, this is a culture that Microsoft does not understand. As long as the creators are happy and viewers can find and view the content created easily, then the rest (OS/browser) don't matter as much.   Ironically, though supposedly most the tools at Adobe are created with Microsoft Visual Studio :)
  • "they who have the users, dictate the content rules" especially visible for iphone app...but this is a period notion.   What's the normal relationship between a content browser and a user?  Almost nothing!  Right now there is so much fuss over that.  The browser really is just a window frame between the user and the world they want to see, it should be invisible.

Leave a Comment

Previous post:

Next post: