
JavaScript as an alternative to AppleScript on OS X Yosemite - bpierre
https://developer.apple.com/library/prerelease/mac/releasenotes/InterapplicationCommunication/RN-JavaScriptForAutomation/index.html#//apple_ref/doc/uid/TP40014508
======
3JPLW
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
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.

~~~
riffraff
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.

~~~
meowface
I never understood the cutesy naming schemes. What's wrong with .filter or
.where.

~~~
nilliams
Agree. Hopefully (?) it's just JS by the point we get to
`Mail.outgoingMessages` so it should be fairly straightforward to mix-in
underscore's methods into whatever their 'collection' representation is, the
same way Backbone does [1] to give you map/filter/which etc.

[1] [http://backbonejs.org/#Collection-Underscore-
Methods](http://backbonejs.org/#Collection-Underscore-Methods)

------
JohnBooty
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
You show them AppleScript and SQL and they say "Wow, what was I thinking,
english is a terrible basis for a programming language."

~~~
JohnBooty
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)

~~~
delian66
I guess the reasoning for the 'SELECT ... FROM' is that the FROM part is
optional, for example you can do stuff like 'SELECT 40+2 AS the_answer' .

------
saurik
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/](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](https://www.youtube.com/watch?v=Ii-02vhsdVk)

~~~
jevinskie
> 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! =)

~~~
saurik
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.

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

~~~
facepalm
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
Scheme.

------
pixelmonkey
"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

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

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

~~~
gvargh
Really? I don't see anything particularly wrong with Javascript... I mean,
sure it's no PHP, but compared to travesties like Lua (1-based, seriously?
What year is it again?) and bloated, convoluted semantic messes like Python
and Ruby... well there aren't many choices left!

Google, Mozilla, Microsoft, and Opera (and obviously Apple) haven't exactly
been jumping at the opportunity to deprecate Javascript in or out of the web.
I mean hell, now we have technologies like Node and asm.js that make
Javascript the fastest dynamic language in existence! People are even using it
in embedded hardware now! So it can't be nearly as bad as people say.

~~~
Goopplesoft
> I mean, sure it's no PHP

Yup, we're getting trolled...

------
stevejohnson
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](https://developer.apple.com/videos/wwdc/2014/#306)

~~~
eknkc
What video?

~~~
pjbrunet
[http://devstreaming.apple.com/videos/wwdc/2014/306xxjtg7uz13...](http://devstreaming.apple.com/videos/wwdc/2014/306xxjtg7uz13v0/306/306_hd_javascript_for_automation.mov?dl=1)

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

~~~
stevejohnson
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
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.

~~~
draegtun
Yes and a Perl bridge as been part of OS X for even longer time (just type
_man PerlObjCBridge_ form terminal).

Additional refs:

\-
[https://developer.apple.com/library/mac/documentation/Darwin...](https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/PerlObjCBridge.3pm.html)

\-
[http://www.macosxautomation.com/applescript/features/scripti...](http://www.macosxautomation.com/applescript/features/scriptingbridge.html)

\-
[https://developer.apple.com/library/mac/documentation/Darwin...](https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/BridgeSupport.5.html)

------
sandGorgon
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](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](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
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.

~~~
sandGorgon
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](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](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](https://github.com/GNOME/vala) [2]
[http://lethalman.hostei.com/maja/index.html](http://lethalman.hostei.com/maja/index.html)
[3] [http://bergie.iki.fi/blog/noflo-and-
gnome/](http://bergie.iki.fi/blog/noflo-and-gnome/)

------
nsfmc
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
> 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
Order doesn't matter in the above example. In the method body you'd reference
arguments[0].green when you wanted green.

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

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

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

~~~
stevejohnson
(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...](http://strongloop.com/strongblog/apples-ios7-native-javascript-
bridge/)

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](https://developer.apple.com/videos/wwdc/2014/#306)

~~~
matthewmacleod
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!

~~~
Glide
I think you were being downvoted because some people (myself included) roll
their eyes when they hear about Javascript yet again. It goes double when
there is a good language already out there (I accept Objective C with its
warts. Swift actually has me excited to make something).

It actually kind of cool. And the Temperature Converter example showed a lot
of the dynamic nature of the objective C runtime. This one presentation
actually piqued my interest in looking at os x scripting.

------
Nemcue
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](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.

------
js2
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...](https://developer.apple.com/library/mac/documentation/applescript/conceptual/applescriptx/concepts/osa.html)

2\. [http://appscript.sourceforge.net/py-
appscript/index.html](http://appscript.sourceforge.net/py-
appscript/index.html)

------
ChrisAntaki
> 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
Scripting additions have always existed...

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

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

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

------
jarek-foksa
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.

------
vinalia
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?

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

------
Groxx
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?

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

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

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

~~~
chaz72
plot twist: a Swift-to-JS compiler

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

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

~~~
JohnBooty
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.

~~~
jasomill
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.

~~~
JohnBooty
I didn't know that!

~~~
jasomill
Incidentally, I'd still mostly agree with your comment, as the underlying
script runtime isn't really designed with application development in mind. For
example, I'm pretty sure Xcode debugging support for AppleScript doesn't even
include breakpoints or related features like single-stepping (Apple's Script
Editor certainly doesn't), and that Script Debugger had to pretty much
implement its own AppleScript runtime to support these features.

On another side note, while Yosemite is the first time Apple has supplied or
supported JavaScript as an OSA language, third parties have integrated the
Mozilla JavaScript engine into OSA in the past in what I believe is an
abandoned project (Google "JavaScript OSA").

------
zyxley
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
$ = Application;

Easy fix!

~~~
angilly
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 $."

~~~
Touche
Bridge = $;

$ = Application;

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

------
slmnm
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](https://news.ycombinator.com/submitted?id=bpierre)

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

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

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

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

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

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

