ECMAscript (better known to most people as JavaScript) has a particularly interesting history in that it started out as an anti-standard. That is, ECMAScript is essentially the same language as both JavaScript and JScript languages, the competing languages used respectively by Netscape and Microsoft.

The technology was first called Mocha, then LiveScript, and was first officially introduced as JavaScript in 1996. However, it has no technical relationship to the Java™ language; the name's significance can be attributed purely to marketing. Sure, the press release implies some sort of connection between server-side Java and client-side JavaScript (see Resources); in fact, there is no connection at all.

Netscape's market dominance forced Internet Explorer to support a compatible language -- mostly compatible, anyway. Internet Explorer came out with JScript, which was almost compatible with JavaScript.

Standards wars

What happened next is simple: every new version of Netscape and Internet Explorer added exciting features that were incompatible with the other browser. The apparent goal was to get Web designers to commit to a page viewable only in one browser, by making flashy new features available only in a proprietary language. You might see some similarity to this and the conflict between Java and J++, which was happening around the same time. The clash between JavaScript and JScript was rooted in the perceived economic benefits to Netscape and Microsoft, but was not so good for anyone else. In fact, those two companies suffered from the cost of trying to maintain compatibility by engineering incompatible code.

Formal standardization efforts began in 1996, when Netscape submitted the JavaScript specification to ECMA International; a standard was adopted in June 1997. The current standard (ECMAScript Edition 3, 1999) is ECMA-262, which corresponds to ISO/IEC 16262.

This, however, didn't stop the war. Both JavaScript and JScript are compatible with ECMAScript, but they continue to have substantial differences and extensions. Their respective companies use the differences to entice developers into saying a given page only works with a given browser, or stating that a given browser will give the "best" page display.

Some developers simply ignored the question of which browsers might work with their pages, but some carefully checked for compatible versions before trying anything. They did so by checking the user-agent string (a string that the browser provides the server) for version information. Unfortunately, many Web developers settled on "Mozilla/X.0" in the user-agent string as the standard for detecting Netscape versions. If the user agent wasn't Mozilla, various features were omitted or disabled; as a result, these pages would render incorrectly, if at all, in every other browser. So, Internet Explorer began to use user-agent strings claiming to be a version of Mozilla!

Other players

Into this already-tangled situation came the developers of new browsers, such as Opera, iCab, and Konqueror, who were primarily interested in rendering all Web pages as well as possible. Because many Web pages made key features conditional on a user-agent string beginning with "Mozilla", more vendors imitated Internet Explorer's technique. Many modern browsers support sending misleading user-agent strings, and even for selecting which browser to pretend to be. This is a market-driven feature; a new browser can probably render millions upon millions of pages if, and only if, it gives such a user-agent string. Many sites try to check for, and block, specific browsers that might or might not have problems rendering them.

While browsers are the most likely platform to specifically refer to the ECMAScript standard, or to identify a particular version, they are not the only technology to support the standard. Some versions of Macromedia's Flash use a variant called ActionScript. Adobe's Photoshop uses JavaScript too. Of particular interest is Konfabulator, a JavaScript runtime for Windows and Mac OS X, which provides a way to do widgets, such as stock tickers, small video games, and so on.

Effects of a standards conflict

The most obvious effect of this standards conflict comes from the delay caused by the huge and elaborate scripts that Web pages must use to identify the browser before performing a task. Some programs have pages and pages of scripting to identify browsers, with workarounds for multiple versions.

These scripts are not solely a result of a standards conflict; after all, Web pages might need some of this merely for determining which standard version a given platform complies with. Still, the early implementations of JavaScript/JScript were dramatically incompatible in this respect, often offering no hints about versions, or doing so in wildly incompatible ways. It was not enough to ask for a version; Netscape and Internet Explorer might not return it in the same way! Of course, more elaborate workarounds might have resulted from developer confusion rather than from lack of support for version-checking. For instance, one such program used in an online store software fulfillment used a giant script to figure out whether you were on a Mac or a Windows machine (the only options it supported) to decide whether to give you a zip file or a StuffIt archive, even though the downloaded software was platform-specific. The whole script was a waste, as was the half hour it took me to build a static page with the correct download links when the script failed on my browser.

A disturbingly large amount of code assumes that the presence of a particular extension is proof positive of a given implementation. For instance, some developers might check if (document.layers) and then assume that, if the check succeeds, the host browser is specifically Netscape 4, and use all sorts of Netscape extensions, or even just standard features that are not widely implemented outside of that Netscape version. Don't do this! You'll be asking for trouble when a browser implements one feature but not another. Instead, use the standard. (The Mozilla people offer an excellent example of well-written "sniffer" code to identify JavaScript implementations; see Resources).

Although the traffic caused by this workaround is a tiny fraction of the overall Web traffic, it is interesting to estimate how many billions of times the string "Mozilla" is sent as part of a user-agent identifier in order to fake out naive scripts. If JavaScript had simply started with an easy way to check versions or perform feature tests, and developers had made better use of the available support, this would all be unnecessary.

Other variations

