Not loving JXA
February 23, 2018 at 10:08 PM by Dr. Drang
A few days ago, Brett Terpstra presented us TaskPaper users with a couple of Keyboard Maestro macros, one for natural language dates (e.g., “tomorrow” or “next Monday” in @due or @start tags) and one for incrementing or decrementing numerical values in tags like @priority(n).
As it happens, I don’t use TaskPaper in as formal a way as Brett does—experience shows that the more structure I put in my task management system, the less I use it—so I suspect I’ll never take advantage of Brett’s work. But tucked away in a footnote is a comment that rang true for me:
I’m still clumsy with JavaScript for Automation. As annoying as I’ve found AppleScript over the years, I’m just not loving JSA much more.
This is a perfect distillation of my experience with both AppleScript and JavaScript for Automation.1
The main problem with AppleScript is the tremendous variation in quality from one application’s dictionary to another’s. There are so many idiosyncrasies, it’s hard to remember which gimmicks apply to which app. JXA doesn’t—and can’t—solve that problem because it rests on the same Apple Events foundation as AppleScript. Worse, it adds a new problem: very little outsourced documentation.
By “outsourced documentation” I mean the vast collection of websites in which AppleScript programmers have written about the little tricks they’ve discovered to get their scripts to do what they want. For me, programming in AppleScript consists largely of working out in my head the overall structure of the script and Googling to find the right magical incantations for each individual part. Then revising the structure when I find that certain parts can’t be done the way I thought they could.
(There are, I’m sure, AppleScripters who don’t need to Google for syntax. I can’t imagine Doug Adams, for example, needing to search for help with the iTunes dictionary. But I’ve never scripted any single application long enough to master it, and even if I had, mastery of one app doesn’t necessarily translate to another.)
JXA doesn’t have that quarter-century of folk wisdom. So programming in JXA is just like programming in AppleScript, but with the extra step of translating someone’s AppleScript trick into JavaScript—a very different language.
When JXA was released, I really thought it would be superior to AppleScript. I imagined myself rewriting my old AppleScripts in this new, more normal language. But it hasn’t turned out that way. Like Brett, I am still clumsy with JXA and doubt I’ll ever get coordinated.
-
And like Brett, I think JavaScript for Automation should be abbreviated JSA and usually write it that way. But Apple says it’s JXA (in documentation that still refers to macOS as OS X, but I’m not here to rant about how Apple’s enormous workforce can’t muster enough people to update the documentation for a line of products so small it could fit “on the table you’re sitting at”). ↩
