JavaScript as an alternative to AppleScript on OS X Yosemite

https://developer.apple.com/library/prerelease/mac/releasenotes/InterapplicationCommunication/RN-JavaScriptForAutomation/index.html#//apple_ref/doc/uid/TP40014508

by bpierre • 12 years ago

410 116 12 years ago

developer.apple.com

yror10• 12 years ago

It would be cool if they also add some kind of support for swift (or some variant) too.

chaz72• 12 years ago

plot twist: a Swift-to-JS compiler

DAddYE• 12 years ago

will be a very simple step since swift is a llvm frontend and we already have this great tool: https://github.com/kripken/emscripten

zyxley• 12 years ago

This makes me really happy.

I kind've wish they'd used $ for what Application() is, though, to keep an analogous similarity with jQuery and the like.

jiggy2011• 12 years ago

$ = Application;

Easy fix!

nkozyra• 12 years ago

You've successfully hacked Javascript!

angilly2• 12 years ago

Not if you want to use the Obj-C bridge, though :)

"The primary access points for the Objective-C bridge are the global properties ObjC and $."

jonknee• 12 years ago

That's easy to do on your own though:

   var $ = Application;

hackmiester• 12 years ago

Could there be any reasonable situation where one might want to load jQuery within this environment, though?

(Although, I suppose, you could use another var for jQuery, such as, uh, 'jQuery' ...)

pygy_• 12 years ago

jQuery is a DOM manipulation library, it is not useful to script OS X apps.

...unless one of them exposes a HTML DOM to the scripting layer, now that I think of it.

mbauman• 12 years ago

AppleScript contains some amazingly powerful APIs, but is nearly impossible to write. Having a Javascript (successor?) implementation is going to unleash its full potential. I could see it becoming much more widely used and supported by third party apps. This is wonderful.

In the same cycle that they release a brand new language, they begin the deprecation process for their (only?) other proprietary programming language in favor of an existing language. Pretty cool.

judk• 12 years ago

As braindead as the language was, the real problem with AppleScript was the bizarre object model, so the Object help doc was full of nonsense methods that did nothing useful. Finding the one method doExactlyOneSpecificThing that matched what you need was always a low-probability event. The opposite of the UNIX philosophy and modular design.

rmrfrmrf3• 12 years ago

Yep. Script Debugger was almost a requirement for doing any serious AppleScript hackery. You can explore an open application's exposed objects and tell Script Debugger to paste the path to it into your current script. Way better than guessing when you need to `tell x` in order to expose its properties or whatever.

The most underrated thing to me that made it all worthwhile, though, was Remote Scripting. I think the full potential of it has yet to be realized, and hopefully JavaScript will allow some impressive future developments.

riffraff2• 12 years ago

is this going to be solved by writing it in javascript though?

Looking at the sample code in this page:

   Mail.outgoingMessages.whose({subject:'JavaScript'})

is doesn't look much better.

Camillo2• 12 years ago

You're not actually supposed to have doExactlyOneSpecificThing methods in AppleScript. Instead, you are supposed to have a small number of verbs that can operate on a large number of objects and their properties. It was REST before there was REST. Unfortunately, this design principle was often misunderstood by those writing scripting interfaces for applications.

It also didn't help that Apple provided very little support for implementing the language's rich query model, which led to many applications only implementing one or two ways to access objects, often with bugs. That was the source of most of the annoyances with AppleScript.

sriku3• 12 years ago

AppleScript was originally conceived to be easy enough for non-professional programmers to read and write, with the history of Hypercard behind it. This is for those rare occasions when they needed to automate something that they do with multiple applications manually. At one point, you were able to hit "Record", do the things that you needed to be automated and boom you get a script that you can begin to massage into something reusable. You didn't need to be a programmer to read this recorded script and you didn't need to know English to read/write it either (it was available in other languages). It looks like Apple realized that automation is the core problem they need to solve and made .. Automator instead, which is based on the same underlying piping - OSA.

