September 5th, 2006
Apocalypse 2.0 - the day the web broke
On February 16th, 2005, Jesse James Garrett coined the term Ajax in an article titled "Ajax: A New Approach to Web Applications". Days before that, on February 8th, the Google Blog announced something called Google Maps. Ajax was born and the web hasn’t been the same since. The combination of JavaScript, DHTML and CSS seemed to breathe a new kind of life into the web. All of a sudden you could program a series of hacks and your web page didn’t behave like a web page before. All that time you spent learning JavaScript? With Ajax, you were in demand again! People started saying things like "JavaScript Engineer" with a straight face.
Then, on October 17th, 2006, something terrible happened. ECMA released the specifications for the fourth edition of ECMA Script, and JavaScript 2.0 was born. It added enhanced JavaScript functionality for developers, but FireFox was the only browser to fully support it. Worse than that, all of the Ajax applications written to fuel the Web 2.0 boom required major reworking. Microsoft decided that they were going to add some enhancements to JavaScript 2.0, but these enhancements only worked with IE7 and broke Mozilla browsers. A new browser, which had steadily gained market share because of its ability to keep the browsing history secret, decided to implement a more "secure" version of JavaScript. Developers of applications which were once the toast of the Web 2.0 world now got hundreds of emails a day from users saying "why doesn’t your page work with my internet". Chaos ensued. (Just to be clear, October 17th is an arbitrary date. I have no idea when ECMA is going to release their spec.)
The increasing reliance on JavaScript and the heating up of the browser wars is bad news for compatibility and a majority of Web 2.0 applicationsThe above paragraph may seem silly, or over dramatic, but the increasing reliance on JavaScript and the heating up of the browser wars is bad news for compatibility and a majority of Web 2.0 applications. One look at the dialects of ECMAScript shows what we’re dealing with. Gecko browsers are using JavaScript 1.6, Microsoft is using Jscript version 5.6 and KHTML browsers are still on JavaScript 1.5. Now all of these, minus version 1.5, are based on the 3rd revision of the ECMA standard, but who is to say that when revision 4 is released, all of these applications are going to be backward compatible? And what of the DOMs for these browsers change significantly with each new version? With so many layers to take into account, developers are going to be left crying as they are forced to peel back the onion.
To take another angle, what keeps the companies releasing browsers; including Microsoft, Mozilla, Opera, and a host of others, to the ECMA standards. The browser world is more competitive than it has ever been, and with the explosion of web applications, there is a lot of temptation, and much to be gained, by making "enhancements" to the JavaScript model. If those enhancements are made by big companies, like Microsoft with IE7 or Mozilla with FireFox 2/3, then won’t developers be tempted to use these enhancements in their code? Maybe at first it just requires a workaround or two, but it is easy to see a very fragmented world of browsers and JavaScript versions in which nothing is backwards compatible and you are locked into a specific browser platform.
Luckily, there are other technologies out there which have always been designed with growth in mind, and developed so that companies couldn’t use different versions or change the inner workings. Ted Patrick, the Flex Evangelist at Adobe has a phenomenal post that illustrates some of the benefits when it comes to compatibility in Flash. Flash is 100% backwards compatible. That’s right, the FutureSplash animation you like so much? It works perfectly on Flash Player 9. Anything Flash developers write will run in the future regardless of any updates made to the code base. And because Flash runs independently of the browser, it isn’t restricted by changes made by outside influences.
What keeps the companies releasing browsers; including Microsoft, Mozilla, Opera, and a host of others, to the ECMA standards.Macromedia, and now Adobe, have a long standing tradition of respecting the development work that came in previous versions. The Flash Player has remained lightweight through it all, and is as ubiquitous now as it was 3 years ago. ActionScript 3 is based on the newest ECMA standards, and provides a look at what JavaScript 2.0 may look like. JavaScript developers who take a look at ActionScript will feel right at home and not be required to hack around browsers or worry whether or not their code is going to run for most people. With web apps, we have put up with the extra effort that is required to make things run, but it shouldn’t be that way. Rich Internet Applications run outside the browser, they provide their own platform for development, and bring real application characteristics to the web world.
Web applications are great, but the problem is that they are still duct taped web pages relying on technology from 1999. When things evolve, and they will, that duct tape is no longer going to hold. Developers are going to have to scramble to rewrite major portions of their code. When all along, if they had gone the RIA route, they would be sitting pretty.
Ryan Stewart, a Rich Internet Application developer and industry analyst, recently joined Adobe's Platform Team as a Rich Internet Application Evangelist. full profile and disclosure of his industry affiliations.
Subscribe to The Universal Desktop via Email alerts or RSS.
