JSTalk – An Alternative To AppleScript?
March 26th, 2009My friend Gus Mueller of Flying Meat is having a busy week. On Tuesday it was revealed that his awesome image editing application, Acorn, is part of the MacHeist 3 Bundle. I have been openly critical of these rock-bottom-pricing bundles in the past, and I remain uncertain as to their long-term benefits for the Mac software ecosystem. But in the short-term, consumers obviously have the option of picking up some amazing software for an unbeatable price. And if folks like Gus end up benefiting then I wish them the best.
In the wake of his high profile MacHeist debut, Gus announced something new today which is decidedly less consumer-oriented (though if it takes off, it could certainly have wide-reaching consequences). JSTalk is Gus’s JavaScript-based answer to what he sees as outdated and clunky about AppleScript, Apple’s preferred scripting language on the Mac.
For starters, Gus’s JSTalk provides syntactic sugar on top of standard JavaScript in order to give it some comfortable Objective-C style conveniences. Then, he provides a teeny bit of source code that any application can embed in order to respond to incoming JavaScript commands. This results in a scenario where an Objective-C based application can easily expose its internals to other applications, so that a script written in JSTalk can control it from another application.
I’m excited about the idea of JavaScript taking a more prominent role in the scripting infrastructure of Mac OS X. In fact, about 9 months ago I wrote some challenging words about my opinion on the matter. Responding to Apple’s impressive enhancements to JavaScript in the context of WebKit:
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.
Since then, Apple has given no indication of pursuing a system-wide infrastructure for JavaScript scripting. So in comes Gus Mueller with JSTalk, and solves the problem. Right? Well, sort of. Gus’s idea is very cool and clever given the constraints he’s working with. Namely, he can’t easily control how every application works, or how it interacts with the system and every other application. His solution is cool, and may even be worth adding support for to your application, but it’s not as cool as a system-wide, Apple-endorsed solution would be.
Michael Tsai makes some smart observations about JSTalk, also agreeing that it’s cool, but taking exception to Gus’s claim that getting away from the rigid structure of AppleScript’s XML-based scripting dictionaries is a good thing:
I think defining the object model, e.g. using XML, is a feature. Otherwise there’s no separation between the scripting interface and the application’s unstable internal interfaces.
Taking a closer look at Michael’s post, I think I could have avoided this somewhat long-winded post by starting simply with, “Yeah, what Michael said.”
March 27th, 2009 at 11:03 am
JSTalk is “an alternative to AppleScript” in the same way a excavator is an alternative to a sedan. It”™s far more powerful, and people with the right technical skills can do amazing things with it, but it”™s also more difficult and more dangerous and suggesting it to someone who just wants to drive to the supermarket is at best misguided.
JSTalk is very much by a programmer, for programmers. It requires you to understand memory management, object models and architectural complications. AppleScript is for normal people. I”™m surprised how many Mac devs don”™t get this — not necessarily including you or Gus, since you don”™t really touch on the question directly — when they take so much pride in approachable GUIs. Even the annoying syntax of AppleScript is a good reflection of this, although they made a pigs ear of implementing it (HyperTalk was much better, but of course it wasn”™t extensible in the same way).
As a high-level implementation language for Cocoa, JSTalk is very interesting. As an alternative or future direction for AppleScript, it”™s about as good an idea as deprecating System Preferences in favour of command line tools and config files.
March 27th, 2009 at 11:18 am
Thanks, Ahruman. I admit in my own thinking I had glossed over the “programmer-y” implications this has for users who want to script the target application. Memory management is definitely a beast and you’re right, AppleScript ends up making it pretty much a non-issue for end-users.
March 28th, 2009 at 3:57 pm
Strong agreement.
Just as exposing your inner data model as your forever-file-format is easy and wrong, exposing your API-of-this-build as your forever-scripting-interface is… easy and wrong.
Public API’s (scripting, file formats, saved parameter settings) are forever.
But apart from all that: WOO! Go JavaScript!
I really like JavaScript.
March 30th, 2009 at 9:52 am
i’m lost, how is this different from a javascript OSA (Open Scripting Architecture) from late night software?
oher than maybe a faster JS engine?
March 31st, 2009 at 1:01 pm
Why on earth would you want to do this rather than run appscript in either Python or Ruby? Seriously the stuff you can do with Python + appscript is amazing. Further appscript comes with a nice translator of Applescript -> Python that handles most stuff. (Not variables unfortunately) The syntax is very easy to use as well. Plus mixing all the Python libraries with stuff you’d normally do with Applescript is amazing.
I have one program that scans an email for some purchase information from an ecommerce email, generates an invoice in Excel, generates a FedEx shipping slip, emails an HTML mail invoice with a link to the FedEx tracking number they can click on. There’s no way you could easily do that in Applescript and I suspect you couldn’t in JSTalk either. But it’s trivial in Python. And the code is amazingly readable.
March 31st, 2009 at 2:57 pm
MacCanada:
Very different:
– JavaScriptOSA is/was an OSA language component with integrated Apple event support; basically analogous to the AppleScript component, though JSOSA had some design flaws and omissions that meant it never worked as well as AS, and it never found popular support.
– JSTalk completely ignores the OSA and Apple event APIs; instead, it hooks directly into Cocoa-based applications through Objective-C APIs, using Cocoa’s Distributed Objects system to talk to other processes.
The client-side (language) stuff is relatively small potatoes, however. The real difference is what Gus is proposing on the server (application) side. Cocoa applications normally use Cocoa Scripting to implement their Apple event interfaces. Cocoa Scripting is kinda like Cocoa Bindings, only for IPC rather than GUI: add some binding info (sdef file) and glue code, and you’ve got a complete View-Controller layer on top of the application’s existing Model layer. What Gus seems to be proposing is doing away with this View-Controller and talking directly to the Model objects via their native APIs.
This will certainly simplify things for developers (since they don’t have to do anything to make their apps ‘scriptable’), but I’m not sure it will make for a better user experience: the VC part of MVC is there for a reason, after all. Of course, this isn’t to say one couldn’t implement a proper DO-based VC layer, but this pretty much brings us back to Cocoa Scripting’s problem: any fool can bang together a rudimentary VC layer, but designing a really robust, reusable framework that both developers and scripters can easily understand and use is a much, much harder problem.
Personally, I think it’d be better to create a third-party alternative to Cocoa Scripting, which wouldn’t be too hard as long as you nailed down a sensible spec to begin with. It’s the one area where developers can safely do an end-run around Apple: you just embed the framework in your application bundle, so there’s no user-installed dependencies to worry about. Plus you get to leverage the existing AppleScript audience, and any other language that knows how to speak Apple events (the shortcomings of a certain less-than-stellar Apple event bridge notwithstanding).
May 27th, 2009 at 5:14 am
Thanks, Ahruman. I admit in my own thinking I had glossed over the “programmer-y” implications this has for users who want to script the target application. Memory management is definitely a beast and you’re right, AppleScript ends up making it pretty much a non-issue for end-users.