Is it a good idea to learn JXA in 2022?

Hi just wanted to ask the community if it’s still a good idea to learn JXA for automation in macos? Is Apple still developing updates to this technology? Or is it going to die out soon?

I know that it is still being supported by the latest macos(Ventura). But how likely would it still be present in future OS versions?

PS: I’m a web developer and I’m more comfortable writing JavaScript. AppleScript can be quite confusing sometimes.

Cheers

Heck, it wasn’t a good idea to learn JXA the day it was released in 2014! It was crippled and buggy then, with lousy documentation and no official or community support worth a damn.

JXA hasn’t changed since, partly because the Mac Automation team were lazy and disinterested, mostly because Apple finally realized this for itself and disbanded their department in 2016, reassigning its developers to other teams and sacking the manager responsible.

The entire Apple event/Open Scripting Architecture/AppleScript stack has been mouldering in maintenance mode since (its only growing market nowadays is iin malware). A huge pity too because Apple event IPC, if a bit crusty, is legitimately awesome—vastly superior technology to anything Shortcuts or any other platforms offer. It’s just been murdered by Apple repeatedly shackling it to garbage and then leaving it to rot. (I actually fixed that problem 15 years ago, until the Mac Automation team wrecked it again. Still salty.)

FWIW, I doubt Apple will pull JXA before they pull AppleScript as well. They should have deprecated Automator, JXA, and other no-longer-wanteds in macOS 11 as part of their proactive slimming down of legacy scripting language support (Python, Ruby, etc) in their overall transition to Shortcuts, but they simply don’t care enough to be bothered. (Alas, the post-Jobs Apple cares little for quality/trash control.)

Meantime, Adobe’s made clear that the future of InDesign/Photoshop/Illustrator automation lies in its next-generation UXP JavaScript engine. That’s going to be massive so once the print industry realizes this and starts migrating from AppleScript to UXP, that’ll be the end of AppleScript’s last legitimate market and Apple is then free to pull its plug quietly without any upset. (3–5 years would be my estimate, depending on the speed of these behemoths.)

If you want something that works right and is still “officially supported”, stick to AppleScript. The language itself is terrible, but the application automation stuff works perfectly and, crucially, AS still has a small but experienced user community to help you out whenever you get stuck.

As you’re a web dev, you should already be using Node.js for all your general day-to-day scripting. Keep on doing that. Node has its own share of issues, but as a platform it’s unbeatable.

You can call into AppleScript from Node via the command-line osascript for simple tasks, passing arguments and results as plain strings (or JSON at a push). Slow but simplest. If you are brave and need deeper/faster integration, the AppleScript-ObjC bridge should be accessible via Node’s objc bridge, allowing you to pass complex values and call multiple AS handlers directly.

The other option, if you’re even braver still, is to go all in on Node and use nodeautomation which, unlike JXA, works about as well as AppleScript. Caveat emptor: no warranty or guarantee of fitness and I do not provide [free unpaid] support, but as long as I need nodeautomation for my own work I will continue to maintain it. Its documentation is not great (still better than JXA’s though) and the accompanying ASDictionary and ASTranslate tools answer most of the practical “How do I…” questions when translating application commands from AppleScript to the equivalent JS syntax.

Whichever way you go: The key to understanding Apple event IPC automation and using it effectively is realizing it is not OOP; it is RPC plus simple first-class relational queries! The IPC system’s design and much of its behavior derives from SQL and RDBMSes, only manipulating a tree-like data graph instead of rectangular tables. If you assume it is DOM and try to treat it like that (as JXA wrongly did) you will only confuse and frustrate yourself, and your code’s performance will likely suck.

There’s some explanation of this in the nodeautomation documentation (AppleScript’s docs totally ignore this and JXA’s are outright misleading). For a more general understanding of the “Why?”, Dr William Cook’s paper on AppleScript’s development is a proper good eyeopener.

HTH, sympathies, and good luck.

2 Likes

My pecking order of automation tools is something like: Shortcuts, shell scripts, AppleScript, and then everything else. I try to do everything in Shortcuts that can be done there because they’re cross-platform and the tool is improving every year. If that fails I call to AS from Shortcuts or a shell script depending on context.

From what I’ve heard, JXA is much harder to work with than AppleScript because it’s basically just a wrapper, not a first-class implementation. While AppleScript can be confusing, it’s the only thing that can do what it does and it’s a great extension to Shortcuts or other languages, and calling out to it using osascript is a good way to go.

1 Like

Wow thank you for the detailed reply. I didn’t know that automation languages in Apple where in this state.

Yeah I will probably be using Node for some of my automations rather than relying on JXA. I’m more comfortable with it as well. Also will try to check out your suggestions like calling AS in node and nodeautomation. I was looking into JXA mainly for ui navigations of apps without installing any thrid party tool.

PS: Your suggestion of looking at AppleScript in an SQL like mindset it definitely intriguing. Will keep that in mind next time I need to do something that requires me to write AppleScript.

Cheers man, Thanks!

