SpiderNode for Firefox chrome code

Richard Newman rnewman at mozilla.com
Wed Dec 14 01:21:38 UTC 2016


2¢ inline:

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

I'd put measuring this right at the top of the list. Gecko is already huge,
and if we're talking adding 15MB, this wouldn't be feasible to ship on
Android at all, which would mean no cross-platform features could use it,
which kinda defeats the point. We want Gecko to be getting smaller, not
larger.

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

I think that Node 7 has async/await, no?

That raises a broader concern: which Node version to support. I'd perhaps
be inclined to start with 7/8, given async/await, but for comparison, FxA
recently wrestled bugs just to get Node v4 into production, so there's
quite a spread within Mozilla already.

I also have a mild concern about Node native modules — in my limited
experience, just about anything interesting one would do with Node ends up
requiring some native module down in the guts, which might have an impact
on how much value we'd get from npm. Do you have a native module
compatibility story for SpiderNode yet?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161213/7b64aadf/attachment.html>


More information about the firefox-dev mailing list