Mozilla recently released Firefox 9, a new version of their browser. One of its most important features is a JavaScript engine that is 36% faster than their previous version.

It strikes me that we have come quite a way if JavaScript performance is now one of the biggest selling points of a browser. The change isn’t all that surprising: with JavaScript powering almost all web applications, JavaScript performance is closely tied to the perceived speed of the browser itself.

I think the success of JavaScript is especially impressive when you consider that JavaScript is not a “clever” language, nor does it have any popular gimmick attached to it. It has succeeded solely by being ubiquitous (all major web browsers support JavaScript) and by undergoing steady improvement.

Other technologies, such as Java from Sun Microsystems and ActiveX from Microsoft, were once promoted as the future of web page scripting. ActiveX involved running signed binary code, or applets, directly from a web page. That approach tied users to Windows and Internet Explorer, a desirable side effect for Microsoft but not necessarily for others. Users also feared (quite reasonably, in my opinion) the potential security nightmare if a dangerous ActiveX control was accidentally run. Java’s “write-once, run-anywhere” approach sounded impressive, but the reality of poor performance and heavy memory consumption discouraged its use in web pages. (I always disable Java in my web browsers.)

JavaScript, on the other hand, was never billed as the next big language. Although originally dismissed by many programmers as being too simple to be useful, JavaScript really isn’t that simple. JavaScript has very little to do with Java (despite the similar name) but is a scripting language that more closely resembles C. JavaScript supports multiple paradigms; not just imperative programming (like C or Java) but also functional programming (like Lisp or Erlang). Support for object-oriented programming is also built into the language.

I think this is an excellent example of perfect being the enemy of the good. Java and ActiveX were “perfect” solutions for web page scripting that nonetheless had serious problems in the real world. JavaScript was merely a “good” language that was flexible enough to be used (some might say abused) for purposes no one envisioned when it was created. (Of course, Java and ActiveX have had plenty of success in other areas, but not general purpose web scripting.)

* * *

I’ve always had a soft spot in my heart for the programming language Forth. Forth was developed by Charles Moore in the 1960’s. It is a very simple language based around the concept of a stack, but behind that simplicity lies a great deal of power.

Forth remains one of my computing regrets, although probably not for the reasons you might think. The problem isn’t stack-based languages; I am fluent in PostScript (another stack-based language) and I’ve written dedicated stack-based languages. I’ve read Starting Forth and Thinking Forth, two classic Forth books, and I consider myself familiar with the language. Over the years, I have used somewhere around a dozen versions of Forth for almost as many platforms, and have written a number of Forth programs. By most definitions you would think that I “get” Forth.

But that conviction is shaken upon encountering dedicated Forth programmers. Forth may no longer be a major player on the desktop but it is still widely used in embedded systems. Forth programmers are always so adamant about their improved productivity (some say by a factor of ten!) that I begin to wonder if there is some key lesson I am missing.

I’ve noticed that Lisp programmers have similar convictions about the incredible productivity of Lisp programming. I’ve wondered before if Forth and Lisp are actually two sides of the same coin, even though they bear no obvious resemblances. Both languages are firmly committed to their paradigm of choice (the stack for Forth and the list for Lisp) and both have programmers who are strongly dedicated to their chosen language.

* * *

I’ve often thought that a stack-based language, such as a subset of Forth, could have been an ideal scripting language for web browsers. Parsing a stack language is trivial compared to other types of languages and much faster. A well-written threaded stack language can achieve speeds comparable to assembly language, much faster than an ordinary scripting language. A stack language can be easily made to operate within a security model, essential for any language intended to run in a web browser, just by constraining the legal operations.

On the negative side, stack languages have never caught on with most programmers. Many newer processor optimizations work against stack languages, so their performance advantages relative to other languages have diminished with time. Also, just-in-time compilers techniques, such as those used in modern JavaScript interpreters, have largely offset those potential speed advantages. Still, I’m surprised no one ever pursued that line of development.