JavaScript as GPSL

Why Jython will beat JavaScript as GPSL-General Purpose Scripting Language

Okay, there is a touch of exaggeration in the title. First, JavaScript is not likely to be displaced from its leading role as the premier scripting language for web development. Jython "beating" JavaScript is really about the appropriateness of JavaScript for a more expanded role in scripting - the General Purpose Scripting Language..

For a longtime, analysts have been calling for a cross platform scripting language for use in all areas of computing. This universal scripting language is needed because web development, distributed processing, network system management and software agents among other tasks - all would work much better if a universal, standard, and cross platform scripting language was available. A GPSL-General Purpose Scripting Language would help to replace the current hodge-podge of WSH, the Unix shells, Rexx, Perl, Python and at least a dozen other languages that currently must be mixed and matched to deliver distributed applications.

JavaScript is not likely to become this GPSL because it has some serious hurdles and deficiencies.One of the major hurdles is that JavaScript's very success as macro language (see below), has meant that JavaScript has developed several incompatible dialects with different definitions and object models. This opens the way to a variety of scripting contenders, such as Beanshell, Jython, JudoScript, Jacl, Perl, PHP, Rhino, Ruby, and others. This article will first examine some of the critical hurdles facing JavaScript and then examine some of the leading contenders for a GPSL..

What JavaScript Hurdles and Deficiencies ?

