And JXA shipped half-baked and broken, and immediately abandoned to sink without trace. I didn’t get so much as a thanks-but-no-thanks 200+ work hours straight down the crapper. But the Mac Automation team still thought they knew better than a production-proven solution that had at its height a couple thousand extremely happy users, whereas their own previous attempt had only proven an embarrassing failure. Apple even considered including Python and Ruby appscript in Mac OS X Leopard, so it’s not like my code wasn’t already known about, read, or used by folks within Apple. While the Xcode project is far too old to build now and some of that code is a lashup of which I’m not proud, the prebuilt component may still work in Script Editor (though I’ve not tested it in years), as should the standalone “demo” app I bundled with it.īear in mind, my JavaScriptOSA implementation was based on my previous appscript work, which had alrady proven itself a genuine AppleScript replacement years earlier. And they had double the developers, all the AppleScript source and internal Apple documentation, and a year. Immediately after JXA was surprised-announced at WWDC14, I dropped everything else, reached out to Sal Soghoian (Mac Automation PM), and crash-coursed six weeks of testing and critiquing JXA, up to and including writing a nearly-complete “JavaScriptOSA” reference implementation for the JXA devs to learn from, or just outright steal.Įven rushed and unfinished, JavaScriptOSA showed what JXA should’ve been. Outside of myself, Dave Winer’s Userland, and the original AppleScript creators, no-one else on the planet has ever managed this.) (For those that don’t know, I am the world expert at building production-ready Apple event bridges, with half-a-dozen under my belt. Worst part is: it should never have come to this. JXA should’ve saved Mac Automation, but it killed it instead. There’s a reason Apple finally disbanded the Mac Automation team and fired the PM responsible. JXA is junk, same as Scripting Bridge before it and they never shit to fix SB even when they had years to do it. I mean, I wrote the thing and even to me years later it’s still like freaking voodoo! :) Tell app "finder" to count every folder of home whose name begins with "D"Īpp("TextEdit").documents.at(1).name.get()Īpp("Finder").(("D")).count() Tell app "textedit" to get name of document 1 It’s not codesigned so you’ll have to right-click the app to Open it, overriding the security warnings, but it still works even on 10.15 (caveat any bugs in the underlying JavaScript Apple event bridge, of which there were a few, plus the endless string of permission requests whenever you try to control another app). Just d/led the JavaScriptOSA zip from the appscript project page on SourceForge, and the bundled JABDemo.app still works. Needless to say, Sal Soghoian completely ignored my expert recommendation for this killer feature which could be implemented in a day, choosing instead to dump JXA and its few hapless users down the same black hole of nothingness as all his other product failures. While it only translates outgoing Apple events, not native AS code, 99% of the time JS users already know how to write general JS code, and it’s the application-specific references and commands they’re struggling to form.īack when appscript was still a thing I hacked together a quick-n-dirty AppleScript-command-to-Python/Ruby/ObjC translator app which appscript users absolutely adored, plus it greatly reduced the number of “How do I…” support questions because, more often than not, users already had a working example in AppleScript which they could just run through the translator to get the answer for themselves. Funny enough, back when the Mac Automation devs were still getting JXA ready to throw away, one of the things I told Sal Soghoian to do was to add automatic AS-to-JS syntax translation to Script Editor’s Log pane.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |