SpiderNode for Firefox chrome code
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
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
* 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
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
If Node was available in Firefox, would you use it, and what would you
use it for?
More information about the firefox-dev