Like the rest of the Mac nerd world, I saw the announcement of SquirrelFish as very promising and inspiring news. The WebKit team has redesigned its JavaScript parser, emphasizing speed performance by switching from a parsed-tree system to a bytecode-interpreted system. The result is a much faster system that apparently offers the promise of even further optimizations as time goes by.
KUDOS to the WebKit team! When I last read about JavaScript performance, it was on Jeff Atwood’s substantial comparison of many browsers and their respective performances. At that time Safari already stood near the front of the pack, only being narrowly beaten by Opera in terms of overall performance.
I expect that unless other browsers have also been dramatically enhancing their JavaScript performance during this time, the SquirrelFish parser will put Apple’s WebKit far in front of the other major browsers in the market. At a time when JavaScript is being used more and more in web applications, the benefits of this advantage could be magnified into a noticeably superior user experience on many web sites.
What About AppleScript?
This announcement got me thinking about Apple’s scripting languages and where the most growth and progress is being seen. Here we have a dedicated product team, responsible for providing a scripting service more or less only intended for use within the context of a web page. Yet this team seems to have a stronger corporate charter for making progress than the AppleScript team, which is responsible for the language that provides system-wide scripting glue to both users and developers. JavaScript must be the single most prioritized interpreted language being developed within the walls of Apple. Yet AppleScript, an often-maligned proprietary Apple language, is still the system-wide standard.
As a variety of web technologies permeate the desktop (and other platforms such as the iPhone), JavaScript is becoming increasingly popular and well-recognized. While AppleScript is lauded for being accessible to naive users, it’s factual ease of use is becoming less relevant as JavaScript’s actual ease of use explodes. How is JavaScript becoming actually easier for users? By means of simple, forced exposure. Just as an awkward, text-based system such as HTML has become so dominant that many secretaries and construction workers are passably fluent in it, so are the majority of users who are likely to use scripting passably fluent with JavaScript.
Apple should make JavaScript its default scripting language.
There, I said it. It wasn’t easy, because I hold a soft spot in my heart for AppleScript. But I’m slightly more of a pragmatist than a romantic. If JavaScript is what Apple cares most about, and JavaScript is where massive performance improvements are going to be made, then Apple should leverage those improvements to the benefit of every desktop scripter.
It sounds like I just said “Apple should kill AppleScript,” but I didn’t. You see, the Open Scripting Architecture, on which AppleScript runs, is designed from the start to support multiple languages. Think of the “Open Scripting” part of the system as the part that lets a script tell another application to do something. The specific scripting language you use to accomplish the rest is really of no concern whatsoever. Two languages, such as JavaScript and AppleScript, can easily live side by side.
The idea of using JavaScript as a Macintosh scripting language is not new. Mark Aldritt of Late Night Software has for years published a plugin called JavaScript OSA which provides the functionality I’m talking about. Here’s a simple script in AppleScript to activate iTunes:
tell application "iTunes"
activate
end tell
And here is the same action written with JavaScript OSA:
with (MacOS.appBySignature('hook'))
{
activate()
}
It’s a little clunky, I’ll grant you. It’s a nuisance that in this incarnation, I had to use the old-style application signature code. But these cosmetic problems are easy enough to fix. If Apple provides its own JavaScript language layer for OSA, it could divert the majority of resources it currently spends on AppleScript. Instead of struggling to keep AppleScript “modern enough,” these fine engineers could instead devote themselves to fine-tuning the JavaScript experience for desktop scripting.
Apple is leading the pack in the development of an interpreted scripting language: JavaScript. It’s time to move on. Adieu, AppleScript.