Yep, I would probably do the same thing as you and prioritize doing stuff on Shortcuts. I just discovered not too long ago that I could actually run shell commands and scripts inside Shortcuts which opened up some possibilities for me. Currently I’m using it to run certain node js scripts that I wrote. Mainly for file/directory manipulations.

Thanks man!

1 Like

Dr Cook’s paper explains the original motivation for using coarse-grained high-level queries (a-la SQL) instead of fine-grained low-level message passing (c.f. DCOM, CORBA, etc). While Mac OS X eliminated the original System 7 performance bottleneck, even now as an inter-process communication strategy it makes a lot of sense, from a high-level UI/UX perspective as much as “API” design.

The #1 reason programmers almost universally despise AppleScript is because they see its OOP-like syntax and (wrongly) assume it’s OOP/DOM. When they subsequently see AS behaving in profoundly *non-*OO ways, they are confused and frustrated by this mismatch between what they expected and what they actually get. This is a huge same: when programmers actually “get” Apple event IPC, they (mostly) love it and can build truly amazing things with it. Alas, Apple’s early mismanagement of AppleScript pissed off its original designers into quitting, and with no-one left who fully understood the technology, there was nobody to document or explain it accurately to programmers in language they could understand. Thus these misconceptions abound.

(Ironically, non-programmers don’t have nearly so much trouble: coming to Applescript without any prior assumptions, they simply accept it for what it is.)

Once you understand how Apple event automation really works, and why it works they way it does, it actually makes good sense. It still has warts (the biggest of which is being buried under AppleScript’s horridly confusing syntactic sugar) but it is remarkably powerful, elegant, and accessible. I’ve built some of the most advanced graphics automation on the planet, and I did it all using Apple event IPC (Python3+appscript driving Adobe Illustrator), and it just blows away everything else on the planet in terms of ease and speed of development.

Ironically, with Siri voice control seeking to open up automation to ordinary end-users, having high-level query engines already built into hundreds of apps should be an absolute goldmine ready to exploit. Alas, with no-one left at Apple who understands or cares for the technology, the whole stack and its ecosystem have been abandoned to rot. Siri Shortcuts may offer only a fraction of the power while simultaneously tying its users into knots as soon as they attempt anything non-trivial, but it’s clear Apple sees that as the future now. Certainly they can’t do a worse job of getting developers behind it.

2 Likes

ALL high-level Apple event bridges are “wrappers”, including AppleScript’s. Powerful as it is, calling the Apple Event Manager’s low-level C API directly is not for faint of heart. It requires a good high-level wrapper to make it simple and easy to use.

What distinguishes the good AE bridges from bad is that good AE bridges preserve Apple events’ powerful RPC+query semantics and expose them as-is, whereas the bad insist on shoehorning AEs into crippled OOP semantics—and then, when stuff inevitably breaks, declare “too bad” and hang their unfortunate users out. That’s not the technology’s fault though; that’s just bad programming by arrogant/ignorant programmers thinking they know better (they don’t).

While some of my appscript bridges are long dead, the Python3 version still works, as do its SwiftAutomation [1] and nodeautomation descendants. These bridges are fully capable of replacing AppleScript entirely, in vastly more popular languages, even when automating notoriously gnarly and ancient “AppleScriptable” apps such as MS Office and Adobe CC suites. [2]

Quickest way to see this for yourself is to grab a copy of ASTranslate and run some AppleScript commands through it. It’s a very quick-n-dirty tool [3] and may contain bugs, but even the most sophisticated AppleScript commands and references should work equally well in these other bridges too. Much clearer and easier to understand too.


[1] AFAIK, although SA hasn’t been maintained in a while so I can’t vouch for it painlessly updating to the latest Swift+Xcode versions.

[2] UserLand’s Frontier (which predated AppleScript) also came close, but dropped out early to refocus on web software. Mac::Glue also made a decent effort, but was stymied by being shackled to Perl. All of the others, including Apple’s, utterly screwed the pooch by trying to be “clever” and OOP-like. Hard as it is to imagine something worse than AppleScript, they managed it!

[3] ASTranslates only translates application commands, by sniffing the outgoing Apple event IPC messages and reformatting them in Python/Swift/JS syntax. It won’t translate the rest of your AppleScript code though; you still have to do that by hand.

(I do have a much more advanced AppleScript-to-Node.js translator that does convert entire scripts, created for migrating InDesign/Photoshop/Illustrator scripts from AppleScript to UXP. It currently manages 90% automated conversion from AS to JS, although the last step from nodeautomation to UXP APIs is currently TODO as Adobe have not yet finished UXP themselves. I don’t provide that tool as a free download though.)

1 Like

I noticed that in this very informative discussion about automation options on macos there is no mention of Swift or Objective-C. Can these be used for similar things as AppleScript and Shortcuts? If so, how do they compare to the other options?

I think those are more general purpose programming languages for making apps and not really for quick automations as you would need xcode to build and compile your outputs. I could be wrong, if you know of any automation tools utilizing those languages without requiring the user to install xcode or some other compiling app please do share I would be quite interested in that.

Try a search for “Swift scripting” in your favourite web search tool.

1 Like