While we’re on the topic of Apple, does anyone have an opinion on AppleScript vs. JavaScript? Never mind the native functionality: assume that JavaScript was “injected” with all the native functionality of AppleScript. The question revolves around the syntax, mechanics, and over-all language philosophy of the *Script.
I was reading a recent post from Chris Messina on the topic of what James would call “the synchronized web,”, and it occurred to me that I’d much rather script in OS X in a language that I considered more portable than AppleScript: namely JavaScript. Indeed, I was thinking it’d be interesting if Rhino or Spidermonkey could be embedded in Vienna for scripting and plugins.
But, maybe that’s just crazy. I don’t really know AppleScript extremely well. Perhaps it’s the bee’s knees. What do ya’ll think?
Technorati Tags: javascript, applescript, synchronizedweb, rhino, spidermonkey, osx
Hmm… I dunno much about AppleScript, but what I do know about JavaScript is that the syntax of the language is ass for such a powerful set of semantics that it supports.
AppleScript is based on Apple's Open Scripting Architecture (OSA) which allows other languages to be used to control Mac apps.
http://www.latenightsw.com/freeware/JavaScriptOSA…
http://en.wikipedia.org/wiki/JavaScript_OSA
http://www.python.org/doc/2.3.5/mac/scripting.htm…
AppleScript is known as a read-only language: it's verbose and fairly clear to read, but frustrating to pick the right constructs to write it. So it's worth looking at an alternate. I wish Apple would. (I haven't used JS with OSA, but its philosophy seems similar to AS. Python OSA works nicely, though.)
I've pretty much given up on AppleScript for OSA scripting. It lets me down every time. For my money, appscript is the way to go. It gives you access to AppleScript-style application automation using a real language. It also give you access to handy Python libraries for things AppleScript isn't too good at—which includes pretty much everything but automating applications.
My experience with AppleScript has been similar to Rick's.
I desperately wish that JavaScript OSA were stable/functional enough for everyday scripting. (It seems like the project has been abandoned, sadly.) What'd be even better, though, would be for Apple to include a JavaScript module for the Open Scripting Architecture in Leopard. Ideally it'd also integrate JavaScriptCore, thereby including most of what's awesome about a browser environment. (How cool would it be to use XMLHttpRequest or XPath in an OSA script?) But I'm only daydreaming.
(On another note: If AppleScript is a read-only language, and Perl is a write-only language, then whomever writes a Perl-to-AppleScript interpreter will make millions!)
Re. Vienna:
It'd probably make more sense to implement a regular Apple event interface first; that way any language that can speak Apple events can talk to it (AppleScript, Perl, Python, and soon Ruby). Cocoa Scripting's not perfect, but serviceable scripting support should be quite doable.
Communicating in the other direction – i.e. from application to scripts – is a bit more problematic though, should it need to provide that as well. In theory you'd just use NSAppleScript or OSAKit to allow users to attach OSA scripts to application menus, objects, etc, but in practice the only currently available OSA language that's good enough to use here is AppleScript, which kinda takes the fun out of things.
So an embedded interpreter wouldn't need AE or OSA support to operate. OTOH, it won't have the same 'glue' capabilities either, so it's really a tradeoff.
…
Re. JavaScriptOSA: It's a pity its Apple event support is so flawed, as it's still the only more-or-less complete OSA language component outside of AppleScript. (There are others, but they're all either unfinished or provide only limited OSA support.) Mind you, if some JS guru wanted to develop an OSS version I'd certainly be interested in helping out. A JS-AE bridge would be useful to Dashboard folks too.
p.s. Rick, MacPython's built-in 'OSA' libraries are due for the chop as they're obsolete (superseded by appscript) and broken on Intel too.
Thanks for all the details has. You're spot on in pointing out that it'd be better to have "traditional" OSA in Vienna first before moving to something nice, but non-standard. I was trying out QuickSilver (yet again, for the 5th time: it just might stick this time) and wishing I could search through if not do more with Vienna (like subscribe to feeds? search feeds?)
Really what I need to do is take a look at Vienna's code and see if I can start hacking around with features and Cocoa.