Comparing JavaScript for Automation (JXA) and AppleScript

JavaScript for Automation (JXA) vs AppleScript

Original Edition 2020-09-16 18:50 GMT-5
(This is a wiki article, and I will update as new information becomes available.)

Let me start by saying that this can be a very emotional, hot topic for some people.
So I want to make it clear that everything I'm posting here is IMO (in my opinion), but based on the actual facts as best I know them.

I'll also say that my journey with and learning of both AppleScript and JavaScript for Automation (JXA) is still much in progress, particularly JXA.

Having said that, in theory, according to Apple, we should be able to address Mac automation objects/apps equally in both AppleScript and JXA. So the decision should come down to which language do you like best? Which syntax do you like best?

But that's just theory. In practice, there seem to be a few, and I think very few, automation areas where JXA doesn't seem to work correctly. IMO, these are edge cases, that most of us are unlikely to run into. In fact, I can't even name the areas.

For me, this is NBD (No Bid Deal), because if I happen run across one of these JXA problem areas, I'll just code that function using AppleScript, and then call it from JXA, using an AppleScript Library. It is interesting, and notable, that you can use an AppleScript Script Library from JXA, but not vice-versa.

One could probably draw up a list of pros/cons, but I'll just list the big advantages of each language:


  • Easier to Get Help
    • By comparison with JXA, there is a huge amount of scripts, script libraries, example scripts, and people knowledgeable about AppleScript.
    • So that means getting help is usually much easier with Mac automation
  • Developing and Debugging with Script Debugger 7+
    • The best available development tool for either AppleScript or JXA, but it only supports AppleScript
    • Provides a complete IDE, with excellent debugging, scripting dictionary support, and exploring of app object models
    • AFAIK, there is really nothing equivalent to it for JXA -- the Safari Debugger is the best JXA tool available today


  • Better programming language for programmers (again, IMO).
    • The "English-like" language of AppleScript just gets in the way for some (a lot?) of programmers
  • Extensive Native and Third Party Libraries
    • JXA is based on core JavaScript, and thus has a much better, more extensive, library of native functions than AppleScript
    • Because JavaScript has been used in web pages for decades, there is a multitude of script libraries, example scripts, and knowledgeable people for JavaScript
    • But this is all (or mostly) for using JavaScript in a Browser, NOT for using it for Mac automation
    • So, lots of help available for core JavaScript
    • But not much help for JXA, for Mac automation
  • Learning JXA
    * If you don’t know either AppleScript or JavaScript, then, IMO, JavaScript and JXA is easier to learn.
    * Of course, if you already know JavaScript, but not JXA, then learning how to use JXA to access app objects is all that you need to add to your skill set.

Support for Each Language

As I read back over what I just wrote, I realize that it might confusing concerning the support available for each language. The main issue here is with support for Mac automation.

  • AppleScript has the best support for Mac automation
  • JavaScript as the best support for core functions, and of course for Browser automation.

My Personal Experience and Views

For me, I'm in process of transitioning from AppleScript to JXA. Part of that is relearning much of the core JavaScript I knew years ago, but have forgot due to lack of use. My main motivation for moving to JXA is the language -- I love JavaScript, but I can barely tolerate AppleScript.

It is hard to tell what Apple is going to do. But I see JXA as being the future of Mac automation. Except for Script Libraries (which are used by both AppleScript and JXA), it seems that Apple is not putting much effort into improving AppleScript: maintaining, fixing bugs, improving documentation, or extending AppleScript.

I know that JXA is a disappointment to a few of the long-time AppleScript developers. It is hard to pin down how much of this is "sour grapes" vs real issues. I'm sure JXA could have been better -- almost anything can be improved -- but it seems good enough to me. As I said above, if I run into something I can't code in JXA, then I'll revert to AppleScript, and call it from JXA.

Bottom line

Both are good tools. Pick the one that works best for you.

The great thing is that KM gives you easy access to run both AppleScript and JXA scripts (and other script languages). So, you can choose either, or both, whatever works best for you. And as of KM 8.0.3+, we have access to the KM Editor scripting model, which is available to both AppleScript and JXA.

See Also:

  1. JavaScript vs. AppleScript now? - June 2016 KM Forum
  2. JXA Resources -- Nov 2019 @JMichaelTX
  3. Comparing JXA with AppleScript -- June 2016 KM Wiki (written largely by @ComplexPoint)