SpiderNode for Firefox chrome code

Gregory Szorc gps at mozilla.com
Wed Dec 14 06:36:52 UTC 2016


On Tue, Dec 13, 2016 at 4:24 PM, Myk Melez <myk at mykzilla.org> wrote:

> 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?
>

As a build system maintainer, I have a few more questions:

* Do we need to compile Node and libuv as part of the build? If so, how
will that impact build times?
* Will Node enforce a filesystem layout for e.g. packages? If so, is that
compatible with our source layout? Or, how much overhead will putting it in
place add to the build?
* What about Windows (since Windows is typically an unloved OS for
developers)?
* Many tools in the Node ecosystem require running Node as part of
building. How will this work with cross-compile builds? (See my comments in
bug 1320607 on the challenges of requiring "host binaries.")

And some other general questions:

* Will Node modules require yet another event loop? How does Node's event
loop interact with existing event loops?
* What's the memory overhead? Does Node have granular memory
management/monitoring that we've worked into JSMs via e.g. compartments and
about:memory?
* What's the multi-thread/process story?
* Is there overhead e.g. passing thousands of strings between Node modules
and JSMs?
* Do we care about implications for sandboxing?
* If we're going to perform a giant refactor of core components currently
implemented in JS, would the time better be spent converting to Rust?

Overall, I'm enticed by the idea of leveraging the Node ecosystem and
developer community. You can't argue with the numbers and Firefox using
Node could drive significant developer excitement towards Firefox. But
actually seeing this through to completion feels like a massive project
with no guarantee of success due to the various challenges involved. Good
luck!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161213/5974b496/attachment.html>


More information about the firefox-dev mailing list