SpiderNode for Firefox chrome code

Myk Melez myk at mykzilla.org
Wed Dec 14 18:48:34 UTC 2016


> David Teller <mailto:dteller at mozilla.com>
> 2016 December 14 at 01:11
> 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.
Brendan is looking at addons manager startup perf at the moment, so he 
should be able to speak to this.

> 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.
That's true in the short term, but as components go Node-only, that 
creates opportunities for Node-only developers to contribute to them, 
especially if they're developed modularly.

> 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.
The primary benefit of Node is not the module loader itself but its API 
library, which'll remain valuable even after we migrate JSMs to ES6 
modules. Incidentally, Node is planning ES6 module support too.

> 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".
Indeed, this is a downside to introducing yet another way to do things.

> I like this train of thought. Do you think that distributing modules
> separately would be realistic?
Yes, I think the distribution model for Node modules—at least those 
developed on GitHub and published to NPM—is an extremely well-worn path, 
and it would be realistic to do so and vendor them into Firefox.

(There is some theoretical security risk to relying on third-party 
services like GitHub and NPM. We're already biting that bullet with 
GitHub, which a variety of Mozilla developers are using to develop code. 
It isn't clear if NPM would be a bridge too far, but if so, then 
presumably we could instead vendor directly from GitHub, or wherever 
else we host the module source.)

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161214/434d6b18/attachment.html>


More information about the firefox-dev mailing list