Apple’s Biggest Announcement Yet Isn’t About Phones Or Watches

Untitled-1

In case you happen to have missed it, an Apple announcement has claimed the number one spot on Hacker News this morning. As tired as we all are of Apple and the endless speculating and PR barrage, this one is different from most all of the others.

It’s different because it’s not really an announcement at all. It’s just the documentation for an API that allows developers to use JavaScript for OS X Automation, and it has serious implications for developers everywhere.

542027463_8ede265d3f_o

What Is Task Automation?

For those that aren’t familiar, the OS X operating system has long supported the ability to script and automate tasks using something called AppleScript. Why would you want to do this? Because it allows the user to automate repetitive tasks that otherwise require user interaction.

As a simple example, assume that you frequently email files to the same group of people. You may click to compose a new email, click the “attach” icon, browse for the document, select it and then click send. You could write an AppleScript to automate that task so all you have to do is right-click on the file you want to send, and select “send to group”. Virtually any interaction you can have with OS X can be automated, which means you can get really advanced. One user has a script which reads his calendar for hours he’s billed, creates an invoice in Excel and sends that invoice to the client.

Historically, these tasks were composed with AppleScript (or Automator), which is a proprietary scripting language from Apple that aimed to simplify the scripting process through the use of natural language.

For instance, if you wanted to show a simple “Hello World” dialog, you could write the following AppleScript


tell application "Finder"

    display dialog "Hello World"

end tell

With OS X Yosemite, Apple is allowing developers to do the same thing using JavaScript.

So What?

On the surface, this seems like a small and insignificant addition. Who cares about task automation? One commenter noted that being able to do the same things with JavaScript that you can do with AppleScript is a “matter of semantics”. You can see that Hacker News thread devolve into a discussion around whether or not JavaScript is better than AppleScript. The downsides of natural language interfaces not withstanding, we’re all missing a much bigger and more important point here.

JavaScript has begun to make its way onto more and more devices as part of the core operating system. Node brings JavaScript right to the server, and huge companies like Walmart are building their entire infrastructure on it. Microsoft offers it as a first class citizen for writing native Windows 8 apps. Google Chrome offers Chrome Packaged Apps, which allows access to a limited set of native APIs from JavaScript and PhoneGap pioneered the idea of proxying JavaScript commands to exposed native APIs.

The fact that Apple added support for JavaScript to OS X Yosemite Task Automation is so significant because it means that JavaScript is now a first-class citizen.

JavaScript As A First-Class Citizen

Not only does Apple provide an API for interacting with the operating system and install apps, but they also provide an Objective-C bridge to work directly with native libraries such as Cocoa. This is HUGE.  Just look at what Apple themselves have to say about it…

JavaScript for Automation has a built-in Objective-C bridge that offers powerful utility such as accessing the file system and building Cocoa applications.

 

 

They just said you could build Cocoa applications with JavaScript. That just happened.

 

What’s even more incredible, is that this is NOT the first time Apple has given JavaScript a promotion in its ecosystem. With iOS 7, they somewhat quietly announced the JavaScript Bridge. This bridge allows developers to call Objective-C methods from JavaScript. While Apple positions this as a way for developers to call plug-ins from a webview, it’s far more than that.

Items like the JavaScript Bridge are what enabled projects like NativeScript. NativeScript is a new framework from Telerik which allows developers to write native applications in JavaScript. Not to be confused with writing a WebView which runs in a native shell, NativeScript allows JavaScript to compose the UI and execute Objective-C at the lowest possible level. Don’t confuse this with cross-compiling. This is JavaScript running directly on the rails.

nativescript_head_banner_2

That’s why the fact that Apple is now offering JavaScript for task automation is so compelling. It’s not that developers have been dying to write more task automations, it’s that we have all long been searching for a universal language for building applications. The fragmentation in mobile has agitated this to nearly a tipping point. Nobody wants to install different IDEs, learn different SDKs, and maintain separate code bases. It’s simply not sustainable. Cross-compilation is appealing for this reason, but results in enormously bloated apps and a level of complexity between the developer and the operating system that they cannot control. If there is one thing developers hate, it’s a black box.