One major change in the last few years was the development of browsers with specific, intentional, and well-documented deficiencies in their JavaScript implementations. I refer, of course, to pop-up blockers. The original JavaScript standard allowed scripts to perform several actions that were potentially intrusive. Intrusive is really not a strong enough word; some scripts were designed to do things that were more like the actions of a virus than the actions of a Web page (for instance, windows that used the onUnload method to open new windows when closed!)

While some of these malicious programs were merely inconvenient, or embarassing (some play loud sound files in the hopes of attracting coworkers to a hapless victim's desk), some were potentially very dangerous. A security nightmare involves the option of creating new windows in which the URL is hidden -- which is to say, windows in which an attacker could potentially load some alternative page without the user knowing. Various browsers have developed defenses against unwanted behaviors from scripts.

This conflict continues to escalate, as sites develop new ways to display messages with JavaScript code, and browser vendors seek new ways to suppress unwanted messages. Some sites have made critical site functionality dependant on the exact same script techniques used to display ads, so users can't access the site's primary function without exposing themselves to unwanted ads.

Future directions

Continuing standardization in ECMAScript is still happening. The forthcoming JavaScript 2.0 language standard and the ECMAScript Edition 4 standard are supposed to be essentially the same language, although JavaScript will have some extensions. The JavaScript 2.0 page explains that "JavaScript 2.0 will also include a few features for which more feedback and experience is appropriate before standardizing them."

If users are lucky, developers will experiment with and explore these features, but not use them for the core functionality of Web pages. In the past, I have argued in favor of reasonable early standards adoption, but it is important when adopting a new spec to remember that not everyone has support for it yet. Still, it's a good thing for everyone to test things openly and above-board before putting them into the field.

One future direction that merits special discussion is Ajax, which is short for "Asynchronous JavaScript + XML". The intent is that scripts on a page can do some amount of dynamic work, obtaining new data and revising their display, without reloading the whole page. In theory, this could dramatically reduce the bandwidth requirements of some sites, as the scripts load large pieces of a page once, and then refresh and upload smaller parts. This is not really a new standard per se, but it is an application of ECMAScript languages that pushes the need for better standardization in browsers, and some degree of feature expansion. The more complicated a script is, and the more features it relies on, the more important it is to developers that the underlying platform is stable and flexible. Hopefully future revisions of the standard address the current version's security issues, although this would necessarily entail a loss of some current functionality.

Making effective and safe use of scripting

What does this mean to you as a developer? Well, first, it means you need to try to minimize gratuitous dependencies. Some pages use onclick script activation to load new pages, replacing all the URLs on their page with "#". This is just annoying. Don't do it.

When you develop a script, make sure you understand what will happen if scripting is disabled. One major vendor's Web site, for several years, simply came up as a blank white page if scripting was disabled -- even though the only thing it needed scripting for was to determine whether your browser supported Flash animations. (A more recent version displays a message saying that you need JavaScript for various functionality, such as site navigation. This is not much better.) If you must have scripting, try to keep it under control; after all, many browsers for people with disabilities have limited scripting functionality.

Once you're onto the script, think about on which browsers you need to run. If you can rule out the oldest browsers (or provide script-free functionality for them), you can simplify your code dramatically. Some simpler scripts might be portable everywhere; others might require several features, or multiple implementations of a given piece of code, one for each of several competing so-called standards. You can identify most common JavaScript versions in code in a fairly portable manner (see Resources for more information). Try to isolate your platform-specific code. Don't just assume Internet Explorer; too many people use unusual browsers (cell phones or PDAs) or prefer Firefox.

Remember that pop-up blockers are out there, and users hate having to change settings; indeed, many users cannot change settings, either due to user skill level or to system administrator controls. Limit your scripting to things that will work even on a browser that's been at least partially locked down.

The more you can stay at the center of standards, rather than out on the fringes of extensions, the less work you'll have to do on compatibility, and the less trouble you'll have with new browser versions. In nearly all cases, you can confidently expect that you will have to maintain pages through at least one significant browser release. Plan for it.

Resources

Learn

• Read what the author says about page bloat in "My not-so-invisible enemy" (developerWorks, July 2005). (And check out other instances of The cranky user column.)
  
  
• Create more flexible Web pages with the help of this article: "Retrofit Your Web Pages for Wireless Compatibility" by Brett McLaughlin (developerWorks, November 2005).
  
  
• Browse through the developerWorks Wireless zone to expand your mobile development skills.
  
  
• Read this an excellent discussion of JavaScript versioning.
  
  
• Check out this essay that appears to have coined the name Ajax.
  
  
• Visit the Web Architecture zone on developerWorks to find articles and tutorials on various Web-based solutions.
  
  
• Stay current with developerWorks technical events and Webcasts.
  
  

Get products and technologies

• Review the initial announcement of JavaScript.
  
  

Discuss

• Participate in developerWorks blogs and get involved in the developerWorks community.
  
  
• Participate in developerWorks discussion forums.
  
  

About the author

Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though.

Rate this article

Comments

Back to top

Table of contents

• Standards wars
• Effects of a standards conflict
• Other variations
• Future directions
• Making effective and safe use of scripting
• Resources
• About the author
• Comments