SpiderNode for Firefox chrome code

Martin Thomson mt at mozilla.com
Wed Dec 14 01:18:29 UTC 2016


Does this have to be an all-or-nothing proposition?  For instance,
node links to openssl, which we almost certainly don't want.  I can't
imagine implementing a shim for node crypto given how tightly bound it
is to the idiosyncratic[1] openssl APIs.

[1] read: horrific

On Wed, Dec 14, 2016 at 11:24 AM, 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?
>
> -myk
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev



More information about the firefox-dev mailing list