Comments on: AppleScript vs. JavaScript?

By: Cote'

Cote' — Fri, 18 Aug 2006 13:40:08 +0000

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.

By: has

has — Fri, 18 Aug 2006 11:30:56 +0000

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.

By: Andrew Dupont

Andrew Dupont — Wed, 16 Aug 2006 20:42:03 +0000

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!)

By: Coty

Coty — Tue, 15 Aug 2006 14:27:02 +0000

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.

By: Rick Thomas

Rick Thomas — Mon, 14 Aug 2006 22:53:16 +0000

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.)

By: Danno

Danno — Mon, 14 Aug 2006 21:52:56 +0000

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.