<div dir="ltr">On Tue, Dec 13, 2016 at 4:24 PM, Myk Melez <span dir="ltr"><<a href="mailto:myk@mykzilla.org" target="_blank">myk@mykzilla.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Brendan Dahl and I have been investigating the possibility of integrating SpiderNode into Firefox for use by chrome code.<br>
<br>
There are potential perf wins to using Node's File System (fs) module in place of the synchronous XPCOM nsIFile* APIs and their asynchronous (but single-threaded) OS.File equivalents. Brendan is currently investigating that use case to get a better sense of the potential.<br>
<br>
There are also several general benefits to Node:<br>
<br>
* It provides core APIs that are familiar to a much larger cohort of software engineers.<br>
<br>
There are perhaps a thousand engineers in the world who are familiar with XPCOM/JSM APIs (and their module systems), whereas there are hundreds of thousands of Node developers. So it'd help us attract more contributors (both volunteers and new employees).<br>
<br>
* It enables us to reuse modules from the Node ecosystem.<br>
<br>
Node would make it straightforward to integrate third-party modules from NPM. We can port some of them today, but many depend on core Node modules (or their own native modules), which makes porting expensive and often unfeasible. Whereas Node would make it possible to vendor modules using NPM's standard dependency management tools.<br>
<br>
Of course we'd still need to ensure that the modules (and their dependencies) are high-quality and have compatible licenses. Rust has the same problem with third-party crates. Still, that's a good problem to have, if it means we can sometimes borrow instead of build new functionality.<br>
<br>
* It supports more modular development of Firefox components.<br>
<br>
With Node, we could use GitHub and NPM to develop and distribute Firefox components as separate Node modules that we vendor into mozilla-central. Besides (arguably, I know) improving our own workflow, this exposes our code to a broader audience, which increases opportunities for reuse and contribution.<br>
<br>
Of course we'd still have to weigh the trade-offs to doing this for any given Firefox component. And make good decisions about what to develop monolithically vs. modularly (and what to develop in C++/Rust vs. in JS). Node doesn't solve those problems, it just makes it easier to choose modular JS development when it makes sense to do so.<br>
<br>
There are also at least two downsides:<br>
<br>
* Footprint will grow. We haven't yet measured the extent of this, but I expect there to be a significant impact from both the core module library and libuv <<a href="https://github.com/libuv/libuv" rel="noreferrer" target="_blank">https://github.com/libuv/libu<wbr>v</a>>, which Node entrains. We could reduce the impact of the module library by not packaging code we don't use, but we'd still take a hit.<br>
<br>
* Node's callback-based model for asynchronous programming makes it possible to fall into Callback Hell, the one significant developer-ergonomics disadvantage of Node APIs relative to Promise-based Mozilla equivalents. There are of course modules to promisify Node, along with coding patterns to minimize callback complexity, so it's a manageable issue. But it's still an issue.<br>
<br>
Overall, my sense is that the potential is significant enough to be worth investigating further, but only if there are either specific compelling use cases or significant developer interest in the general benefits.<br>
<br>
If Node was available in Firefox, would you use it, and what would you use it for?<br></blockquote><div><br></div>As a build system maintainer, I have a few more questions:<br><br></div><div class="gmail_quote">* Do we need to compile Node and libuv as part of the build? If so, how will that impact build times?<br></div><div class="gmail_quote">* Will Node enforce a filesystem layout for e.g. packages? If so, is that compatible with our source layout? Or, how much overhead will putting it in place add to the build?<br></div><div class="gmail_quote">* What about Windows (since Windows is typically an unloved OS for developers)?<br></div><div class="gmail_quote">* Many tools in the Node ecosystem require running Node as part of building. How will this work with cross-compile builds? (See my comments in bug 1320607 on the challenges of requiring "host binaries.")<br><br></div><div class="gmail_quote">And some other general questions:<br><br></div><div class="gmail_quote">* Will Node modules require yet another event loop? How does Node's event loop interact with existing event loops?<br></div><div class="gmail_quote">* What's the memory overhead? Does Node have granular memory management/monitoring that we've worked into JSMs via e.g. compartments and about:memory?<br></div><div class="gmail_quote">* What's the multi-thread/process story?<br></div><div class="gmail_quote">* Is there overhead e.g. passing thousands of strings between Node modules and JSMs?<br></div><div class="gmail_quote">* Do we care about implications for sandboxing?<br></div><div class="gmail_quote">* If we're going to perform a giant refactor of core components currently implemented in JS, would the time better be spent converting to Rust?<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Overall, I'm enticed by the idea of leveraging the Node ecosystem and developer community. You can't argue with the numbers and Firefox using Node could drive significant developer excitement towards Firefox. But actually seeing this through to completion feels like a massive project with no guarantee of success due to the various challenges involved. Good luck!<br></div><br></div></div>