JavaScript Trends: Mixed Signals | WebReference

JavaScript Trends: Mixed Signals

JavaScript Trends: Mixed Signals

Given the popularity of the Web and the key role JavaScript (aka ECMAScript among standards committees) plays in Web development, one would expect JavaScript to be ranked in the top ten of programming languages. But if you take the measure of JavaScript in 2004 you get mixed signals. On one hand, JavaScript is ranked 11th by TIOBE ( in its index of most talked about/discussed programming languages on the worldwide Web. As of June 2004, JavaScript is just ahead of SAS and Cobol and just behind C# and SQL. But in recent months, JavaScript has begun losing popularity in the TIOBE readings. In contrast, Jupitermedia's reports that 95% of all browsers have JavaScript enabled as of May 2004, vs. 88% from January 2002 (an improvement of 7% with a steady upward tick). Also, ECMA estimates that nearly 70% of web pages use JavaScript. ECMA is the standards organization whose ECMAScript-262 version 3 standard describes the baseline implementation of JavaScript 1.5 that all companies using JavaScript are pledged to adhere to. Finally, if you check at free scripting sites such as or, JavaScript generally runs a distant third to PHP and Perl for the number of scripts available. Also, there are many JavaScript samples that only adhere to ECMAScript version 1 or 2. To sum up these events, there appears to be a seesaw pattern in the usage of JavaScript.

JavaScript Standards Breakdown?

Looking at the major browser vendors, one sees the same pattern. Opera and Mozilla have moved their implementations closer to the ECMAScript and related CSS/DOM standards, while Microsoft has frozen its browser since its last update in 2002. Currently, ECMAScript version 4 was due to be approved and published by 1Q 2004. But that hasn’t happened and is likely to be delayed by 6-12 months as new players come on board at the ECMAScript steering committee.

Of even more concern is the apparent splintering of the JavaScript standard, which revolves around BEA's recommended ECMAScript extension – XML Scripting. XML Scripting adds some syntax changes to the JavaScript for clause that makes iterating through an XML file much easier. ECMA has approved XML Scripting (named E4X) but as an extension to ECMAScript version 4. This means software vendors can choose to implement E4X or not. Unfortunately, anyone familiar with ANSI SQL will know that optional levels crippled that standard. As a result, it’s almost impossible to exchange anything but the most elementary SQL scripts. To make matters worse, SQL objects and stored procedures were never fully standardized for all exceptions.

JavaScript can ill afford a splintering on something as fundamental as XML processing. If one looks at JavaScript right now from BEA, Mozilla and the ActionScript/JavaScript subset from Macromedia Flash, each one's handling of XML processing is different. With Microsoft proposing powerful XML processing capabilities in its new XEN language and PHP 5 having a nifty SimpleXML processing extension – JavaScript endangers its growing status as a cross platform macro, scripting and agenting language if it has clumsy or incompatible implementations of XML.

But this is not the only area where JavaScript is in trouble. Part of it is inherent in the language. It’s easy to add new and powerful objects to the language - vendors do exactly that. But each implementation can vary substantially. This is analogous to all the different and incompatible C/C++ libraries that proliferated in the late 1980's and continue to this day. If one looks at the JavaScript used in Acrobat 6, Photoshop, Illustrator, Dreamweaver or Mozilla – all define and handle Color and Text Formatting differently.

Now if one is only concerned about the Web HTML usage of JavaScript - then this natural "evolution" is either a minor problem or irrelevant. However, for those looking at JavaScript as a logical candidate for the cross platform scripting language equivalent to Java, one needs to be concerned with this divergence. It is too much like what has happened with C/C++ where movement of code cross platform requires such a substantial conversion effort that it is infrequently attempted. Look at what has happened within Windows. Trolltech's C/C++ QT framework on Windows is quite different from Watcom C/C++ and again from Microsoft VC++, making conversion a major task.

In hindsight, maybe Sun isn’t given much credit for preserving the closest thing the IT community has to a cross-platform and portable programming language. However, it would be useful to have JavaScript as a cross platform scripting language for several reasons. JavaScript beats Java hands down for ease of programming with its typeless variables and easily defined objects. Also, JavaScript's design makes it suitable for rapid development and deployment. But Java trumps JavaScript for the range of tasks it can perform and its overall speed of operation. It would be nice to have a robust cross-platform version of JavaScript for macro, scripting, OS shell and/or agenting work.

And since Microsoft is a voting member of ECMA (and uses JavaScript extensively in its new InfoPath 2003 and BizTalk Server 2004), it’s less likely to create mischief as it did with Java and the JVM. Even after nearly 2 billion dollars worth of payments to Sun, Microsoft still hasn’t agreed to support the latest JVM – Microsoft gets to install and deliver an obsolete JVM on Windows until 2007, at least.

JavaScript is going through a crucial acceptance period as it takes on more cross-platform macro, scripting and agenting roles. It remains to be seen whether the IT community will support and enforce uniform standards. This will determine how successful JavaScript will be in a broader role than just the Web's scripting language.

Created: March 27, 2003
Revised: June 12, 2004