<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body text="#000000" bgcolor="#FFFFFF">
<blockquote style="border: 0px none;"
cite="mid:CAPMxTNoyjzQCSS4SLqKjSnfyjfDBpLBD2w9+4v3cUCscZ0Sgbg@mail.gmail.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:dtownsend@mozilla.com"
style="color:#485664
!important;padding-right:6px;font-weight:500;text-decoration:none
!important;">Dave Townsend</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">2017
January 3 at 13:54</span></font></div> </div></div>
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><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></div></div></div>
</blockquote>
It still isn't clear to me how much overhead it'll cost (bdahl is close
to getting some Talos numbers). Nevertheless, I agree with you that we
haven't heard a compelling use case, and I'd want one before doing the
rest of the integration work.
<blockquote style="border: 0px none;"
cite="mid:CAPMxTNoyjzQCSS4SLqKjSnfyjfDBpLBD2w9+4v3cUCscZ0Sgbg@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div dir="ltr">
<div><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>
</blockquote>
Sure, and that makes sense for Firefox's immediate needs. OS.File
improvements could also be in scope there. I do think we face a
medium-term challenge of underowned platform code (similar to our
challenge with legacy XUL). But perhaps SpiderNode is a bridge too far
for that (or the wrong solution to that problem).<br>
<br>
-myk<br>
<br>
</body></html>