<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">
<blockquote style="border: 0px none;"
cite="mid:aae81f29-a44f-edac-2318-7b0dde0538d7@mozilla.com" type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="width:100%;border-top:2px solid #EDF1F4;padding-top:10px;"> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:49%;">
<a moz-do-not-send="true" href="mailto:dteller@mozilla.com"
style="color:#485664
!important;padding-right:6px;font-weight:500;text-decoration:none
!important;">David Teller</a></div> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:48%;text-align:
right;"> <font color="#909AA4"><span style="padding-left:6px">2016
December 14 at 01:11</span></font></div> </div></div>
</blockquote>
<blockquote style="border: 0px none;"
cite="mid:aae81f29-a44f-edac-2318-7b0dde0538d7@mozilla.com" type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">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.</pre>
</div>
</blockquote>
Brendan is looking at addons manager startup perf at the moment, so he
should be able to speak to this.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:aae81f29-a44f-edac-2318-7b0dde0538d7@mozilla.com" type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">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.</pre>
</div>
</blockquote>
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.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:aae81f29-a44f-edac-2318-7b0dde0538d7@mozilla.com" type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">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.</pre>
</div>
</blockquote>
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.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:aae81f29-a44f-edac-2318-7b0dde0538d7@mozilla.com" type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">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".</pre>
</div>
</blockquote>
Indeed, this is a downside to introducing yet another way to do things.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:aae81f29-a44f-edac-2318-7b0dde0538d7@mozilla.com" type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">I like this train of thought. Do you think that distributing modules
separately would be realistic?</pre>
</div>
</blockquote>
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.<br>
<br>
(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.)<br>
<br>
-myk<br>
<br>
</body></html>