Theorists and theologians of programming languages give a lot of thought to issues like referential transparency, lexical scope rules and idempotency. More often than not, though, programming languages live or die for reasons that have nothing to do with such syntactic and semantic virtues. In the early 1980s everyone wrote programs in Microsoft BASIC because that’s what shipped with the IBM PC. A little later we all switched to C because…. Well, I’m actually not sure why, but I know it had nothing to do with referential transparency. Turbo Pascal was enormously popular for a very simple reason: It cost 50 bucks at a time when a C compiler would set you back $500.
Now we have JavaScript. It’s not Microsoft BASIC or Turbo Pascal. As a matter of fact, it’s a language with some decidedly highbrow features. And yet I’m pretty sure the root of its popularity does not lie in its lexical closures or its first-class functions. JavaScript is thriving because it’s the way to make nifty stuff happen inside a web page. Those Google maps that glide around in their box when you push them with the little hand—that’s JavaScript magic, and I was thunderstruck the first time I saw it. And the drag-and-drop pictures on Flickr, the fill-in forms that won’t let you schedule a delivery on February 30th, the online surveys, the clickable seating chart on the airline-reservation page, the everybody’s-an-editor features of Wikipedia, virtually everything on Facebook—none of it would happen without JavaScript. (It’s only fair to mention that most of the obnoxious things on web pages, such as popup ads, also depend on JavaScript.)
So here are a few miscellaneous JavaScript developments that I’ve been noticing lately.
John Resig has ported the Processing graphics language to JavaScript. The original Processing implementation of Ben Fry and Casey Rees produces Java applets. Java programs can also be embedded in web pages (here’s an example ready at hand), so what’s the point of switching to JavaScript? Both languages have their pluses and minuses, but Java has just enough startup overhead that many folks in our impatient age are reluctant to run it. JavaScript avoids that delay.
(Note: This is where I’m supposed to explain that Java and JavaScript are not dialects of the same language, or even closely related. On the other hand, JavaScript is the same as LiveScript, JScript and ECMAScript, and it’s almost indistinguishable from ActionScript. I don’t know what we did to deserve this confusion of names. Maybe it had something to do with excess consumption of froufrou coffee drinks. For more on the sorry history of the two languages see Steve Champeon or Douglas Crockford.)
Cat is another graphics language with an interpreter that emits JavaScript.
Looking beyond all the web-gui-glitz, and more in the direction of referential transparency and the like, Sjoerd Visscher has released some interesting code that makes JavaScript look more like Haskell.
There’s a new JavaScript (excuse me, ECMAScript) standard on the way, someday. (It’s been coming for at least seven or eight years.)
A couple of things I should have known long ago but just discovered: The dashboard “widgets” introduced in Apple OS X 10.4 a few years ago are coded in JavaScript. And several big Adobe applications (InDesign, Photoshop, Illustrator) have JavaScript interpreters built in.
There’s more news from Apple: WebKit, the open-source core of the Safari browser, is getting a new JavaScript interpreter called SquirrelFish. Here’s what the announcement says:
SquirrelFish is a register-based, direct-threaded, high-level bytecode engine, with a sliding register window calling convention. It lazily generates bytecodes from a syntax tree, using a simple one-pass compiler with built-in copy propagation.
As for the deep mystery of the name “SquirelFish,” if there is there a connection to Holocentrus adscensionis, I don’t get the joke.
Still another technology connected with Apple—and still another goofy name—is SproutCore:
SproutCore is a framework for building applications in JavaScript with remarkably little amounts of code. It can help you build full “thick” client applications in the web browser that can create and modify data, often completely independent of your web server, communicating with your server via Ajax only when they need to save or load data.
The provenance and current status of this system are somewhat murky to me. SproutCore was created by Charles Jolley, an independent software developer, but apparently it was embraced and promoted at the recent Apple Worldwide Developer Conference as a technology for creating web applications that resemble the OS X Cocoa framework (see here and here). But so far Apple has said nothing openly to confirm their adoption of SproutCore. It’s worth noting that there are lots of other JavaScript libraries and frameworks (for example, the Yahoo User Interface Library YUI, qooxdoo, John Resig’s JQuery).
When I look upon all these somewhat baffling developments, my role is that of a not-quite-innocent bystander. I don’t have the expertise or experience to speak authoritatively on the best choice of programming language and development environment. On the other hand, I have an interest in the outcome of the language competition. I want to be able to write small, illustrative programs (like the Processing sketch mentioned above, or another done in ActionScript) and make them available to the world at large via web pages. JavaScript and its variants are likely to be the vehicle for that activity. Could we make it a smooth-running and reliable vehicle, please?
I close with an interesting comment from Hackerdashery:
As the correct metaphor for a web page moves farther from “document” and closer to “application”, maybe it makes sense for browsers to act more like operating systems.