Now that some people have had substantial experience with JXA, I’d like to ask what their current thoughts are on JXA vs. AS. Other than perhaps a few places where AS does things more easily (or correctly, or whatever), and given that El Capitan makes it possible to debug JXA in Safari, is there any reason to use AS anymore rather than JXA? All those years of struggle, mystery, and frustration – and occasional elation — all in the past? (And yes, this is directly relevant to KM because some of us frequently use KM as a wrapper around scripts that do the real work.)
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).
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:
- 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
- Script Debugger
- 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
- But not much help for JXA, for Mac automation
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
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.
I am currently learning vim and wanted to use it for all my future development, would you say vim is a good place to write jxa or I should really use something else to make my life easier. I could not find any plugins for vim that have jxa support.
Vim is a terrific editor although not the most Mac-friendly one out there.
The only editor I know for certain has JXA support is Atom.
I know what you mean, about wanting to use one editor for all your development work. That was my thought about BBEdit. My suggestion? Forget about that. That’s the decision I came to (on the Mac), and I’m glad I did.
You can’t always get a hammer to work like a mallet. You can’t always get a single screwdriver to fit all heads. Use what works, for each situation. Atom is free. No reason not to add that to your toolbox.
I’m currently working in Xcode in Swift. I also have Script Debugger open, and BBEdit (although I finally made a macro that does what I was using BBEdit for, in this situation).
So, just go with what works. My $.02-worth.
Ooh, just stumbled across this Atom package while looking for something else:
My feeling is that the best instrument is always that in which one has recently invested most time.
I don’t think there’s any particular reason why people who already like writing AppleScript, and who can already do what they need with it, should feel any pressure at all to migrate.
On the other hand, I also don’t think that AppleScript would really be at all a good choice for anyone just beginning to develop a capacity to script.
Suddenly, a new world has opened to me. Yahoo!
Yeah, I’d like that also. I’ve received some help, but I have plenty of times where I can’t get the Safari debugger to react to a “debugging” statement in my script, no matter what I do.
I actually started reading that once. I’ll have to go back to it.
Sure – I’ll aim to gather a few notes on using the Safari Debugger with the Automation context at some point in the week.
Rob, that’s an excellent point, which really highlights the advantages of JXA over AppleScript.
The one nagging thing about JXA is the complaints one encounters from time to time about issues/failures/shortcomings of JXA. So of this, I know, just sour grapes by the individuals who did not get the JXA they wanted.
I was wondering if you would share with us, any specific, actual issues you have encountered with JXA, and any workarounds? I suspect the list is quite small.
The only limitation of the Automation library that I have encountered is that while while batch-reading a property across a collection works (.getProperty)
Collection -> .propertyName -> List of values - one for each collection member
Examples might be:
- Instead of being able to set every row in an OmniOutliner outline to something like .collapsed, with a single property assignment, you have to iterate across the collection, setting the property for each parent row.
(And probably someone needs to write an good book, if books still sell )