edit: Back in 1998/99, I even wrote a web server entirely in AppleScript - it was a platform for our research lab to share, debate and record ideas.

wlesieutre• 12 years ago

Automator even has the same "record" functionality for repeating tasks in a UI[1]. The direct Automator actions like "scale image" are cleaner when they exist, but including Automator actions with 3rd party applications didn't catch on as much as it could have.

Some apps have them (Pixelmator comes to mind), but for the most part it doesn't have the support that AppleScript used to. It's a bit sad that we now have easier automation (via IFTT) in a huge pile of webapps than many native programs where it hasn't improved in the last 10-20 years.

[1] http://www.macosxautomation.com/automator/features/virtual-u...

tlrobinson• 12 years ago

That reminds me... the first "web app" I ever built was a home automation interface, hacked together with AppleScripts, because that's all I could figure out how to do on my Mac in high school (circa 2001). I don't remember how the webserver portion of it worked (but I definitely didn't implement it myself)

hrktb• 12 years ago

Applescript was only a front end for OSA, for instance there is/was a working perl front end for OSA. The reason it never really took off is mostly due to OSA itself, and not the scripting language I think.

For instance most of the Adobe product don't care about OSA and offer a Lua extension mechanism instead (even there, I feel they only cared avout filters and publishing modules). Or even iPhoto had severe limitations on what could be done through the scripting interface.

The Finder has perhaps the most useful interface, but anything done there can also be done in the shell IMO. There must be other apps exposing very useful functionalities to OSA, but I haven't see many.

gcanyon• 12 years ago

Others have touched on this farther down, but this always sets me off: AppleScript is not confusing because of its native syntax. It's confusing because of the inconsistent, often contradictory, incomplete, and sometimes just insane dictionaries provided by the various apps you access with AppleScript.

Switching to JavaScript will do exactly zero to fix that. However, there appears to be new functionality inherent in the implementation, including better integration of native code (oddly, the examples are in ObjC instead of Swift), and I assume this will be faster than AppleScript. If this increases the popularity of writing scripts, then perhaps app-writers will improve their dictionaries.

oceanstone• 12 years ago

Scripting additions (plugins for scripts) can be used to enhance the functionality of applications. The OS has a set of standard scripting additions available. These offer things like speaking text and user interaction dialogs.

app.say('This is exciting')

radio4fan• 12 years ago

Scripting additions have always existed...

I used work for a living in AppleScript nearly 20 years ago. Heavy drinking helps block out the memories.

angilly2• 12 years ago

Haven't wrapped my brain completely around this yet, but I wonder if it's going to allow for some cool (and/or dangerous?) crossover write-once-run-in-browser-or-locally apps.

JohnBooty4• 12 years ago

I don't think that's the case. AppleScript is the equivalent of shell scripting for GUI appls.

You don't write applications in AppleScript; you use AppleScript to control other applications in an automated way.

You can write AppleScripts with simple dialog boxes and such, just as you can write interactive bash scripts. And while you could theoretically implement an application entirely as a shell script or batch file or AppleScript, it'd be a bit like mowing your lawn with a pair of scissors.

jasomill2• 12 years ago

While never particularly popular, both Apple (AppleScript Studio and subsequent AppleScript Xcode templates) and third parties (FaceSpan) have provided full IDEs for developing applications with AppleScript.

JohnBooty4• 12 years ago

I love AppleScript because whenever somebody asks, "Why don't they make programming languages more like English?" all you need to do is show them AppleScript.

The functionality exposed by OSX apps via AppleScript is often incredible, but the language itself is annoying.

The question is whether or not applications will support it. With the emphasis shifting away from OSX desktop applications to cross-platform and cloud apps, will OSX app developers still take the time to expose scripting functionality?

coderzach• 12 years ago

You show them AppleScript and SQL and they say "Wow, what was I thinking, english is a terrible basis for a programming language."

pconner• 12 years ago

SQL makes sense, but at its core, it's a query language, not a programming language. You can do lots of arbitrary computation with it if you want and use it for things it's not good at, but for its intended purpose, it works pretty well.

meritt• 12 years ago

SQL is pretty damn simple.

JohnBooty4• 12 years ago

SQL is fantastic for relational data - it maps pretty closely to relational algebra.

About all I'd change is placing the column names after the table/object names - "FROM table1 SELECT col1, col2" instead of "SELECT col1, col2 FROM table" because it makes code assist features easier. (Microsoft did this with LINQ)

coldtea3• 12 years ago

Well, if they think that about SQL, they are wrong.

SQL is more like math than natural language. That it is declarative doesn't make it like Applescript.

bla2• 12 years ago

I love AppleScript because whenever somebody asks, "Why don't they make programming languages more like English?" all you need to do is show them AppleScript.

Yup :-) AppleScript has an interesting history, it used to support multiple "natural languages" (such as French, ...) in addition to English: http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf

