8 ms·

You can use Javascript [0] or Objective-C (via ScriptingBridge) instead of Applescript. Any language that can bridge to Objective-C (like Swift, Python, or Ruby

by ihuman 5y ago

You can use Javascript [0] or Objective-C (via ScriptingBridge) instead of Applescript. Any language that can bridge to Objective-C (like Swift, Python, or Ruby) can also use ScriptingBridge. [0] https://developer.apple.com/library/archive/releasenotes/InterapplicationCommunication/RN-JavaScriptForAutomation/Articles/Introduction.html https://developer.apple.com/library/archive/releasenotes/Int...

russellbeattie 5y ago
First of all, support and documentation is virtually non-existent for any of those options. Have you tried to use JS alone to automate anything? Eventually you'll end up on the GitHub wiki like the rest of us, trying to convert 15 year old AppleScript examples into JS. It's a nightmare. This is related my point that AppleScript is an an anachronism. Apple must know that as well and don't want to spend any resources on the problem. So it's just sort of stuck.
- hhas02 5y ago
  You are correct about SB and JXA. Counterpoint: https://sourceforge.net/projects/appscript/files/ https://sourceforge.net/projects/appscript/files/ Type an AppleScript command into ASTranslate[1] and run it, and you get its instant translation to Python/Ruby appscript syntax. Appscript users adored ASTranslate: it answered 95% of their “How do I…” questions at a tap of a button. Appscript was great tech—a genuine AppleScript replacement—but it was ASTranslate that sold it. Back when I was enthusiastically supplying Sal Soghoian with 6 weeks of 100% free unpaid[2] JXA testing, feedback, and advice (up to and including writing a complete reference implementation of how a JavaScript OSA component should work for his team to learn/steal from), automatic AS-to-JS command translation I told him was THE Killer Feature Script Editor needed to make JXA a success. And yes, I provided Sal a free reference implementation of this feature—see the JABDemo app[3] in the JavaScriptOSA zip file. (Still works!) Incredibly quick and simple too: just add a toggle switch to Script Editor’s existing Apple event logging pane, to choose which language to format outgoing Apple events in: AS or JXA. A couple hours’ work to implement and test; would’ve done more than a year’s user community support[4] to make JXA both instantly usable and popular AF. Yep, I’d have done better advising a doorknob. #PEBKAC -- [1][3] You’ll need to do the right-click-to-open shuffle to get them to run, as these are ancient apps that I’ve not updated with modern codesigning and notarization. But they still run, and they still rock at what they do. [2] Again, an important lesson in business learned. Never do world-expert consultancy for less than three figures an hour. Because jerks like that appreciate it by exactly as much as they pay for it. Give to them it for free, they don’t give a shit. [4] Which they didn’t do either. And after Soghoian ghosted me, and made it clear that JXA was going to be garbage that they simply didn’t care about themselves, damned if I was going to do it for them either. Which is a shame, because after lead-authoring Apress’s monster Learn AppleScript 3rd edition, I could’ve knocked out “Learn JXA” in 6 months and sold JXA for them.
hhas02 5y ago
You can certainly write automation code using JXA or SB. Or you can just skip straight past the end where you `/dev/null` the lot in steaming frustration, and go back to using AppleScript because, as much as it stinks as a language, it’s the only nominally supported option that actually works. Calling JXA and SB abandoned unsupported incompetent trash is, frankly, an insult to all the abandoned unsupported incompetent trash out there (I’m looking at you RN, npm). The worst bit is, the Mac Automation team had absolutely zero excuse for botching SB and JXA. The first might be forgivable (because everyone screws up their first AppleEvent bridge—I certainly did), but to ruin two—and do so when this was already a solved problem. And Apple knew this was a solved problem, because they were also considering Python and Ruby appscript for inclusion in Mac OS X 10.5 at the same time as SB was being developed internally. Alas, Peter Principle, Dunning-Kruger, and Not Invented Here won out[1]; Scripting Bridge shipped, sucked donkey gonads, and immediately sank without trace. Then a few years later JXA did it all over again.[2] There is a reason why Apple finally fired the Mac Automation Product Manager and disbanded the whole damn team. The tragedy is, while AppleScript itself is a wonderful, awful failure in end-user language design, the underlying AppleEvent IPC infrastructure and the Apple Event Object Model that apps build atop it comes very close to true greatness: a high-level, highly consistent, query-driven UI/UX that for a time was damn near ubiquitous across every major productivity and recreational application. That query-powered UI ought to be at the heart of Apple Siri today, as Siri’s entrypoint into 1000s of professional and consumer apps, not mouldering in a corner because not a single person left inside Apple even realizes what a treasure chest they sit on, even now. So it goes. -- [1] a.k.a. Sal Fecking Soghoian. Though really this was my 100% fault: because I was a dumbass who thought “Mission Complete” when Apple approached me about appscript, not realizing that was only the foot in the door. What I immediately should’ve done was find out what dev was sponsoring it and asked what they needed in order to sell it internally to all the decision makers that count. Lesson belatedly learned. Pro-tip to y’all: When an org like Apple comes knocking on your door, saying “We’re interested in your work…”, the correct answer is “YES! What do you need from me to help make this work?”, not “Oh neat. Wait a minute while I go tidy stuff up…” Because you will not get a second chance. [2] Again, Sal Soghoian; a man incapable of learning from his own errors, never mind everyone else’s. If only Apple had hired Cal Simone, who actually knew what he was doing and how to sell it.

by ihuman 5y ago

russellbeattie 5y ago

First of all, support and documentation is virtually non-existent for any of those options. Have you tried to use JS alone to automate anything? Eventually you'll end up on the GitHub wiki like the rest of us, trying to convert 15 year old AppleScript examples into JS. It's a nightmare. This is related my point that AppleScript is an an anachronism. Apple must know that as well and don't want to spend any resources on the problem. So it's just sort of stuck.

hhas02 5y ago
You are correct about SB and JXA. Counterpoint: https://sourceforge.net/projects/appscript/files/ https://sourceforge.net/projects/appscript/files/ Type an AppleScript command into ASTranslate[1] and run it, and you get its instant translation to Python/Ruby appscript syntax. Appscript users adored ASTranslate: it answered 95% of their “How do I…” questions at a tap of a button. Appscript was great tech—a genuine AppleScript replacement—but it was ASTranslate that sold it. Back when I was enthusiastically supplying Sal Soghoian with 6 weeks of 100% free unpaid[2] JXA testing, feedback, and advice (up to and including writing a complete reference implementation of how a JavaScript OSA component should work for his team to learn/steal from), automatic AS-to-JS command translation I told him was THE Killer Feature Script Editor needed to make JXA a success. And yes, I provided Sal a free reference implementation of this feature—see the JABDemo app[3] in the JavaScriptOSA zip file. (Still works!) Incredibly quick and simple too: just add a toggle switch to Script Editor’s existing Apple event logging pane, to choose which language to format outgoing Apple events in: AS or JXA. A couple hours’ work to implement and test; would’ve done more than a year’s user community support[4] to make JXA both instantly usable and popular AF. Yep, I’d have done better advising a doorknob. #PEBKAC -- [1][3] You’ll need to do the right-click-to-open shuffle to get them to run, as these are ancient apps that I’ve not updated with modern codesigning and notarization. But they still run, and they still rock at what they do. [2] Again, an important lesson in business learned. Never do world-expert consultancy for less than three figures an hour. Because jerks like that appreciate it by exactly as much as they pay for it. Give to them it for free, they don’t give a shit. [4] Which they didn’t do either. And after Soghoian ghosted me, and made it clear that JXA was going to be garbage that they simply didn’t care about themselves, damned if I was going to do it for them either. Which is a shame, because after lead-authoring Apress’s monster Learn AppleScript 3rd edition, I could’ve knocked out “Learn JXA” in 6 months and sold JXA for them.

hhas02 5y ago

You can certainly write automation code using JXA or SB. Or you can just skip straight past the end where you `/dev/null` the lot in steaming frustration, and go back to using AppleScript because, as much as it stinks as a language, it’s the only nominally supported option that actually works. Calling JXA and SB abandoned unsupported incompetent trash is, frankly, an insult to all the abandoned unsupported incompetent trash out there (I’m looking at you RN, npm). The worst bit is, the Mac Automation team had absolutely zero excuse for botching SB and JXA. The first might be forgivable (because everyone screws up their first AppleEvent bridge—I certainly did), but to ruin two—and do so when this was already a solved problem. And Apple knew this was a solved problem, because they were also considering Python and Ruby appscript for inclusion in Mac OS X 10.5 at the same time as SB was being developed internally. Alas, Peter Principle, Dunning-Kruger, and Not Invented Here won out[1]; Scripting Bridge shipped, sucked donkey gonads, and immediately sank without trace. Then a few years later JXA did it all over again.[2] There is a reason why Apple finally fired the Mac Automation Product Manager and disbanded the whole damn team. The tragedy is, while AppleScript itself is a wonderful, awful failure in end-user language design, the underlying AppleEvent IPC infrastructure and the Apple Event Object Model that apps build atop it comes very close to true greatness: a high-level, highly consistent, query-driven UI/UX that for a time was damn near ubiquitous across every major productivity and recreational application. That query-powered UI ought to be at the heart of Apple Siri today, as Siri’s entrypoint into 1000s of professional and consumer apps, not mouldering in a corner because not a single person left inside Apple even realizes what a treasure chest they sit on, even now. So it goes. -- [1] a.k.a. Sal Fecking Soghoian. Though really this was my 100% fault: because I was a dumbass who thought “Mission Complete” when Apple approached me about appscript, not realizing that was only the foot in the door. What I immediately should’ve done was find out what dev was sponsoring it and asked what they needed in order to sell it internally to all the decision makers that count. Lesson belatedly learned. Pro-tip to y’all: When an org like Apple comes knocking on your door, saying “We’re interested in your work…”, the correct answer is “YES! What do you need from me to help make this work?”, not “Oh neat. Wait a minute while I go tidy stuff up…” Because you will not get a second chance. [2] Again, Sal Soghoian; a man incapable of learning from his own errors, never mind everyone else’s. If only Apple had hired Cal Simone, who actually knew what he was doing and how to sell it.