Could AppleScript be the next scripting language of the web?

tell application "MarsEdit"
	activate
	make new post window
	tell post window 1
		set title to "[[pageTitle]]"
		set link to "[[pageURL]]"
		set body to "[[bodyText]]"
	end tell
end tell

tell webapp "30boxes"
	activate
	make new vcalendar event
	tell post vcalendar event 1
		set title to "[[eventTitle]]"
		set link to "[[eventURL]]"
		set body to "[[bodyText]]"
	end tell
end tell

15 thoughts on “Could AppleScript be the next scripting language of the web?”

1. As a Windows user and VBScripter, it really looks more readable (okay, I don’t count, I dream in HTML).
   Do you see this as a sort of API? Or might it be enough to hack a greasemonkey script/converter for that?

2. Y’know, I’m not sure. But as a stand-in for Greasemonkey in WebKit, I think it looks might fine!

3. Verbose programming languages are a real pain to code in if you are doing any real work.

4. Pingback: Mozilla Corporate Labs? at A Fool’s Wisdom

5. You’ve been able to do this at the server-side for donkey’s years using acgi (AppleScript CGI) which were originally supported by the WebStar server I think. A more robust implementation of AS that incorporated it directly into a RoR-like environment as you suggest (you can already use SQL from AppleScript–not exactly suitable for production web services though) would be pretty cool for Mac-heads but arguably only of interest to developers who don’t really want to learn ‘heavier’ languages (inevitably though such languages become more widely adopted with time).

   Having access to AppleEvents (inter-application communication) directly from a web-server, and thus almost within the web-browser could be pretty useful though. But an all-together more integrated event model between browser, server, and other applications is definately what’s needed, and AppleScript/AppleEvents are a nice way to imagine it, but themselves wouldn’t be up to the task performance wise.

   Here’s an AppleScript that demonstrates the simplicatity of an XML-RPC (SOAP is similar) call, which returns a nice record for the result.

   tell application “http://api.example.com/”
   call xmlrpc {method name:”wibble”, parameters:{wobble, wubble}}
   end tell

6. Wow, Jacob, would that XML-RPC example work?

   I see huge potential then for WebKit + AppleScript + Microformats… yum!

7. While applescript is a cool language for communicating with applications, I would SERIOUSLY hate to code in it. Just because a langauge is readible doesn’t mean it is nice to program in – I haven’t seen any startups using COBOL.

   I would actually say DSLs (domain specific languages) based on a powerful yet expresive langauge would be nice. Applescript is powerful because applications can expose functionality, but other languages can take advantage of this communication facility (a simplistic implimentation would be this ruby wrapper.)

   JavaScript is pretty powerful. A XUL Runner/WebKit powered app that was coded using JavaScript and could connect to external applications via AppleScript would be cool.

   Think of AppleScript as piping between apps – sure it might be possible to code simple applications using only it, but it isn’t something most people would want to do.

8. Chris, yes they’re commands that have been supported since 10.1. You can probably see why Apple wanted to expose AppleScript’s power better—through Automator.

   I like the idea of using it as a greasemonkey equivalent. It’d sure make developing ‘add-ons’ more accessable, however WebKit would have to expose the DOM thoroughly. This would actually then open up the possibility of AppleScript dashboard widgets. However this is all a bit unlikely, Apple have shown a commitment to JavaScript and you can in fact access the DOM from AppleScript in Safari through JavaScript (using the doJavascript command—but not yet supported by Camino). The fact that you can do scripting in Windows with JavaScript, and that Adobe uses JavaScript for scripting its applications suggests we might be moving towards that on both the web and desktop.

   BTW if you’re not familiar with the history of HyperCard/HyperTalk (AppleScript’s precursor) check it out.

9. AppleScript just makes my head hurt. I don’t know why. Perhaps because I never spend enough time with it at any given time but I just can’t retain the syntax and the ways it likes ‘english’ to be written. Every time I try and do something with it I feel like I’m learning it from scratch.

10. I’ve seen AppleScript described as “a read-only language” – sure, it looks great and seems more understandable to those who don’t already know it, but it’s a right bugger to code in. Programming languages that attempt to move towards natural language are mostly doomed to cause more confusion than they solve. They’re not just a leaky abstraction, they’re a REALLY REALLY leaky abstraction. (See Joel Spolsky’s great essay on the topic)

    It’s like this: You go, “Oh, that looks really easy, it’s just like English! Let me try coding something…” and then it doesn’t work. And you try something else and it doesn’t work either. And it turns out that to use it you have to be just as strict about your syntax as you would with any other programming language, so the main benefit of natural language – namely, its flexibility and fluidity – is lost, and you’re just left with something that’s not only not as compact as other programming languages, but more confusing because the natural language part of your brain keeps jumping in to derail you.

    The only good NL-based programming language I’ve seen is Inform 7, which is for creating text adventures. It’s genuinely one of the most innovative bits of software I’ve seen and a great pointer to the future of programming.But it’s worth bearing in mind that the main reason it works so well is that the programming language design maps *exactly* onto the problem domain, which is using prose to describe something and to handle incoming prose as well. Plus, Graham Nelson literally spent several years making the parser flexible enough purely to deal with that. If you tried to get it to handle, I dunno, 3d graphics, the whole thing would be unusable.

    In summary: lsnguages to suit the domain, innit.

