<div dir="ltr"><div>Following up here:<br><br>I think ultimately this is falling flat with me for a few reasons. 
First we know it will add a bunch of overhead to gecko. Second to reduce
 that we're talking about turning off node features that will break node compatibility. 
Thirdly I still haven't heard a strong use case for doing it.<br><br></div>I
 do think that we want a good way to use npm modules that don't depend 
on node modules themselves, things like react and redux are in use in 
our tree now and we probably want to grow their use. Currently the SDK 
module loader is good enough, we do have some performance concerns with 
it but it will be easier to fix those than introducing spidernode.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 14, 2016 at 2:12 PM, David Teller <span dir="ltr"><<a href="mailto:dteller@mozilla.com" target="_blank">dteller@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 14/12/16 19:48, Myk Melez wrote:<br>
>> David Teller <mailto:<a href="mailto:dteller@mozilla.com">dteller@mozilla.com</a>><br>
<span class="">>> 2016 December 14 at 01:11<br>
>> The two remaining perf-related issues we have with OS.File are:<br>
>> - memory use (ChromeWorker + js-ctypes is quite memory-inefficient);<br>
>> - slow startup (loading js files during startup is inefficient).<br>
>><br>
>> I suspect that Node would not help with either issue, but feel free to<br>
>> prove me wrong.<br>
> Brendan is looking at addons manager startup perf at the moment, so he<br>
> should be able to speak to this.<br>
<br>
</span>Wait, is he currently trying to use Node during the startup of Firefox?<br>
<br>
Note that experience shows that loading JS code *during startup* and<br>
afterwards have very different performance profiles.<br>
<span class=""><br>
>> Unfortunately, my personal experience shows that<br>
>> having yet another API to the platform typically would mean that<br>
>> developers/contributors need to understand *all of* XPCOM, JSM and Node,<br>
>> not any of them. So I'd count this as a drawback.<br>
><br>
> That's true in the short term, but as components go Node-only, that<br>
> creates opportunities for Node-only developers to contribute to them,<br>
> especially if they're developed modularly.<br>
<br>
</span>That's possible.<br>
<br>
By the way, if we wish to head this way, we certainly need a path to<br>
perform Node <-> JSM and Node -> XPCOM. Both might need some finesse.<br>
<span class=""><br>
><br>
>> Also note that there are (currently unmanned) plans to migrate away from<br>
>> JSM and into ES6 modules. If/when this happens, this will decrease the<br>
>> benefit of Node on this aspect.<br>
> The primary benefit of Node is not the module loader itself but its API<br>
> library, which'll remain valuable even after we migrate JSMs to ES6<br>
> modules.<br>
<br>
</span>Fair enough, with the caveats on adding a new library mentioned before.<br>
<span class=""><br>
>> I like this train of thought. Do you think that distributing modules<br>
>> separately would be realistic?<br>
> Yes, I think the distribution model for Node modules—at least those<br>
> developed on GitHub and published to NPM—is an extremely well-worn path,<br>
> and it would be realistic to do so and vendor them into Firefox.<br>
<br>
</span>Everything that increases true modularity (by opposition to XPCOM's<br>
spaghetti modules) is a step forward, if it is feasible. I'm not<br>
entirely convinced that we can do it with Firefox code, due to the<br>
existing mess, but you may have ideas clearer than mine.<br>
<span class=""><br>
> (There is some theoretical security risk to relying on third-party<br>
> services like GitHub and NPM. We're already biting that bullet with<br>
> GitHub, which a variety of Mozilla developers are using to develop code.<br>
> It isn't clear if NPM would be a bridge too far, but if so, then<br>
> presumably we could instead vendor directly from GitHub, or wherever<br>
> else we host the module source.)<br>
<br>
</span>Yes, I'm thinking both of security risks and the npm-pocalypse. Using<br>
yarn instead of npm would mitigate the latter, though.<br>
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
 David<br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
</div></div></blockquote></div><br></div>