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.)
Great question!
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).
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:
- AppleScript
- 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
.
- JXA
- Better programming language for programmers (again, IMO).
- The "English-like" language of AppleScript just gets in the way for some (a lot?) of programmers
- JXA is based on core JavaScript, and thus has a much better, more extensive, library of native functions than AppleScript
- Of course, 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
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.
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.
2 Likes
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.
Hey Nikita,
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.
JavaScript syntax coloring will probably get you by in Vim, and I’m fairly sure you can write functions to run your code without any problems.
-Chris
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.
1 Like
Ooh, just stumbled across this Atom package while looking for something else:
1 Like
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.
Learning a bit of JavaScript is always a good investment of time – it’s going to be with us for a while, it’s used in a wider range of contexts than applescript, it has features which make scripting a bit faster (map, reduce, filter, sort, regexes, encode unencode, Math, the excellent Safari debugger etc etc), and its run-time speed is also very highly optimised.
The you’ll be happy to know I had a major breakthrough today. All of a sudden, I just “got it”, about JavaScript, I realized that there were indeed JS paradigms that closely match ones from C# (although the lac of type safety makes them different, which has some significant advantages in scripting).
Suddenly, a new world has opened to me. Yahoo!
2 Likes
Would you consider a brief elaboration/tutorial on using the Safari debugger? I haven't really been able to find much on this — maybe I just need some references to available information. I've done lots of work with web inspectors and JavaScript debuggers, mostly Firebug in Firefox, but some in Safari and Chrome. (And, come to think of it, in OmniWeb when it was still an excellent modern browser with an interesting take on things — vertical tabs, for one.) I've even done a little node.js programming. But I can't seem to get started running JXA with the Safari debugger or figuring out what to do once I'm inside it. It even looks completely different than slightly out of date documentation shows.)
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.
Definitely read JavaScript: The Good Parts. It is not a tutorial, it is an exposé of some deep underlying power of JavaScript that 8 years after the book's publication is still probably relatively unknown.
JavaScript, despite it's apparent crudeness and wide use by people relatively uneducated in software development, has a powerful underlying object model based on delegation. I'd have to think about exactly what I mean, but it supports all sorts of modern-language mechanisms that are not always supported by other languages.
It will be interesting to see the extent to which JavaScript's object model is utilized in the JXA world.
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.
1 Like
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.
Thanks.
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
… in the first two releases of the JavaScript for Automation the corresponding .setProperty has only been applicable to one collection member at a time.
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.
- Similarly, on an OmniGraffle canvas, rather than setting all lines to red with a single property setting, you either still need (in the current JXA) to do it iteratively, line by line, or use a function like evalOSA, to do the batch setting with an AppleScript line from inside JavaScript.
Generally JSC (JavaScript Core) itself is a very mature and highly optimised language, which has benefited from many more iterations of competitive improvement than AppleScript, but the Automation library is very new, and has been through far fewer iterations than AS. As long as people are using JavaScript for Automation, each iteration will enrich and develop it. The only thing I am looking for at the moment is the batch setProperty over collections.
(And probably someone needs to write an good book, if books still sell 
)
(There’s also really just one disgruntled voice which aimed to set a certain tone for while – that of someone who had (a) written another automation interface for JavaScript, based on Apple’s older and now largely deprecated Carbon interface, and who really felt that ideally his project, or at least his advice, should have been adopted by Apple, and who had ( b) written an AppleScript book.
An understandable reaction of disappointment, but it seemed somehow to mutate into a curiously foul-mouthed and over-insistent attempt to dissuade others from using Apple’s JavaScript for Automation at all, which has left a marginally less than fragrant trail in StackOverflow. A difficulty with this campaign was that the writer felt impelled to dive in first on any technical question and encourage an impression that the whole thing was broken and that a solution was unlikely to exist and that the language ideally shouldn’t be used. The actual technical solution might be quietly offered by others some time later, but by then the propaganda effect had been achieved. All’s fair in love and war, I guess, but I think it would have been a bit more helpful to the public had this voice been slightly more punctilious in declaring an interest (disappointed authorship of rival interface, authorship of book which risked loss of readership, heavy personal investment in AppleScript etc).
But fortunately, the sheer usefulness of JavaScript for Automation speaks for itself.
2 Likes