Is JavaScript here to stay?

The challenges facing this leading user-scripting language

Most everyone knows the children's story of The Little Engine That Could, where a pint-sized locomotive uses the power of positive thinking to overcome apparently impossible odds. The Little Engine chants, "I think I can, I think I can, I think I can," as it chugs up a mountain -- a mountain all the big trains said was too steep for the Little Engine to manage. Just when it appears the Little Engine won't make it over the peak, the spunky steamer comes through, rolling down the hillside with a triumphant "I thought I could, I thought I could, I thought I could!!"

The Little Engine That Could is a lesson in believing in yourself and never giving up, even when the pundits and experts tell you otherwise. If software had a heart and soul, no doubt Netscape's JavaScript would aspire to be the Little Scripting Language That Could. JavaScript is a scripting language designed to enhance the HTML content of a Web page. JavaScript is a language made for the masses, and is intended to be used by anyone, in theory even those without formal programming experience.

While the idea behind JavaScript is a noble one, as a Little Engine it's already showing signs of running out of steam. At least temporarily. JavaScript is an integral part of Netscape's much-heralded troika of enabling technologies -- the other two are Java and plugins -- so it's unlikely that JavaScript will derail any time soon. As Netscape is a company often with an extra ace or two up its sleeve, there's no telling what grand future plans they have for JavaScript.

Still, the future doesn't address the problems of the current JavaScript landscape, which is littered with a confused heritage, annoying security and compatibility problems, and a syntax based on C -- not quite the best example of a friendly user-scripting language. Does JavaScript have a future? Will it be the Little Scripting Language That Could, or will it eventually be switched to a dead-end track in the stockyards, decaying in rust with the rest of the has-been ideas of the Internet?

Sorta Java, sorta not

On December 4, 1995, Netscape saddled JavaScript with a great responsibility. Prior to that day, the scripting language being added to Netscape Navigator 2.0 was called Livescript.

Then on December 4, Netscape and Sun announced an alliance; they would cooperate on a new scripting language designed to be embedded with the HTML of a Web page. As luck would have it, Netscape already had such a scripting language. Instead of calling it Livescript, it would henceforth be referred to as JavaScript. Overnight, interest in JavaScript soared.

The marketing benefit of calling the language JavaScript is an obvious one. JavaScript can ride the coat-tails of Java, a star merely by association. But the name is also somewhat misleading, because it connotes that JavaScript is a "junior" Java, and this is not the case. While Netscape and Sun don't intentionally confuse users over the differences between Java and JavaScript, neither are known for making it a point to clarify the roles of the languages. Educating users on the features and benefits of both Java and JavaScript -- and why we need both -- is one area where both Netscape and Sun could do better.

"And then came the bugs, Doc, thousands of 'em!"

I wrote this paragraph a dozen times, trying to find the way the best way to put it. But there is no "best way" to put it. The fact is, JavaScript has bugs. Some might even say more than its share.

To be truthful, most of these bugs are innocuous, and many are related to differences between the documentation and the actual behavior of the language. No big deal; just mentally correct for the errors in the documentation. For example, the documentation for Netscape 2.0 discusses using JavaScript to read the value of a password form control. Yet for security reasons JavaScript is unable to read the value of password controls.

Yet other bugs are caused by incomplete implementation. JavaScript supports blur(), focus(), and click() methods for form controls, for instance, yet these methods are non-working on many platforms.

One more annoying JavaScript trait is differences of operation across platforms. Some cross-platform incompatibilities are to be expected, given that Netscape is available on four major operating systems -- Macintosh, Windows 95/NT, Windows 3.1, and Unix (if you count all the flavors of Unix, the number of supported platforms more than triples). To the Web page designer, however, differences across platforms is perhaps JavaScript's most frustrating personality quirk. It's not unusual for a developer to spend hours and even days or weeks perfecting a script under a given platform, only to discover the script crashes Netscape under a different platform.

Finally, JavaScript continues to suffer from inconsistencies between interim releases. Features that were working in one release sometimes stop working in the next, and perhaps return to operational status in the release that follows. Case in point: the document.close method. This method was working fine in the original release of Netscape 2.0. But in the 2.01 interim release, the document.close method was somehow broken, and scripts that relied on it no longer functioned.

To its credit, Netscape quickly repaired the document.close method for the 2.02 interim release, but the damage had already been done. Millions of users downloaded 2.01, and a percentage still use it. Since 2.01 users are still be out there, Web designers are advisesd to take the conservative approach and develop work-arounds that will function on all versions. This is not an easy task, and it unnecessary adds to development time.

These inconsistencies have created a mini turmoil among some JavaScript experimenters. Their venom can occasionally be felt on the three major newsgroups that support JavaScript: comp.lang.javascript, netscape.devs.javascript (a semi-private newsgroup hosted by Netscape), and livesoftware.javascript.developer. One former enthusiast even created a "Netscape Abuse Page," at, where the guest of dishonor is JavaScript.

Will the bugs be fixed? Netscape adamantly promises so, having added more developers and testers to support JavaScript in version 3.0. Thanks to its name change and heightened sense of importance, back in the Netscape 2.0 beta days the role of JavaScript far exceeded its original design specification. Yet Netscape management failed to adequately address the need to add more developers to tackle the blossoming feature list. The bulk of the work of JavaScript in version 2.0 was the responsibility of a single (and I might add hard-working) developer at Netscape. Try as he might, he could not deal with all the issues in the break-neck schedule of version 2.0. The result: the language was allowed to be released without adequate testing.

