SpiderNode for Firefox chrome code
dteller at mozilla.com
Wed Dec 14 21:12:46 UTC 2016
On 14/12/16 19:48, Myk Melez wrote:
>> 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.
Wait, is he currently trying to use Node during the startup of Firefox?
Note that experience shows that loading JS code *during startup* and
afterwards have very different performance profiles.
>> 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.
By the way, if we wish to head this way, we certainly need a path to
perform Node <-> JSM and Node -> XPCOM. Both might need some finesse.
>> 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
Fair enough, with the caveats on adding a new library mentioned before.
>> 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.
Everything that increases true modularity (by opposition to XPCOM's
spaghetti modules) is a step forward, if it is feasible. I'm not
entirely convinced that we can do it with Firefox code, due to the
existing mess, but you may have ideas clearer than mine.
> (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.)
Yes, I'm thinking both of security risks and the npm-pocalypse. Using
yarn instead of npm would mitigate the latter, though.
More information about the firefox-dev