In an article for, JavaScript Trends, we showed that JavaScript is doing quite well as a cross platform macro language adopted by a growing number of ISV applications including Adobe, ePiphany, Lotus, Macromedia, Siebel and many others. As well, 4.x browsers are getting largely replaced with IE5x+, Netscape 7.x, Mozilla 1.x, and Opera 6x+. As a result of being more fully enabled by these browsers, JavaScript becomes more important and useful in web applications. Finally, one can see in the reviewing community an almost grudging admiration for JavaScript. It is easy to learn, and its cross platform and cross-browser capabilities are becoming ever more attractive. For example, even at Microsoft JavaScript is displacing VBScript in such new products as InfoPath 2003 and Biztalk 2004 which use JScript (Microsoft's JavaScript version) preferentially. So what is spoiling JavaScript ? You guessed it - success.

JavaScript is starting to balkanize into distinctive, but also mutually incompatible dialects because of its strengths and successes in the marketplace. One of the major attractions of JavaScript is that it is available in cross platform C/C++ or Java editions as Open Source from Mozilla and commercial products from Trolltech and Nombas/Openwave, among others. But even more fundamental, JavaScript's Object model is easy to develop with and extend. This is precisely what attracts ISV's to using JavaScript.

However, as a macro language, JavaScript is often greatly modified to serve the local needs of the application it is supporting. Just look at the different versions of JavaScript Adobe has created for Atmosphere, Acrobat, Illustrator, and Photoshop. Each one is loyal to the core of JavaScript but then goes on to add many distinctive object models and methods. Think of them as C/C++ frameworks or libraries. The problem is that many of these are incompatible even between Adobe products. And Adobe JavaScript objects certainly do not agree with Macromedia's or Volume Graphic's.

Another case of success as mixed blessing is JavaScript prospering in major Web-based applications. JavaScript has evolved with CSS and DOM support such that desktop applications can be closely approximated in Web browsers. Menus icons, and taskbars with draggable resizable windows or windows panes are avilable as JavaScript components. Treviews, accordion scrollers, and the most sophisticated dropdown calendars also can be done in Web browsers. Take a look at Cognos ReportNet or IBM/Rational RUP or for just a few examples of what can be done with JavaScript either as primary GUI front end or as key support element.

But this growing capability of JavaScript to power the Web API as a substitute for the Win API did not fail to catch Redmond's attention. As Joel Spolsky, normally an enthusiatic Microsoft advocate, points out - Redmond now sees the Web API not as a complement but a direct threat to the Win API and has taken action. Microsoft DHTML projects like HTA were stopped dead in their tracks. Ditto for development of IE and bringing JavaScript/DOM/CSS up to standards. Now, JavaScript's success in enabling Web application has the dubious distinction of revealing the level of antipathy for a truly crossplatform Web API on the Redmond campus. In the future, expect Redmond to make its JavaScript/JScript more proprietary and less standardized.

Finally, success may have come too fast to JavaScript especially when Netscape, JavaScript's creators, faltered after Microsoft "cut off its oxygen". The result has been the wide adoption of JavaScript but no center of innovation. Mozilla (which employs Brendan Eich, the chief architect of JavaScript), has not led JavaScript innovations in the past few years. There is a JavaScript leadership vacuum in contrast to the vigorous sponsorship of say Eclipse by IBM, Java by SUN, and the Apache Web Server by the Apache Group.

Thus, some of the syntax and base object models of JavaScript may have been closed off too soon. XML processing, object serialization, database connectivity and transactions, asynchronous messaging and WebServices are some major arenas where there is little or no guidance from JavaScript as to how syntax and object models should be coded. Such syntactic features (available in competing scripting languages) such as associative arrays, for-each clause, static structs, enhanced switch statement are being ignored or left to individual vendors like BEA to make improvements in and then get ECMA to approve as standard.

So, success for JavaScript has produced hurdles as some vendors seek to shape or even slow down its adoption. At the same time, deficiencies in JavaScript's base set of APIs and syntax have become evident. As JavaScript is pressed into use on cross platform agenting and/or distributed processing tasks. it is meeting with mixed-success. The result is that other cross platform scripting languages are being considered as potential candidates for universal scripting language. Like javaScript these scripting suitors are often Open Source and are easy to develop with an deploy.

CrossPlatform Scripting Princes

Like princely suitors to the throne of IT cross platform scripting languages, there are a number of scripts which could displace JavaScript as being the heir to the throne of universal scripting language.The table below summarizes the key characteristics of the wannabe GPSL-General Purpose Scripting Languages.

Table 1 - Cross Platform Scripting Languages
DevGrp Comment
Beanshell Any JVM GUI editor, jdbg small provides interpreted Java with bsh like extensions
Jacl Any JVM editor, GUI small runs TCL with JVM and allows direct Java calls
JudoScript Any JVM editor, GUI small rich containers, JDBC, XML, SGML direct calls
Jython Any JVM text edit,debug small runs Python with JVM and allows direct Java calls
NetRexx Any JVM text edit, debug IBM runs Rexx with JVM and direct Java classes
Perl Win, Linux, etc 3rd party GUI IDE large new Parrot will be universal VM for Perl, C, Java
PHP Win, Linux, etc 3rd party GUI IDE large new PHP5 adds command line, XML, OO mods
Rhino Any JVM text edit Mozilla runs JavaScript within Java with direct Java calls
Ruby Win, Linux, etc editor, debug small runs an OO language with auto container classes
XEN Win ?? GUI IDE MS combines C# interpreter with XML, SQL

Let's look at some of the charaecteristics of this scripting language. First and foremost, it should be Open Source and cross platform. However, being Open Source does not demand that it be free (see below). It should be an interpreted language, possibly compilable and running in a small footprint so it can be used on PDA, mobile and other evolving computing devices. Being an interpreted script with a small footprint helps to insure that the scripting tool will remain orthogonal and act as a complement to the major compiled programming languages.

To an extent, many of these requirements are being met as a result of a scripting language's development. Look at all the scripting tools that run in the JVM. This group of scripts alone is a rich set of scripting offerings because each one ensures, unlike JavaScript, that a uniform set of functions are available for GUI, threading, XML, Web Services, database connectivity, etc. If a function is not available natively in the scripting tool, its Java alternate can be invoked through the Java connection. A GPSL-General Purpose Scripting Language should also support objects, collections like tuples or associative arrays, plus a frugal syntax - more Java-like than Ada or PL/1 in this latter respect. This helps keep the interpreter size down and processing speed up.

This GPSL should also offer a small or even typeless set of data primitives such as JavaScript or PHP and a small, but robust set of flow of control statements like VBScript or Ruby. It should provide file, thread, asynchronous messaging, unified XML, SQL, and object serialization/persistence like JudoScript or XEN. The GPSL should be Open Source and uniformly cross platform (not 3rd party and limited cross platform as in the Ximian project Mono version of JScript where only a part of .NET framework is ported). Microsoft has yet to declare its intentions on XEN (or soon to be C Omega ); and that choice will determine how Open and/or interoperable Redmond intends to become.

Finally, unlike JavaScript, the GPSL should be financed and supported by the ISV community. JavaScript and other Open Source projects have two glaring weaknesses - they live hand to mouth in obtaining programming, documentation, support personnel and services. They have no financial or legal clout to enforce their standards. For example, ECMA seems to be as powerless as JavaScript programmers to make Redmond tow the line on JavaScript standards. JavaScript on the Web languishes because Redmond does not update IE's W3C and ECMA standards compliance, nor does it move to rationalize JavaScript's DOM/CSS inconsistencies nor Forms obsolesence (see WhatWG).

The GPSL would be Open but could be subject to a modest licensing fee, say $1 per year per usage in an ISV's products. Take DBMS vendors - assume there are 300 Million licensed DBMS users in the world and 1/3 of them were to operate DBMS that used the GPSL - this would generate operating revenues of $100 million for the GPSL development and standards organization.

Finally, to add teeth to the GPSL standards, it should have a requirement that all ISV users of the GPSL provide their users with a standards conformance toggle or "undo" switch. This software switch would ensure that the GPSL standard code could be easily adhered to throughout any application generated by the ISVs software that uses the GPSL scripting tool. This in turn, would allow individual ISVs to create variants and proprietary extensions to the language. This allows 3rd party innovation, but also prevent "run-ahead" proprietary extensions which are silently and automatically generated into users code. Developers and users would always have an easy "undo switch" from using proprietary and potentially non-interoperable code and/or output.

JavaScript Lessons

The four top priorities for CEOs, CIOs and IT managers for the past decade have been revolving among these issues:
1) IT should be more responsive to business needs; development backlogs should be measured in a few months not years;
2) Systems should interoperate and integrate better; adhoc reports, integrating with external customers should not take months;
3) IT project success rates should be better than 2 chances in 3; and on time, on budget, on spec better than 1 chance in 2;
4) IT permeates every business; managing the change brought about by IT projects and systems is management problem 1.
Now that hardware cost are, as Bill Gates has acknowledged, approaching zero and the software technologies of the last frontier - distributed, heterogeneous, n-tier systems - are becoming well understood; making software work well together is a major priority. And in order to do so, one needs a mechanism for making highly interoperable requests for IT services. The whole Web Services paradigm is designed to address that issue. But missing from the Web Services standard is robust, open and interoperable scripting or programming facility. All the major vendors recognize this: Microsoft's Xen, IBM's NetRexx and the widespread adoption of JavaScript as cross platform macro and scripting language by a number of ISVs attest to the need for a GPSL.

