SpiderNode for Firefox chrome code

David Teller dteller at mozilla.com
Wed Dec 14 09:11:49 UTC 2016



On 14/12/16 01:24, Myk Melez 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.

I don't think you're going to get performance wins for uses of nsIFile*
because (barring any error) we have already migrated to async everything
that we could migrate without major refactorings.

During runtime, I don't think you're going to get perf wins for OS.File,
either – at least, no perf issues have been reported so far. That's
actually the reason for which OS.File is single-threaded. The initial
implementation was multi-threaded but it turned out that we don't make
use of that.

The two remaining perf-related issues we have with OS.File are:
- memory use (ChromeWorker + js-ctypes is quite memory-inefficient);
- slow startup (loading js files during startup is inefficient).

I suspect that Node would not help with either issue, but feel free to
prove me wrong. I'm personally planning to invest some time in a Rust
reimplementation of OS.File, which would fix both, but I don't know when.

> 
> 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).

That sounds good. Unfortunately, my personal experience shows that
having yet another API to the platform typically would mean that
developers/contributors need to understand *all of* XPCOM, JSM and Node,
not any of them. So I'd count this as a drawback.

Also note that there are (currently unmanned) plans to migrate away from
JSM and into ES6 modules. If/when this happens, this will decrease the
benefit of Node on this aspect.

> * 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.

Again, that sounds good, but we are going to end up with yet-another-way
of doing the same thing. Consider that mixing nsIFile and OS.File is
already unsafe (due to threading). Now mixing nsIFile + OS.File + fs
will make things even harder to trust. Similarly, mixing nsIFile + libuv
in C++ code would make things "interesting".

> * 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.

I like this train of thought. Do you think that distributing modules
separately would be realistic?

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

Given the issues above, I think I might use it for experiments, but I
would be very nervous of r+ing any change based on Node.

Cheers,
 David



More information about the firefox-dev mailing list