(This is probably why many AppleScript Guides still say "English Dialect" on the first page, e.g. http://download.info.apple.com/Apple_Support_Area/Manuals/se... )

Here's a Dijkstra rant from '77 against natural language programming: http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667....

cnp• 12 years ago

Wow! That dissertation is so interesting.

turingcar5• 12 years ago

For the record, AppleScript is not “natural language programming”; it is merely more similar to English than most programming languages. As with most mainstream programming languages, human terms (usually English) are used for keywords like “if”, “then”, “else”, “while”. It still has a very limited and structured grammar, like most programming languages.

In deference to the expressive flexibility demanded by humans, it does provide a few alias terms (“=“, “equals”, “is equal to”) and a few places where something can be written either left-to-right or right-to-left (“name of document” vs. “document’s name”), but even that is common in other languages. e.g., document.name vs. name(document), foo(bar.baz()) vs. bar.baz().foo(), and C’s support for both ”! && ||” and “not and or” operators.

Obviously, tastes vary, and I’m not trying to convince anyone that they should like something they don’t, but often people who complain that AppleScript is unlike languages they are more familiar with have only taken a cursory look at examples of AppleScript and are unaware that it has a syntax that is in fact similar to other languages. The primary differences are that it is very light on punctuation and prefers using descriptive words over abbreviations, because its goal is to be approachable for first-time and casual programmers. Even for AppleScript experts, this often helps make understanding or maintaining code easier.

Personally, I’d like to see AppleScript support some more “compact” syntax, like square brackets for array references, but I do not think it’s reasonable for AppleScript’s target audience to have to learn the meaning of “a ? b : c” before they can read simple conditional statements like “if a then b else c”.

Camillo2• 12 years ago

HyperTalk was surprisingly ok, though.

gilgoomesh3• 12 years ago

HyperTalk was brilliant because everything seemed to just naturally work. The grammar and object model were both highly intuitive – you really could just guess the right syntax.

AppleScript and HyperTalk are aesthetically very similar but every time I have to write something in AppleScript I get oddball parse errors that I can never decipher and I need to randomly try things until an approach succeeds (for reasons I don't understand) or I give up.

Where HyperTalk was friendly and forgiving, AppleTalk is punishing.

gilgoomesh3• 12 years ago

AppleScript is not a solid argument against natural language derived programming languages in general. AppleScript's problems have more to do with the fact that it looks like it should be flexible and powerful but in reality it is fairly limited and inflexible (and its documentation and error reporting are terrible, compounding its problems).

Someone• 12 years ago

I think AppleScript's problems have more to do with the fact that it relies too much on external parties to do its stuff. The moment you do

  tell application "foo"
    every bar whose third baz is frob
  end tell

whatever you write in that tell phrase gets executed by application "foo" (the logic runs in the process, and has to be written by the implementers writing the "foo" application). Implementing that flexibility is lots of work and hard because Apple did not supply much support libraries (1). Because of that, all implementations were incomplete (and differently so) and buggy. That "and differently so" was the main reason one cannot get comfortable writing AppleScript. Even if the above worked, there was no guarantee that, for example

  tell application "foo"
    the third baz of every bar
  end tell

worked.

The essence of AppleScript goes very far:

- The editor imports syntax from "foo" the moment it sees that tell application "foo" block.

- When compiled, it converts that into a standardised binary format (an Apple Event)

- When run, AppleScript sends that event to "foo", and "foo" parses and executes it.

In essence, it turns application "foo" into a service that shows its internal state in its GUI (in 1993).

(1) in their defence, I don't think they could have written good support libraries in the language of the day. A few C++ 'interfaces' in header files might have helped, though.

matthewmacleod2• 12 years ago

You know what's pretty cool? This potentially allows native MacOS applications to be written in JavaScript... Not that I can see any reason to do that.

stevejohnson3• 12 years ago

(Downvoters of parent, please stop, it's a perfectly reasonable comment.)

While you're correct that JS can now be used to write Mac applications without an Obj-C wrapper, that's not really the point of this.

Anyway, you can already write Mac applications in JavaScript. And iOS applications! This has been true since iOS 7 and Mavericks. http://strongloop.com/strongblog/apples-ios7-native-javascri...

You can build double-clickable "applets" in AppleScript and JavaScript, but the OSA interface isn't really made for app development, just automation.

However, they do expose all Cocoa and Obj-C APIs to JavaScript, so anything is possible! They even do a demo of a standalone temperature converter at the end of the WWDC session.

https://developer.apple.com/videos/wwdc/2014/#306

philmcc• 12 years ago

After a quick search I couldn't (readily) find any links about writing Mac apps in Javascript. The Strongloop seems to be for iOS7 only. Where would I find out more about this?

matthewmacleod2• 12 years ago

Yeah, I suspect I was a bit unclear there!

I'm pretty familiar with ObjC-Javascript integration and have been working with it for a while. This change offers a nice direct system interface for automation, and one that has access to all of Cocoa.

I also didn't intend to put Javascript down at all - its more that the more complex part of building a MacOS app is working with Cocoa, and Javascript will make that more complex, rather than simpler, just because of the impedance mismatch.

I'm not sure there's a compelling use case for building such apps, but it's still pretty cool!

cstross• 12 years ago

Stupid and uninformed question here:

Given Apple's well-known antipathy to the idea of browser engines other than WebKit and scripting languages other than JavaScript on iOS (yes, yes, I know you can find Python/Lua/Lisp/whatever apps on iOS; I mean as a general rule and for inter-app automation), could this be a prelude to allowing some sort of sandboxed-app automation interface on iOS? That is, allow a JavaScript implementation running on iOS to "drive" apps via this object model?

(Genuine question here. I have no idea whether I'm blowing smoke or whether this is a plausible long-term direction for Apple to take iOS.)

nexuist• 12 years ago

I'm not sure if this answers your question, but you've been able to execute native javascript in your apps since iOS 7: https://developer.apple.com/library/mac/documentation/Carbon...

stevejohnson3• 12 years ago

Genuine answer here. There's no need to apologize for not constantly immersing yourself in the workings of Apple platforms. :-)

JavaScript is just another interface to Apple's "Open Scripting Architecture (OSA)." Previously, AppleScript was the only way to use it. The fact that they added another language indicates nothing about whether OSA will ever come to iOS. My guess is it won't; the new extensions APIs will likely handle any inter-app communication Apple wants to allow, because they are designed with iOS's sandbox model in mind already.

Put another way, Javascript is to AppleScript with respect to OS X automation, as Scala is to Java on the JVM. The existence of Scala does not indicate that the JVM will be ported to the Haiku OS. (There may be a better analogy but that's what I came up with.)

steveax• 12 years ago

There are other language interfaces to OSA. Frontier's UserTalk was an early implementation (and much more useful than AppleScript IMO) IIRC, there are also Python and Ruby bindings as well.

0x0• 12 years ago

For developers, I think you can write ui automation tests in javascript for your own app during debugging/testing.

In the general case, for published apps, I'm not seeing it happen. Apple seems to be super focused on sandboxing and separating components on iOS. Even with the new iOS8 extensions, everything needs to be user triggered and even then, extensions live on separate islands.

It's doubtful they'll change that model since it would defeat the "you can't break your idevice even if you tried" feeling for end users and the app store.

gilgoomesh3• 12 years ago

Javascript in this case has nothing to do with web browsers. It is simply a scripting language used to manipulate OSA (Apple's cross-application automation API in Mac OS X). Since OSA is not part of iOS, this likely won't affect iOS at all.

You actually can use Javascript to automate iOS apps running in Instruments (one of Apple's developer tools). This is used for automated UI testing in the iOS simulator or while your iOS device is tethered to a Mac. This has been around for a couple years and there's no indication that it will ever be permitted in released applications. There's actually no reason to enable it – it's only useful for snooping on apps (good for developers, bad for users).

saurik2• 12 years ago

If anyone wants to do stuff similar to this on earlier versions of OS X (but arguably even more generally) or on iOS they should look at one of my projects, Cycript, an Objective-C/JavaScript hybrid with a highly-bridged Foundation/JavaScriptCore object model that can inject code into running applications.

http://www.cycript.org/

(I expect to have the ability to introspect and manipulate Swift objects in the near future as well, and have a talk on preliminary research of low-level Swift object runtime metadata at #AltConf a couple days ago. The console will also support some of Swift's syntax, such as the named-argument-style method calls.)

https://www.youtube.com/watch?v=Ii-02vhsdVk

jevinskie• 12 years ago

earlier versions of OS X

Will Cycript work on 10.10 or are you just saying that you'll have two JS choices now (Cycript and JS Automation)?

I use Substrate all the time, I really need to look into Cycript! =)

saurik2• 12 years ago

The Apple thing only works on 10.10 (which most people reading this wouldn't be using currently), so I am saying that there is an option for earlier systems. Cycript actually doesn't work on 10.10 right now (well, it does, but it is frustrating to use as you have to keep saying this. before global variavles) due to a change made in JacaScriptCore that I am unhappy with (talked to some people at Apple, filed a bug with WebMit, and am checking with a friend of mine on the ECMAScript committee), but I have a reasonable workaround I can use for non-Cydget use and for Cydget crazy one-off Substrate hacks are fair game, so I should have everything fixed soon for a new release.

slmnm• 12 years ago

Forgive me for hijacking the thread. The op is currently featured on the front page for 3 different stories. It's pretty cool!

https://news.ycombinator.com/submitted?id=bpierre

Edit: Didn't mean to sound critical with "is this normal" comment. Just pointing out.

pixelmonkey• 12 years ago

"Because JavaScript is the language of the web browser, and because the web browser has become the dominant application delivery system, and because JavaScript isn't too bad, JavaScript has become the World's Most Popular Programming Language. Its popularity is growing. It is now being embedded in other applications and contexts. JavaScript has become important.

It is better to be lucky than smart."

- Douglas Crockford, 2008

gvargh2• 12 years ago

Could not have happened to a better language! It's about time Javascript finally has its chance to shine.

lucian1900• 12 years ago

That's the whole point, it could've happened to a much better language.

stevejohnson3• 12 years ago

A lot of people in this thread have misconceptions about what AppleScript is and what it means for JavaScript to be an alternative. I recommend watching the WWDC session [1] if you can, and skip to 16 minutes in (through minute 20) for a quick explanation of what this actually is.

TL;DR shell scripting for the GUI, not a way to build Mac applications (which you can already do with JS).

Edit: video link

Double edit: Looks like I'm slightly wrong about using JS to build apps this way. You can bundle scripts as applications, and OSA can create windows and controls, so you could hypothetically build whole apps this way. But I'm not sure I would want to.

[1] https://developer.apple.com/videos/wwdc/2014/#306

eknkc• 12 years ago

What video?

basil• 12 years ago

306 - JavaScript for Automation

pjbrunet• 12 years ago

http://devstreaming.apple.com/videos/wwdc/2014/306xxjtg7uz13...

willismichael• 12 years ago

If I were a Mac user I could really get behind this if only for the fact that it means support for any language that can compile to Javascript (particularly Clojure)

jarek-foksa• 12 years ago

Not sure why people would still want to use JavaScript to interoperate with Cocoa interfaces, Swift is easy enough to be used as a scripting language and it was designed to work nicely with Cocoa.

To me it makes more sense to either go completely native with Swift and Cocoa / Cocoa Touch or use hybrid model where HTML 5 content is embedded with the new WKWebView API (aka WebKit 2).

WebKit 2 framework will become public in iOS 8 and OS X 10.10 which means hybrid HTML5/Native apps will be able to run with full speed thanks to JIT, split process model and other optimisations.

js2• 12 years ago

The problem with AppleScript isn't so much the language as much as the OSA[1] itself which is really hit-or-miss depending upon how much functionality any particular app chooses to make scriptable, much less actually document in its dictionary.

As to AppleScript's deficiencies, in the past I've used py-appscript[2], though apparently it's no longer developed.

1. https://developer.apple.com/library/mac/documentation/apples...

2. http://appscript.sourceforge.net/py-appscript/index.html

sdegutis2• 12 years ago

This is just so insanely insane. I have such mixed feelings about this.

On one hand, it's really exciting that Apple is taking these huge steps in making our lives as programmers easier. And yeah, I wish they had done this when JSTalk came out, but better late than never.

On the other hand, it really sucks that JavaScript is the new universal scripting language. Swift and JavaScript are now the two blessed languages on Apple platforms. I mean, I get why, but man, JS is just so awful.

rmrfrmrf3• 12 years ago

From the spec, it seems that they've improved on a few things (integers being the big one).

sdegutis2• 12 years ago

You know, Apple essentially made a new way to build full-fledged Cocoa applications using a dynamic interactive language. You could literally write a whole GUI app in a single JS file without even touching Xcode. That's... kinda awesome.

aquanext• 12 years ago

wert da ferk! ( what happened to apple! this is awesome. :D )

jastanton• 12 years ago

Atwood's Law in action, I love it :)

sandGorgon2• 12 years ago

so, I'm a little confused here - more than a year ago, the Gnome Project picked Javascript as its primary dev language and it was linked here on HN (https://news.ycombinator.com/item?id=5169599)

That entire thread is around how Javascript is a bad paradigm for desktop. But, this entire thread is how amazing javascript is going to be for OSX.

Let me add that the JS programming model of Gnome is what powers http://extensions.gnome.org - and I have my own extensions in there. Also (and correct me if I'm wrong) the "GObject Introspection" mechanism is fairly analogous to OSA.

So, is there a underlying technical or implementation issue that makes it good on OSX and bad on Gnome ? use case? technology ? OSA ?

belandrew• 12 years ago

They're very different use cases.

Applescript is used for automation of already existing applications which will still be written in C++ or Objective C. Applescript, a proprietary language with no other uses, is just being replaced by a much more common language in Javascript so people won't need to learn a new one to automate apps. People don't generally write applications using Applescript and they probably won't be using Javascript, so there's little overlap.

In GNOME Javascript is being used to write the applications in the first place. There is total overlap between Javascript and C/C++.

People see the GNOME choice as both redundant and reducing performance of desktop apps while people see the Apple choice as simply using a common language instead of a proprietary one for scripting.

sandGorgon2• 12 years ago

not entirely true. Gnome has a first class language - Vala [1] - that is for writing performant system level applications. And the community is quite active as well - https://github.com/trending?l=vala

If you think of automation, there have been attempts at bringing flow based programming to the Gnome-JS engine (think of it as Quartz Composer integrated into the desktop) [3] - plus the fact that http://extensions.gnome.org is about as automatic as you can get to customize the desktop.

Is it a difference in positioning ? Because honestly I'm a little befuddled on why all the developers on HN get supremely excited about JS on OSX... and not something like NoFlo.js integrated into Gnome.

[1] https://github.com/GNOME/vala [2] http://lethalman.hostei.com/maja/index.html [3] http://bergie.iki.fi/blog/noflo-and-gnome/

pjmlp• 12 years ago

I was watching the talk and thinking all the time, Apple just discovered OLE Automation.

Yes, I know that Open Scripting Architecture is also quite old, but having now JavaScript bindings and the types of demos they made, just reminded me of it.

Derbasti2• 12 years ago

Oh Javascript. This has been said so many times before, but why, oh why, has the world converged on this particular language?

Why aren't there saner alternatives to Javascript in browsers? We have so many languages at our disposal, why choose Javascript? Why don't people realize that web programming is not great because of Javascript but despite Javascript?

We are bound to Javascript on the web because browsers, for whatever reason, don't support anything else. But we don't have to make matters worse by dragging this weirdo language unto the rest of the programming world.

But who am I kidding, AppleScript may be one of the few languages actually worse than Javascript.

yoklov• 12 years ago

JavaScript isn't that bad. It certainly has it's faults but there are much worse languages that could have become ubiquitous than JavaScript.

Honestly, I find web programming to be generally terrible. JavaScript is actually one of the better parts of it.

Most of the time I work in C++ these days though.

Derbasti2• 12 years ago

You already know all the good stuff about weak typing and equality.

But let me give you a few recent examples I stumbled over: - Javascript can not format numbers with leading zeros. - Handling binary data is increadibly painful. - Object oriented programming is really convoluted. - Lack of classes and modules makes code structuring hard.

True, it could be worse. But Lua, Ruby, Python, Perl, Scheme, Clojure, and many others are much better languages with very similar feature sets. And then there's a whole host of languages with different features. I just don't see why you would Javascript in an environment where all these other alternatives are available.

facepalm• 12 years ago

Why don't people like you recognize the greatness of JavaScript?

Which language would be preferable? Perhaps Lua? Not much else with comparable simplicity comes to mind.

pirateking• 12 years ago

Scheme.

poweribo• 12 years ago

good thing these other nicer languages compiles to javascript: typescript, kotlin, clojurescript

polskibus• 12 years ago

I remember that Windows have had very powerful JavaScript scripting for ages (windows xp or earlier), later they forgot about it and created Powershell. Interest ing to see apple now using the same idea on their platform after so many years.

Nemcue• 12 years ago

As an aside: if you want to use JS /today/ as an OSX Window Manager (hotkeys, resizing, switch screen etc), you should check out: https://github.com/sdegutis/Phoenix

I've been using it for a couple of months now, and it's been glorious! So being able to do more things in JS makes me very excited.

Groxx• 12 years ago

This means I may actually start scripting apps again. Applescript is a bit of a mess, at least I'm experienced with Javascript.

I wonder if this will imply (significantly) better debugging tools? Like a way to debug a javascript-script in Safari, sorta like iOS webviews?

milos_cohagen• 12 years ago

This is cool because as a programmer I found AppleScript difficult to pick-up quickly. However, after a recent foray into writing scripts for iPhoto and iTunes, the api's and documentation of those apps totally turned me off.

I'll be interested once I see some succinct JS to show me most played songs in last week, or recent photos imported from iCloud.

SimeVidas• 12 years ago

ELI5: What is AppleScript and how does it relate to Swift and Objective C?

cormullion• 12 years ago

I'm going to miss AppleScript - in both obvious senses of the word. It was a language I used to swear by, and at. I spent hours getting scripts to work, so I've became used to the language's infelicities, but was always frustrated by the lack of tools. Here, for example, is how I gather you're supposed to change the case of a string:

on change_case(this_text, this_case) if this_case is 0 then set the comparison_string to "ABCDEFGHIJKLMNOPQRSTUVWXYZ" set the source_string to "abcdefghijklmnopqrstuvwxyz" else set the comparison_string to "abcdefghijklmnopqrstuvwxyz" set the source_string to "ABCDEFGHIJKLMNOPQRSTUVWXYZ" end if set the new_text to "" repeat with this_char in this_text set x to the offset of this_char in the comparison_string if x is not 0 then set the new_text to (the new_text & character x of the source_string) as string else set the new_text to (the new_text & this_char) as string end if end repeat return the new_text end change_case

I'm assuming that this will be easier using JavaScript... :)

turingcar5• 12 years ago

There has been no statement that AppleScript is going away or being replaced by JavaScript for Automation. This is simply a case of offering users more choices.

AppleScript’s primary target audience is first-time and casual programmers. (Of course, there are professional programmers writing applications and utilities in AppleScript, too.)

tedchs• 12 years ago

Does this mean AppleScript will actually be documented now? The problem historically has been code is written from random examples, without actual reference docs that make it possible to discover what's available.

nsfmc• 12 years ago

The thing i'm not totally sold on is that for arg-free alloc/inits, you can forego 'calling' those methods at all so you get code like `task = $.NSTask.alloc.init;` but sometimes you have code like `ObjC.super(this).init;`. So although you're actually initializing a new object, casually glancing through the code makes it seem that you're actually just accessing a property on NSClassName. Jstalk/cocoascript i think get this right with `NSWhatever.alloc().init()`.

Still, it's a bit weird and it makes me think that the poor folks working on this didn't know what the swift folks were doing because if they had, i suspect that the cocoa-bridged syntax would feel even more natively javascripty than it does right now rather than what's here. For comparison

    // in swift
    var color = UIColor(red: 0.61, green: .71, blue: .23, alpha: .8)

    // in js for automation
    var color = $.UIColor.colorWithRedGreenBlueAlpha(.61, .71, .23, .8);
    
    // but why not use objs for named args?
    var color = $.UIColor({red: 0.61, green: .71, blue: .23, alpha: .8})

Of the two, the swift feels the most js-native to me because you can easily hallucinate the {}s from the third example. But even if you're creating a js bridge and you're apple, why even force people to deal with alloc/init anymore? Even the registerSubclass syntax feels like a concession

Don't get me wrong, I think it's great that we're getting better applescript support via js, but it's definitely an area where the implementation feels like a step back from cocoascript and jstalk, at least with both of those the syntax highlighted when you were engaging in nonidiomatic behavior but at least both tried their best to paper over it.

What should have been a lightweight approach actually feels more heavyweight than writing equivalent code in swift instead, which makes me sad because i like js and i would have really liked for this to have been more approachable.

bobbyi_settv• 12 years ago

why not use objs for named args?

Because then there is no way of conveying the order of the parameters. In this case, it's ambiguous whether the method we are calling is colorWithRedGreenBlueAlpha, colorWithGreenBlueRedAlpha, etc.

Zelphyr• 12 years ago

Order doesn't matter in the above example. In the method body you'd reference arguments[0].green when you wanted green.

vinalia• 12 years ago

The one thing I still like about AppleScript is the GUI scripting. I don't know of any other way to control the mouse position, clicking, and keyboard input using a programming language.

One time I had to fill out a few thousand pdf files and print only select pages from them (like pages 2-4 and 14-22) for a client. I used applescripting because it was easy to write (took about half an hour) and worked consistently. Are there any other ways to do GUI scripting in OSX?

JavaScript as an alternative to AppleScript on OS X Yosemite

Related Stories