Already large applications systems are permeated with 3-5 languages. For example, take a recent project which used ASP C#, Flash ActionScript, backend C/C++ extensions and client-side JavaScripts. And for reportwriting, Java based Report Mill. This is typical. In his assessment of Scripting languages, John Ousterhout, creator of the TCL scripting language, argues for two-language development . This means using an integrated scripting and base programming languages like Jacl=TCL+Java or Jython=Python+Java or XEN=C#+SQL+XML. This combo script plus compiled language is likely to be better at attacking the problem of language proliferation and the ensuing difficult maintainability problems including responsiveness to requests for changes and extensions of systems.

But JavaScript's mixed success has proven that GPSL problems extend beyond technical language design. The institutional infrastructure has to be considered as well. If a GPSL is to be Open, cross platform and yet foster standards and innovation it needs to be imbedded in an institution that is not going to be a virtual beggary dependent on handouts from the ISVs and end user organizations that profit from the GPSL's very success.

So is Jython going to "beat" JavaScript as the future GPSL ? Who knows ? Jython has one distinct advantage - its XML, database connectivity, threading, and XML interface features are already set and so beyond standards machinations as in the case of JavaScript. But don't count JavaScript out - Rhino is awfully nice. And of course some parties would say PHP5 with its new OO foundations and robust command line interface is the real sleeper here. But this point is important to note - with the exception of XEN, all of the above scripting languages are Open and easily downloaded and installed and used. Try one or two out and see if you can find the ideal candidate for computing's GPSL-General Purpose Scripting Language.

Jacques Surveyer is a consultant and photographer; see the latter at

Top of Page  Tutorials Home  JavaScript References  JavaScript Books