Recently the Node.js Foundation announced that Mozilla is joining forces with IBM, Intel, Microsoft, and NodeSource on the Node.js API. So what’s Mozilla doing with Node? Actually, a few things…
You may already know about SpiderNode, a Node.js implementation on SpiderMonkey, which Ehsan Akhgari announced in April. Ehsan, Trevor Saunders, Brendan Dahl, and other contributors have since made a bunch of progress on it, and it now builds successfully on Mac and Linux and runs some Node.js programs.
Brendan additionally did the heavy lifting to build SpiderNode as a static library, link it with Positron, and integrate it with Positron’s main process, improving that framework’s support for running Electron apps. He’s now looking at opportunities to expose SpiderNode to WebExtensions and to chrome code in Firefox.
Meanwhile, I’ve been analyzing the Node.js API being developed by the API Working Group, and I’ve also been considering opportunities to productize SpiderNode for Node developers who want to use emerging JavaScript features in SpiderMonkey, such as WebAssembly and Shared Memory.
If you’re a WebExtension developer or Firefox engineer, would you use Node APIs if they were available to you? If you’re a Node programmer, would you use a Node implementation running on SpiderMonkey? And if so, would you require Node.js Addons (i.e. native modules) to do so?
I’m working on a ECMAScript 7-friendly version of a Membrane right now ( https://github.com/ajvincent/es7-membrane/ ), testing it primarily with Node.js and secondarily in the Mozilla Firefox or Google Chrome browsers. So sure, I’d love to add testing via SpiderNode.
Ah, interesting! Does Proxy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy help with your implementation?
You’d better believe it! DevMo’s documentation, particularly on Proxy and Reflect, is my primary source of information. #2 is the ES7 spec, and #3 is IRC or e-mail.
I couldn’t do this without DevMo.
Erm, actually I was wondering if the Proxy feature itself is helpful! I did a bit more reading about Membranes, in particular Tom Van Cutsem’s article http://soft.vub.ac.be/%7Etvcutsem/invokedynamic/js-membranes, which your repo references, and now I realize that Proxies are necessary (if insufficient) for them!
Myk, I’ve seen your question before. What I didn’t see was a rationale – why should a WebExtensions developer use Node? What kind of APIs would be available? Obviously not I/O APIs because these are off limits for WebExtensions. If you take Node and remove all the “dangerous” APIs, what will still be there and what’s going to be the benefit compared to compiling the same Node modules via browserify or webpack?
That’s a great question, for which I don’t yet have a good answer.
Right now, we’re in the process of figuring out what WebExtensions developers would use Node for, if it was available to them. And we’re also discussing the proposal with WebExtensions principals (product managers and engineers), to figure out which Node APIs they’d be willing to provide to WebExtensions.
If the answer to that second question is that no “dangerous” APIs will be available, then that obviously makes Node much less useful. Might it still be useful enough to provide a separate Node process that can run un-browserified/webpacked Node code? Or is Node only useful enough if you can use its system APIs?