SpiderNode for Firefox chrome code

Myk Melez myk at mykzilla.org
Wed Dec 14 00:24:54 UTC 2016


Brendan Dahl and I have been investigating the possibility of 
integrating SpiderNode into Firefox for use by chrome code.

There are potential perf wins to using Node's File System (fs) module in 
place of the synchronous XPCOM nsIFile* APIs and their asynchronous (but 
single-threaded) OS.File equivalents. Brendan is currently investigating 
that use case to get a better sense of the potential.

There are also several general benefits to Node:

* It provides core APIs that are familiar to a much larger cohort of 
software engineers.

There are perhaps a thousand engineers in the world who are familiar 
with XPCOM/JSM APIs (and their module systems), whereas there are 
hundreds of thousands of Node developers. So it'd help us attract more 
contributors (both volunteers and new employees).

* It enables us to reuse modules from the Node ecosystem.

Node would make it straightforward to integrate third-party modules from 
NPM. We can port some of them today, but many depend on core Node 
modules (or their own native modules), which makes porting expensive and 
often unfeasible. Whereas Node would make it possible to vendor modules 
using NPM's standard dependency management tools.

Of course we'd still need to ensure that the modules (and their 
dependencies) are high-quality and have compatible licenses. Rust has 
the same problem with third-party crates. Still, that's a good problem 
to have, if it means we can sometimes borrow instead of build new 
functionality.

* It supports more modular development of Firefox components.

With Node, we could use GitHub and NPM to develop and distribute Firefox 
components as separate Node modules that we vendor into mozilla-central. 
Besides (arguably, I know) improving our own workflow, this exposes our 
code to a broader audience, which increases opportunities for reuse and 
contribution.

Of course we'd still have to weigh the trade-offs to doing this for any 
given Firefox component. And make good decisions about what to develop 
monolithically vs. modularly (and what to develop in C++/Rust vs. in 
JS). Node doesn't solve those problems, it just makes it easier to 
choose modular JS development when it makes sense to do so.

There are also at least two downsides:

* Footprint will grow. We haven't yet measured the extent of this, but I 
expect there to be a significant impact from both the core module 
library and libuv <https://github.com/libuv/libuv>, which Node entrains. 
We could reduce the impact of the module library by not packaging code 
we don't use, but we'd still take a hit.

* Node's callback-based model for asynchronous programming makes it 
possible to fall into Callback Hell, the one significant 
developer-ergonomics disadvantage of Node APIs relative to Promise-based 
Mozilla equivalents. There are of course modules to promisify Node, 
along with coding patterns to minimize callback complexity, so it's a 
manageable issue. But it's still an issue.

Overall, my sense is that the potential is significant enough to be 
worth investigating further, but only if there are either specific 
compelling use cases or significant developer interest in the general 
benefits.

If Node was available in Firefox, would you use it, and what would you 
use it for?

-myk




More information about the firefox-dev mailing list