JavaScript may be more like Java than just its similarity in syntax. Like Java, JavaScript has also had a roller coaster ride of early phenomenal success, then some bruisings due primarily to Microsoft's machinations, and now renewed success as a macro language. Yet this recent success as a macro language may mark the highpoint for JavaScript. JavaScript will continue to prosper as the top Web scripting language but might not become the universal scripting language on par with Java as the premier cross platform programming language.

Some pundits have nominated JavaScript to be THE cross platform scripting language. There is a need. Java's huge and largely standardized component libraries now deliver the benefits of reuse envisioned for languages such as Ada, C, C++ and others with the wide selection of devices and platforms Java supports. XML has become the universal language for data storage and distribution, supplanting CVS, EDI and SQL as the preferred medium of data interchange. But XML has very primitive programming capabilities. Ask anyone who has used XPath or XSLT. It's like doing arithmetic with the lamda calculus - cumbersome to say the least. Therefore the gap is this: there is a need for a common, standards-based, cross-platform scripting language that can used for software agents, business rules, workflow control as well as web applications and macro-glue language. Developers do not want to learn a new language for each of these tasks. Besides JavaScript there are dozens of other pretenders like Jython, Perl and Ruby, but in reality there is still no universal scripting language equivalent to XML and Java in reach.

The Scripting Need

The Internet delivers worldwide connectivity and therefore the hypothetical ability to run on any device, any time, on any OS platform. Software agents put even more emphasis on the ability to create dynamic scripts to perform tasks on different devices and platforms and then report back for possible follow up action. And in the brave new world of SOA (Service Oriented Architectures) and BPM (Business Process Management), capsule workflow scripts are able to handle contingent and exception conditions as processes flow through and between organizations.

To summarize, more programming is becoming dynamic, adhoc, conditional , and/or one-of-a-kind, the very stuff of interpreters and scripting languages. True, many of these tasks could be filled by a cross platform programming language, likely Java. But the very nature of the tasks calls for the low overhead and responsiveness of an interpreted language. And consider the need in IT for constant "splicing work." For example, in a complex order-entry system, programming staff were devoted to the task of delivering "ad-hoc" routines that helped ETL-Extract, Transform, and Link to suppliers ever changing data sources, pricing routines and delivery schedules. The "instant glue" was (and presumably still is) PHP, JavaScript, and Ruby. Let's look and see why scripting languages fare well with these requirements.

The Scripting Advantage

As a C programmer, this reviewer fell in love with a C-interpreter called Interactive C in the mid-1980's. It allowed one to adopt the now fashionable "test first" paradigm. I could write snippets of C code in Interactive C, immediately confirm their syntactical correctness and also make sure they worked as expected. This is the essential advantage of interpreted script code such as JavaScript, Perl, Ruby, TCL, etc. Because they are relatively simple in structure and interpreted, it's easy to code and test quick, adhoc programs.

But today's interpreters (like JavaScript) offer additional services to developers. They completely take over the bug-prone task of managing memory. Many provide weak typing so that a variable can be re-used as a string, a float, etc. Some regard this as a weakness - leading to hard to find bugs like dual assignment. Scripters would argue that good namespace management and frequent testing of code snippets (that interpreters encourage) tend to minimize the risk.

Finally, modern scripting languages like JavaScript provide a full compliment of OO programming capabilities. Encapsulation ensures that some class properties can be declared protected or private, thus allowing the programmer to grant access to these properties as deemed appropriate. Polymorphism allows the same basic routine call, say .draw(), to be able to respond appropriately to different objects - say Circle.draw(), Ellipse.Draw(), RoundedRectangle.draw() and others. And the key to that is inheritance. A class can inherit all the basic properties and methods/routines of a base class and then add just a few new properties and methods to complete the class.

And contrary to naysayers, OO does deliver substantial benefits. Code reuse occurs with GUI components and standard libraries. The base classes for Java and the .NET frameworks are huge. Ditto for Apples OS/X framework. JavaScript's basic objects classes like Array, Date, Form, Math, and String eliminate redundant coding. Also automatic code generation is becoming more prevalent and relies on standard libraries of routines being universally available - hence the success of ASP, JSP, PHP, Perl, etc. And JavaScript in both web development and as a macro language gets intense reuse of its object models.

So Why Not JavaScript?

Ticking off the advantages of scripting languages above, has also inevitably resulted in a check mark for JavaScript. And look at the additional list of JavaScript virtues:
uniform base scripting language usage as defined by the ECMA standard;

• cross platform versions available in C and Java for the major platforms(Windows, Linux, Mac, flavors of Unix);
• base code is OpenSource at Mozilla
• familiar syntax, similar to C/C++, C#, Java;
• but relaxed typing allowing variant-like variables;
• one of the easiest OO programming in syntax and structure.

Given this pedigree, one would have to ask why JavaScript isn't used as the universal scripting language? As it turns out, success may be JavaScript's undoing.

Early success certainly brought JavaScript to Microsoft's attention. As a result, Redmond rushed its version of JScript through, with its many proprietary extensions. After winning the browser wars, Redmond turned off all standardization of JScript with JavaScript since the 2001 last release of IE 6. JScript has become even more proprietary as part of the .NET framework. Microsoft can claim that it supports JavaScript; but certainly not a standard and cross-platform version. This continued hostility to cross-platform JavaScript adds anywhere from 20-40% more time when developing JavaScript for web applications. At best, Microsoft's ambiguous and sometimes hostile attitude does not advance the cause of JavaScript as universal scripting language.

A second consequence of early success with Netscape was that when Microsoft "cut off the oxygen," Redmond effectively left Netscape dead. Buyout owner AOL has disbanded nearly all of Netscape. The JavaScript developers have been scattered to the winds. The result is that there is no real organization actively advancing and protecting JavaScript. JavaScript innovations such as the Visual JavaScript IDE, database connectivity, and advanced XML processing died with Netscape. No other vendor with the possible exception of BEA, has advanced general and standardized JavaScript features and extensions.

But as noted in the introduction, JavaScript is thriving as a macro language. But again, JavaScript's success disqualifies it as the universal scripting language. The problem is that the core base of JavaScript libraries and object models was still fairly narrow when Netscape succumbed to Microsoft's attacks. And while vendors such as Adobe, BEA, IBM, Macromedia, Microsoft, Sybase and dozens of others have adopted JavaScript; they have been forced to add their own object models and functions for database connectivity, XML processing, presentation formatting, etc. Most of these extensions to the JavaScript object model are proprietary. This is "strike three" against JavaScript becoming the universal scripting language.

Summary

If one looks at the software landscape there are some remarkable franchises. Microsoft owns the GUI space through the dominating presence of the Win API. The W3C has has garnered a major franchise in medium scale data storage and interchange with its vigorous delineation and standardization of XML. IBM, Microsoft, and Oracle are wrangling over who will dominate the large-scale data storage and transaction world of SQL and databases. And Sun still has no rival for a cross platform programming language with Java.

Given the power and influence these software franchises confer on their owners, it's remarkable that major vendors have not seen fit to advance their specific scripting tools as the universal processing interpreter of choice. There are some logical candidates. Microsoft has VBScript. IBM's NetRexx is worthy of consideration. Sun backed TCL/Tk for awhile. Adobe, BEA or Macromedia could easily champion JavaScript. But as JavaScript becomes more successful as a broad based macro language, it disqualifies itself. This is because JavaScript develops widely varying (and often conflicting) object models for basic functions. The resulting irony is that JavaScript's popularity all but precludes it from becoming the universal scripting language.