What’s strange is Apple doesn’t necessarily need to attract a new kind of developer. It’s arguable that it already has platform dominance and developer mindshare when it comes to the mobile space. Adding JavaScript access to native methods would have been akin to Microsoft doing the same thing with .NET when it so dominated the enterprise. What’s in it for Apple?

In any event, as a JavaScript developer I am very excited this morning. I have zero plans to go automate anything on my Mac now, or in the near future. In fact, I have never used task automation. What really amps me up is the fact that Apple has begun to sneak JavaScript in as a first-class citizen, and that opens all kinds of doors for developers everywhere.

We’ve just moved one step closer to that elusive unicorn – write once, run anywhere.

Update

Several folks have written and provided more information about HOW this actually works and how you can do it yourself…

Automator image by Miguel C from Flickr CC

Comments

  • Maximilian Stroh

    Thanks for the post, I didn’t notice this important “detail” right away 🙂

    • burkeholland

      Yeah – it’s kind of hidden behind a tool (automator) that nobody uses. They always seem to do these things quietly when nobody is looking.

  • Shawn Cahill

    I am glad they are allowing a more mainstream language. Lost in a lot of discussion of OS automation though is that Microsoft launched WinJS3 which DOES allow OS application development to be done completely in HTML and JavaScript in addition to XAML and C#. Not only that, but because it is open source, they have allowed it be used for creating UI interfaces for web! That is very impressive!

    A lot of press for Apple these days and how wonderful they are but they don’t allow that level of OS integration with open source for their desktop language. Perhaps this is a harbinger that they will. I doubt it though since they love to control their sphere of influence.

    • burkeholland

      Microsoft gets no love from JS developers and they are the ONLY ones who have given JavaScript a real seat at the table. That’s not lost on me.

  • Luke Puplett

    It’s also been an active scripting language on Windows since 1998 under the name JScript (http://en.wikipedia.org/wiki/JScript)

    • burkeholland

      Could you build native windows app with that? Like PInvoke and all that business?

      • Not unless someone built a NativeScript type library for bridging Active Scripting, COM and Win32 GDI.

        You see, Apple’s work doesn’t immediately open all of the Mac OS libraries to JS, but it provides a way to expose Obj-C methods and properties to JS. So you have to do some extra work first.

        “The WebScripting informal protocol, defined in WebScriptObject.h, defines methods that you can implement in your Objective-C classes to expose their interfaces to a scripting environment such as JavaScript.”

        I might be wrong. As far as I can tell, with NativeScript, Telerik have built the much needed wrapper around the native APIs.

        On Windows, someone could build a library of WPF abstractions in .NET and expose them via COM to Active Scripting. There’s no call for that though. JS is gaining popularity, so MS provide WinJS for writing ‘modern’ touch apps.

        • burkeholland

          Yes – that’s exactly what NativeScript does. It also has abstractions for UI since you don’t want to compose that stuff via JavaScript. NativeScript was a hard nut to crack even with the direct bridge support.

          It’s interesting to know that “techincally speaking”, we could have been writing native apps for Windows in JavaScript for a long time. 🙂

          • We used [cw]script (Windows Scripting Host) for this purpose. It didn’t have nearly the pretty face as Automator, but it was better than batch files.

  • CMichaelGraham

    JavaScript rules. ECMA Script 6 will be a real turning point. Couple that with Angular 2? Now we’re talking. Keep up the amazing work, Telerik !! 🙂

  • Steven Leggett

    The larger the usage, the greater the driving force to improve the language.

  • Pingback: Issue #18 – Sept 19, 2014 | Tales from the Front End()

  • Mark Nadig

    A friend reminded me of http://blog.codinghorror.com/the-principle-of-least-power/
    javascript all the things

    • burkeholland

      That’s a great one. He also has Atwood’s Law about “Anything that can be written in JavaScript will eventually be written in JavaScript”.

      • peter

        Anything that can’t be written in JavaScript eventually will.

        • konstantin

          It is actually not a typo 🙂 the statement is anything that CAN … not cant. That was the actual statement by Jeff Atwood

          • peter

            My version is a corrolary to Atwood’s law. 🙂

  • Pingback: Four short links: 22 September 2014 - O'Reilly Radar()

  • Pingback: JavaScript for OS X Automation by Example -Telerik Developer Network()