11. Wow, I just stumbled across this via google, I was looking for microfromats and applescripts!

    I was just reading about microformats and was wondering if it were possible for applescript to parse them out of emails. Years ago I did something similar for a friend. I had setup Eudora with a rule/filter to run an applescript when the subject matched an “offical” ebay message for the winning bidder. It would scrape the message and update a Filemaker database and update the items record with the winners mailing address and final price. Then he would have reports for sales and be able to print mailing labels. It worked ok, but my friend was to lazy to list his items in filemaker and ebay finally came out with better tools anyway.

    Anyway, it might get me to switch from Thunderbird to Mail.app so I could use applecscript to scrape microformats from emails. I want to be able to schedule a meeting between two different users of two different systems. Or add them to my Addressbook, or add their birthday.

12. Well, I knew this was the response I’d get, so I guess I can say that I told myself so. 😉

    Brian — I like where you’re going, though just as you could do some cool stuff with Mail.app and AppleScript, you could do similar things with Thunderbird extensions and JavaScript… in fact, you could look at porting the Firefox Tails extension to Thunderbird.

    One other idea — maybe we just need a consistent way to access web content with AppleScript and some microformats-aware libraries for AppleScript? Sure, Safari has AppleScript capabilities, but Firefox and Camino don’t (though I hear it’s coming). Anyway, universal access to data between websites *and* applications is what I’m after here.

    Thanks for pointing out that AppleScript isn’t a panacea — I guess it’s time to look into AppleScript’s implemenation of JavaScript!

13. Random thoughts, as it’s not quite clear what you’re looking for:

    You could create an AppleScript-like syntax for JS, sure, and either write a cross-compiler to translate it into standard JS code or hook it directly into the AST layer if you’re feeling adventurous. (Just avoid the keyword injection mis-feature and stick to convenional identifiers.) Apart from a bit more novice appeal, I can’t see any practical advantage to doing this though.

    If you’re thinking of adding Apple Event Object Models to web applications, be aware that implementing an AEOM is a non-trivial task. While its query-driven nature is great for users in terms of usability, and the ability for individual commands to operate on multiple objects at once ideal for situations where communication overheads are high, these features are also rather tricky to implement robustly (even Apple’s own Cocoa Scripting framework doesn’t get it completely right).

    AppleScript is dead as a serious CGI/webapp implementation choice. That boat sailed years ago. While you can still write .acgi scripts (you’ll need ACGI Dispatcher to use them as there’s no longer direct OS support), the language itself is painfully underpowered, and there’s zero web-related infrastructure (compare to PHP, Perl, Python or Ruby).

    If you want your webapps to communicate with local desktop processes via Apple events, either use osascript or a native Apple event bridge. I’m not aware of any PHP-AE bridges, but Perl and Python both have mature third-party bridges (Mac::Glue and appscript respectively; I wrote the latter, btw) and there’s a high-level bridge under development for Ruby (see RubyOSA on RubyForge).

    You can control scriptable apps from JavaScript – sort of. See JavaScriptOSA, which is Mozilla’s JS interpreter packaged as an OSA component. Its Apple event support has significant flaws, however, so it’s only semi-usable, plus only operates within an OSA context (Script Editor, attachable applications, etc.) which probably isn’t what you’re looking for.

    If you’re looking to control desktop processes across a network, don’t forget that Remote Apple Events are another option as long as the clients are trusted Macs.

14. Pfaw! And could COBOL make a comeback? Not a chance! My friend left his macbook at my house a few days ago. He’s a moderate hereditary mac-cultist who brags about the lack of virus for macs. So I made a little “virus” script before giving it back to him. Oh the horror and pain, it was COBOL! They’re trying to bring back the dead and make a zombie army. 😉

15. I’ve programmed in C,Perl,Java,VB and I think AppleScript language is very underrated. After checking it out a few times, and dismissing it as most of you have, I gave it a real shot and started programming in it. It is amazing. The only issue is speed, as with most scripting languages. I would like to start doing webdev with it, but at the moment I can’t find any info, and certainly not a framework.