Nice episode! I’m eager to see everyone’s examples!
Loved the epsisode. Are there any tutorials for apps like Data Jar or even ToolBox Pro? I want to take my knowledge to the next level but I find these apps difficult to master.
Without myself having been exposed to Scriptable, the ability to run JavaScript in a shortcut sounds cool, but what happens when the same Shortcut is run on MacOS? Could the same shortcut be run, but pass the JS around as a magic variable into either Scriptable or a run JavaScript action? That doesn’t appear to be possible. Maybe Get Device Details - Model as input into an If, which then runs the Scriptable action where Model is not Mac - but that results in “This action cannot be run because a required app is missing” on MacOS and the Run JavaScript for Mac Automation shows “This action can only run on Mac” when viewed on iOS. These are just the random things that go through my head when I listen to these types of episodes.
As a Software Engineer, this episode was a good listen, but I couldn’t help but feel @RosemaryOrchard and @simonbs were holding back a bit. Maybe on an even nerdier podcast, the conversation would get to the nitty gritty. Great to hear the types of challenges being faced by Devs are pretty universal!
I think @MacSparky’s comment about being a Problem Solver is universal to the Automators audience, whether they are a Software Engineer or not. I think Automators walks a pretty fine line between nerd and Dev - keep it up guys!
Maybe on an even nerdier podcast, the conversation would get to the nitty gritty.
Sad to admit but I studiously avoid podcast listening; I don’t mind skimming a written transcript but an hour-plus of my life is a big ask if I don’t know what I’m getting in return for that commitment. (Not to mention my auditory attention span is abysmal. I forget the start of your sentence before you reach the middle. Bear of very little brain, I am.)
TBH, if you’re automations are really That Good, you shouldn’t need to talk about them ’cos you’d have the whole world using them already.
OTOH, if someone does a podcast about all of the automation things that don’t work well, let me know. Those are much more fun, and far more educational too. Not least because just occasionally some smart, insightful, really ambitious person might listen and think “Oh hey, I could do better myself…”, and who knows then what greater work might emerge. That’s exciting. Disruption is good, be it of comfortably, complacently mediocre end-user products or of comfortably, complacently mediocre vendor assumptions that what we users have today is “Good Enough” for us[1].
Cos the thing is, any fule can whip up a shiny new Automation Platform that can do some of the things for some of the people for some of the time. Building a platform that can scale up—and down—to cover everyone’s needs… ah, that’s the real Holy Grail. Let’s have more talk about how to make that, and perhaps some mad fool out there will feel the urge to go and actually build it! 
…
Run JavaScript for Mac Automation
Yup, LOL, hard nope. That’s the execrable #FailWhale that dug AppleScript and the rest of Mac Automation in its grave, failing so hard and fast that in wake of its launch-day sinking Apple killed the entire Mac Automation department and fired the PM responsible[2]. Do Not Want.
I am legitimately surprised Simon hasn’t moved to fill that void (bomb crater?) in subsequent years, macOS could certainly stand a friendly JavaScript editor (plus command-line interpreter) that also happens to work across iOS as well.
I realize the JXA fiasco effectively destroyed JavaScript’s future within Apple (outside of Safari where it’s safely entrenched); even so, it may not be beyond redemption. The JavaScriptCore API is actually pretty nice to work with, and JavaScript itself is by far the most widespread and influential language on the planet in the last three decades, so a cautious, targeted redemption reaching the places that Node.js cannot reach (<cough>iOS</cough>) is not beyond the bounds of possibility. What JS really needs is a damn good sales pitch and a polished, ready-for-purchase product, targeted at the right person within Apple to buy it.[3]
BTW, an alternative to Simon’s work is John Lindquist’s ScriptKit, which is also a very nice, automator-oriented product (but not on iOS, boo!), and which also has the advantage of being stock Node.js underneath, which means you get npm support and the rest of the Node ecosystem goodness right out of the box. Alas, Node is V8 underneath, which means Apple can never adopt it directly (V8 being Google product).
Maybe if Simon and John were to tag-team… ISTR there are third-party libraries that give JSCore access to most npm modules too.[4] Opportunities lie where you invent ’em.
–
[1] It’s not. Apple Automation today blows. Far, far harder than it should. (Technically one small expression of a vastly larger fish-rots-from-the-head-down problem: Cook’s long decade of steady-hand leadership all but rendering the world’s greatest disruptor into an immaculately oiled cuckoo clock.
[2] Sadly not out of a cannon into the sun, but I take what grim satisfaction I can.
[3] This is actually not a preposterous idea: WorkflowHQ successfully cut a deal just a few years back, positioning their own product at the heart of Siri. And though Shortcuts theoretically offers a much wider reach than a “traditional” programming languages, it has yet to achieve even a fraction of audience share that JavaScript (10M+) already has in its pocket. Simple math says JavaScript Everywhere, including in cross-platform Shortcuts, is much too good an opportunity to waste. Apple haven’t done it because they are clueless, but that doesn’t mean community can’t.
[4] Being able to load npm modules opens JavaScript access to the wealth of Cocoa APIs and “AppleScriptable” apps too (npm really does have libraries for everything!)—a couple more underrated, undervalued, unerexploited Apple gold mines, waiting for some enterprising third-party dev to tie them all together in a deliciously enticing bow. Just saying (COIs aside).
Having dug around, I was thinking of jscshim.
I hadn’t heard of Bun before—it’s been several years since I last worked with JavaScriptCore and the Bun project looks like it started only last year. Could get interesting. Certainly a lot closer to what an “Official Apple JavaScript” could and should look and feel like. With Apple clearing out the old “P-langs” from the stock macOS install, I think a lot of sysadmins would swoon for a modern capable JavaScript shell being bundled as standard. And that’s just to start.
One immediate annoyance: bun doesn’t seem to offer an interactive shell, though it runs .js files okay. OTOH, its ability to run .ts files out of the box is very sweet (something I wish node had).
Also ridiculously easy to spin up an HTTP server using the example code on their home page (instant working demo: good)… once I realized I was expected to copy-paste this code into a http.js file in my home folder (their demo instructions never said to do this: bad).
Package manager is a bit rough, and I’m a little concerned about it stepping on my node installation’s toes since bun install likes to call the module directory node_modules too. (OTOH, if I let it use my established node_modules directory, it barfs errors.) If you can import and use the objc module in bun, I’d be interested to hear.
Obviously very much a work in progress. Still, a really good find. And yes, Simon could do far worse than tag-team with the Bun devs and together create the “Unofficial Official Apple JavaScript”—aka the JS platform we Apple users actually deserve—and then sell the hell out of it to Apple till it becomes just the “Official Apple JavaScript”.
[soapbox]
It constantly surprises and frustrates me how many geeks create all these terrific technologies but have no clue how to promote and sell them beyond their own immediate niche. It’s a definite geek weakness: failure to see outside of their own comfort zone. As a result, they fixate on “making the tech even better”—faster, more features, etc, etc, etc—in the hopes that this will somehow sell it to more users, instead of realizing their tech is [already more than] Good Enough; and it’s everything else—packaging and presentation, marketing and sales, building brand-awareness—which they need to work at improving.
(I’ve actually been on the threshold of Apple adopting my tech in macOS, and blowing that opportunity exactly because I didn’t understand this until many years later.)
A company like Apple isn’t looking for amazing technologies; it’s looking for adequate technology that’s packaged as an amazing product, with a large, growing, highly desireable market which is going to fall over itself en-masse for that product the day it’s unveiled at WWDC or whatever.
That’s why Apple bought WorkflowHQ. Shortcuts technology isn’t a patch on what the JS community has today. What sold Workflow is that its developers packaged and marketed their tech really well: a single, coherent, attractive-looking product targeting a highly desireable market with a polished user experience.
Whereas JS makers have a metric ton-load of great toys all scattered over the place at random, and no-one ever thinks to pull the best of them all together and tie the whole package up in a lovely bow and promote as The Must-Have Solution for the world’s ten million hungry ambitious JS users. Much as I dislike JS as a language, I cannot deny that is a helluva opportunity there for the taking. Yet it sits there, no-one within the JS world apparently interested in taking it.
Great Presentation and Positioning—a compelling product vision—is the real key to mass-market success, and sooner folks like Simon and the Bun devs get as good at that side as they are at the techie aspect, the sooner they can elevate their work from pleasing thousands (and playing distant second fiddle to the mighty Node.js), to delighting millions (and running laps around it)! Hey, I live in hope. 
[/soapbox]
Great episode! @simonbs, could you please provide a script from Ukrainian to check blackouts? As an Apple reseller here I could spread it wide. Thank you!