For JavaScript to become the worldwide standard Netscape envisions for it, it must prove itself a more stable environment, particularly in the areas of cross-platform and version compatibility. Few developers can afford the time and hardware to test their JavaScript creations under all conceivable platforms. JavaScript will only become an accepted standard when a script developed on one platform runs the same on all other platforms.

JavaScript and security

JavaScript was unfairly branded a cracker's dream-come-true even before Netscape 2.0 was officially released. It all started with an early beta release of 2.0 that allowed for reading the URLs in a window's history list. Though it must have seemed like a good idea at the time, it quickly become apparent that a bad guy could exploit the security hole and obtain visited URLs, some of which might contain sensitive data, such as passwords. Netscape responded by removing JavaScript access to the URL list.

Even after Netscape 2.0 shipped security problems continued to be exposed. Version 2.0 allowed for the "silent" submission of a hidden mail form; Web page authors could use this innocent-looking feature to collect e-mail addresses of anyone who visited. This feature was removed in Netscape 2.01.

To Netscape's credit, security is one area of JavaScript development that is receiving much-needed attention. True, in Netscape 2.0x, security flaws in JavaScript were addressed simply by removing functionality from the language. This is not the ideal approach, because it also breaks "innocent" scripts.

From the beginning, Netscape has said the removal of features was merely a stop-gap measure, and it would someday replace its method of "security-through-crippling" with a bona fide data tainting model. With such a model, JavaScript could regain its lost functionality, and still provide a means to validate data to ensure it is not being exploited in a security breach. The data tainting model was still being developed as this column was written, but should be fully implemented in time for the final release of Netscape 3.0.

Advances such as the new data-tainting model is precisely what JavaScript needs to keep its toe-hold as the leading user-scripting language for Web pages. Yet developing data-tainting for JavaScript is probably Netscape's easiest task. It now has to convince a skeptical public and developer base that JavaScript can be trusted, given the previous negative publicity of security holes in version 2.0x.

What about Bill?

No discussion of JavaScript's future is complete without mentioning Microsoft. Is Microsoft a force to be reckoned? It's true that Microsoft has made plenty of blunders in its past, like Bob and MSN. And the mere fact that Microsoft has had successes in the areas of operating systems and desktop applications does not equate to automatic success in the Internet. But it's hard to disregard the tens of millions of dollars that Microsoft is spending to compete for Internet mind share and browser share.

Microsoft's Internet Explorer 3.0 is a good example of what a little bit of vision and plenty of money can bring. Even among die-hard Netscape Navigator fans, Internet Explorer looks mighty fine. By the time it ships, IE should support Java, ActiveX components, it's own user-scripting language (called VB Script), and even JavaScript.

At first blush, the fact that IE supports JavaScript should bode well for JavaScript's tenure as the leading user-scripting language. After all, if JavaScript is supported by both Netscape and Internet Explorer, it can't miss. Sadly, where Microsoft is concerned this isn't how it works. Microsoft is perhaps the best adopter in the known universe of other people's technology. Part of Microsoft's adoption scheme is to take the best of what the others have to offer, and make it their own. This is clearly the approach of VB Script, which is similar to JavaScript in many ways, but unique enough to earn the distinctive Microsoft stamp.

What sets off VB Script from JavaScript is that VB Script is based on Bill Gates' all-time favorite language, Basic. For many professional programmers, Basic is the stuff to sneer at, but for millions of front-line in-house developers, it remains the most easy and straight-forward language to master. Where JavaScript (like Java) relies on arcane C syntax to define function and statement blocks, VB Script -- like all Basic variants -- uses English-like commands. These commands, such as the familiar If -Then - End If, make the Basic language easier for newbies to read and understand. Since newbies comprise a significant market of those creating Web pages, a user-scripting language designed specifically for them is a natural fit.

There's no way to revise JavaScript's basic syntactical construction, but there is still time for Netscape to popularize JavaScript among the masses. This is not something it is doing now. The current documentation for JavaScript is dense and at some times cryptic. Third-party books on JavaScript, such as the one I wrote, help to fill the gaps in user education, but only Netscape can make JavaScript a success. Part of that success is plenty of free and easily accessible documentation.

Netscape's responsibilities don't stop there. The company must also offer tools to aid in the development of JavaScript programs, including a JavaScript editor, debugging utilities, and perhaps even advanced tools such as memory stress applications to ensure JavaScript programs perform under all conditions. These enhancements to the JavaScript development pool help attract professional programmers, who lend credibility to the language. Development interest tends to follow the pros -- if the pros don't use a language, you can't expect anyone else to.

So, the Little Scripting Language That Could begins its trek up the mountain. Will it make it over the top? Only time will tell. That and the resourcefulness of its engineers at Netscape.

Resources Gordon McComb is an author, consultant, and lecturer. He has written 50 books and over a thousand magazine articles during his 20 years as a professional writer. More than a million copies of his books are in print. Gordon also writes a weekly syndicated newspaper column on computers, reaching several million readers worldwide. Gordon's latest book is The JavaScript Sourcebook, out this month from Wiley Computer Publishing.
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more