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.
I’ve always thought that BASIC would be an excellent scripting language for web pages. It’s a good mix between power and ease of use and it always seemed to me that it would be a natural for that task. For some reason I don’t think anyone ever tried it.
Thanks for the heads-up on the new Firefox browser, I hadn’t heard that they had done that. With so many sites dependant on Javascript now I think it makes a lot of sense to really optimize the Javascript engine. I know just what you mean about the Forth and Lisp mindsets. I’ve known some really talented programmers from both camps and none of them could ever understand why I didn’t climb on board. It’s just that Forth and Lisp were never for me, they didn’t work like my brain works (or maybe it’s the other way around?) Great article, really got me to thinking.
I’m a very novice programmer and I found this article extremely interesting. I have such a lot to learn and it helps to have available such well written material as I am finding on your site. I am a new reader and very much appreciate your efforts. Keep up the great work.
I used to write a lot of PostScript programs but I hadn’t thought much about PostScript in years. Remember how Display PostScript was going to take hold and revolutionize how text and graphics were displayed onscreen? Sometimes I think it’s a shame that things went the way they did because I really enjoyed writing and debugging those stack based programs. It was amazing how much you could do with them. These days I write in C++ using Visual Studio and I like the tools and the environment but sometimes I do long for a little bit of that simplicity and fun. Great site here BTW!
i think for developing on tablepc/mobile , a forth IDE with packing feature will be very powerful
A long time ago, when my BSEE was new, I did some FORTH programming and loved it. It set me up to understand PostScript which helped me get further into computer graphics and then animation, which is what I wanted in the first place. I’ve made money programming in a dozen computer languages including C, C++, Java, HyperCard, ActionScript, JavaScript, PL/1 and some proprietary ones too. Every once in a while, I troll the web to see how FORTH is doing. I was glad to find this post because I also think that FORTH may be a good web language. If you use words that match the application, it’s not any harder to understand than JavaScript and it’s even more flexible and smaller.