New Objective-C Bridges

Ronald Oussoren is an absolute rock, quietly but reliably maintaining PyObjC (which dates all the way back to NeXT) even longer than I can remember—and I've been using Python since 2003. It's some years since I've had cause to use PyObjC, but it's the model by which all such bridges should be built: practical, usable, dependable, humble. It respects the target APIs and semantics; there's no excessive cleverness, obfuscation, obstruction or Drama screwing things up the moment you do anything non-trivial. It Just Works.

As to Gus's FMJS, if it's just a personal toy project to learn libffi and throw away then fair enough—always good exercise. But there's absolutely no point trying to create yet another JavaScript[Core]-to-Cocoa bridge for anyone else to use; Apple already have one in macOS; released in 10.10, it instantly sank without trace. Nobody Cares. With a mindnumbingly vast ecosystem and 10 million(!) users and counting, node.js and NPM† have already won this game. The ONLY realistic way forward now is to embrace Node. Either adopt it as-is (best solution from a technical standpoint) or else package Apple's JavaScriptCore as a 100% seamless drop-in replacement for the Google V8 interpreter that normally powers node (the political acceptable solution if you want Apple to accept it). Anything else is just wasting everyone's time.

--

† Needless to say, there's already an npm module for JS-Cocoa integration: nodobjc. (e.g. It's what I used to build nodeautomation.) If macOS fans want to make themselves useful, please go contribute to that. Improving unit tests, user documentation, and example scripts would be extremely helpful and much appreciated.

@has The main problem with Apple's JS to Cocoa bridge is that you can't instantiate any system classes. This means no CIImage, no NSFileManager, no NSURL, etc. Instead, you have to mark specific classes for exporting, and you can only do that if you're compiling your own source. FMJS overcomes that.

Gus: You're thinking of 10.9's JSCore's ObjC API, which allows application developers to make their apps JavaScriptable by exposing ObjC methods to JS as a quicker, easier alternative to implementing Apple events/OSA based automation. I meant 10.10's JavaScript for Automation, which has a standard JS-Cocoa bridge built in.

Like I say, creating stuff just for fun is cool. OTOH if you want to change the world then you have to understand you're competing against Node.js, which has a 10-year, 10-million user headstart over you. You're not going to beat that, no matter how technically good your technology is. JXA already tried and it failed, first and foremost because JXA was created in total isolation from the rest of the JavaScript world; hopelessly incompatible with both Node technologies (libraries, editors, documentation, etc) and culture (openness).

The only way to win is to make a "Node", only better: a native Apple citizen (replacing politically problematic V8 with JSCore) than works seamlessly with both existing Node and Apple technologies across macOS and iOS. That then gets you the entire Mac-based (million-plus) Node user base for free (at which point if Apple aren't all over you like a fly on shit then it's probably a good time to invest in a Chromebook instead).