You have probably been around this issue a number of times, but it’s noticeable that cross-platform and other issues are now displacing the centre of macOS scripting gravity somewhat towards JS (OmniGraffle, OmniOutliner, soon OmniFocus, TaskPaper of long date, and now QuarkXPress 2018, which feels like a bit of a watershed).
Some real unfinished areas in the JXA Automation API, combined with a heroically single-minded campaign of sulphur, brimstone, and worse, from Hamish, have protected the AS ecosystem a bit from that particular JS incursion, but I wonder what your current thoughts are about the future (given this newer pattern of app-embedded JS interpreters) and about the possibility of supporting JS-based app automation debugging in any way ?
Safari debugging did work well for JXA for a while, but since some breaking change quite a while back (two OS versions, I think) (much radared, little attended to) probing the Automation interface of apps through the Safari debugger is now rewarded by nothing more than an instant crash.
Perhaps some scope for SDJS there ? Or perhaps the costs/benefits/feasability of that still look unconvincing ?
(Quark seems to be using V8, others JSC (JSContext) – which already looks like a technical challenge – and perhaps these embedded JS interpreters [Omni, TaskPaper, Quark] while fast, and without the JXA defects, are also rather out of reach for 3rd party tools ?)
The short answer is no, we are not going to develop a version of Script Debugger for JavaScript.
I last dealt with this issue publicly back in December 2014. I can’t believe it’s been so long since Apple introduced JavaScript for Automation (JXA).
While there has been a lot of recent activity with JavaScript automation, both on macOS and on iOS, little of it has anything to do with Apple’s JavaScript for Automation. For instance, the Omni Group has done a fantastic job of integrating a JavaScript runtime environment directly into all of their products on the Mac and iOS. Unfortunately, the Omni Group is not utilizing Apple’s JavaScript for Automation. Other developers are doing similar things, resulting in a vast array of JavaScript implementations based on different technologies.
After the initial release of JavaScript for Automation, Apple has not progressed the technology in any meaningful way. There have been few improvements, no new documentation efforts and no promotion of the technology. Try searching for JavaScript for Automation or JXA on Apple.com and see what you find.
Apple’s Swift programming language was introduced at the same time as JavaScript for Automation and the difference in how Apple has promoted the two technologies is dramatic.
This leaves me believing that there is no viable business for a JavaScript for Automation product. It may seem like something that can be easily added to the existing Script Debugger product, but that is not the case. Script Debugger would need an entirely new debugging infrastructure, all of the code-building tools would have to be redone to support JavaScript, and I could go on and on.
My experience with Script Debugger has taught me how incredibly difficult it is to build a viable business around automation tools. I don’t see a profitable opportunity with JavaScript for Automation. I know this news is disappointing for those looking for better JavaScript for Automation tools - I’m sorry I cannot help.
P.S. In the time since JavaScript for Automation was released, nobody else that I’m aware of has introduced a tool for it. If the opportunity was there, surely someone else would have seized on it.
Sound reasoning. I doubt JXA will ever amount to anything much.
I am concerned about a possible future of unified cross-platform UI frameworks, and wonder if we will end up with more generic apps not necessarily well-suited for macOS or iOS.
If had unlimited funds, and some influence over Apple macOS planning, I know what scripting product I would like to see. But that is now long in the past…
( not really an option anyway for iOS, and of course an embedded JSContext performs much faster than any kind of Apple Event interface – particularly noticeable with OmniGraffle, in which speed can make a difference, with more complex diagrams )
