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.

Have you ever tried to set up an SSH tunnel? Chances are you either have no idea what that is, or you have tried, and are squirming in your seat now recalling the pain you suffered.

SSH tunneling is an extremely powerful means of establishing an encrypted (secure!) link between your computer and another computer, migrating selected network accesses from one computer to the other.

For instance, let’s say you’re a student, and you have a school library that provides all manner of online reference materials, such as encyclopedias, magazine indexes, etc. In order to prevent these resources from being accessed outside the school, the school may limit access to computers “inside the network.” If you have access to a shell account inside the network, you may be able to use SSH tunneling to “surf the web” from your shell account, even though you’re using Safari on your Mac to do all the web viewing. Nifty, huh?

I have configured something like this before and it’s extremely confusing and easy to get wrong.

Meerkat 1.0 from Code Sorcery Workshop, is a slick GUI interface around providing this type of functionality. It provides nifty luxuries such as named presets for tunnels, and allows for tunnels to be opened automatically when a particular app launches. Cool!

Congratulations to Justin Miller on reaching 1.0 with this product!

I’m happy to announce a new podcast which you’ll hopefully consider adding to your iTunes subscription lineup: Core Intuition.

The show features my friend Manton Reece of Riverfold Software, makers of Wii Transfer, and myself. What is the podcast about? We’re still figuring that out, but we’re roughly aiming to be an entertaining discussion-based podcast covering issues of interest to indie Mac developers, and people who are interested in the lives and thoughts of said developers. In other words, people like you!

The first issue covers topics ranging from WWDC to reflections on the Apple Store, and Apple’s NDA policies. We’ll see how it evolves. In the meantime, wouldn’t you be proud to count yourself among our very first listeners?

Ever since FlexTime 1.0 came out almost two years ago, people have been asking me why they can’t use the space bar to start and stop a routine.

Sorry it took so long, folks. FlexTime 1.2.2 now supports this!