Musings on “JXA” vs “JavaScript for Automation”

Thanks, Rob.

Hey, can you do me a favor and make sure if your post contains JXA stuff, that you include the text “JXA” somewhere in it, so it comes up in a search? You don’t have to if you don’t want to, but I personally would appreciate it. :slight_smile: Thanks.

I’ll add it to that post, and try to remember it. ‘JXA’ is not, for some reason, how I spontaneously think about it – sounds likes a washing powder :slight_smile:

(Is searching for ‘JavaScript for Automation’ any good to you ? I guess I tend to think of it as JS with that Automation object, so JS for A comes sooner to mind)

LOL. Sure, I can search for “JavaScript for Automation”.

I guess in one more thing, I’m the opposite of you. “JXA” is short and sweet. “JavaScript for Automation” is a mouthful.

Now that I think about it, with your love of brevity in code, and my love of verboseness, we should have the opposite opinions! :slight_smile:

I might argue that on a forum like this, it’s helpful to use the same terms as Apple. To find a trace of anyone in Apple using the term JXA, I think you might have to track down one or two of the slide packs in the early developer briefings.

Not much sign of it in Apple’s offical release or public-facing documents :slight_smile:

1 Like

LOL, at StackOverflow they use both as tags for obviously the same thing …

I'm with @DanThomas on this.

  • Apple branded JavaScript for Automation as "JXA" when it was released, and have used it a number of times since.
  • Formal Apple docs probably don't use it because, well, they are "formal" documents. Just like Peter doesn't like to use "KM" in the wiki.
  • A google search turns up about the same hits for both, but "JavaScript for Automation" also pulls in other JavaScript, non-JXA stuff.
  • Most of the early third-party sites and blogs use "JXA", like the dtinth/JXA-Cookbook Wiki
  • In this forum, we have a tag for "jxa" and most often refer to it as "JXA".

When in doubt, use both. In fact, I have a text expansion just for ";jxa":
"JavaScript for Automation (JXA)"

No, it never figured in any of the the branding work for markets, and nothing in the first release notes (10.10) or the Scripting Guide for Automation)

(Even in the technical channels to developers, it barely figures outside a couple of early uses by engineers in pre-release WWDC presentations to developers.

https://developer.apple.com/search/?q=jxa

The one appearance in parentheses in the second release notes (10.11) owes more to the influence of the JXA Cookbook site than to any branding work by Apple).

I'm sure it's here to stay, and I have no problem with it – just not a name that I use myself.

I'm sure it is here to stay as well.

The key point is good communications, using terms that your readers will quickly recognize and understand, and, of course, can search for and find.

When you're talking to yourself, feel free to use whatever terms you like. :wink:

When you're talking to yourself, feel free to use whatever terms you like. :wink:

LOL.

Oh ... so you're ruling out "JXA" ?

Understood. I won't use it again.

1 Like

Since there seems to have been some question about whether or not Apple has officially used the "JXA" term, I thought I'd share this:

"JXA" is not a acronym that we invented here. It was established by Apple during the 2014 WWDC:

JavaScript for Automation - WWDC 2014 - Videos - Apple Developer

JavaScript for Automation

Automation in OS X has always been about power and choice. Scriptable applications, including Pages, Keynote, Numbers, and the Finder, can already be automated using a variety of languages, including AppleScript, Objective-C, Perl, Python, and Ruby. With OS X Yosemite, application scripting support has been added to another popular language, JavaScript. JavaScript for Automation (JXA) extends the standard JavaScript environment provided by the JavaScriptCore framework with support for querying and controlling all of the scriptable applications running in OS X. JXA scripts are supported at all layers of the system and can be invoked from the command-line, from the system-wide Script Menu, and can even be distributed as code-signed applications.

WWDC 2014 - Session 306 - macOS