SpiderNode for Firefox chrome code
myk at mykzilla.org
Fri Dec 16 17:55:39 UTC 2016
> David Teller <mailto:dteller at mozilla.com>
> 2016 December 14 at 13:12
> On 14/12/16 19:48, Myk Melez wrote:
>> 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?
Yes, that's one of the use cases he's looking into.
> Note that experience shows that loading JS code *during startup* and
> afterwards have very different performance profiles.
Noted! Brendan is planning to do some startup perf measurements to get a
sense of the cost of using Node during startup.
> 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.
In the experiments we've been doing, the Node modules have access to the
Components global, which means they can access XPCOM APIs and JSMs.
Likewise, JSMs can access Node modules.
> 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.
Perhaps, although I too think it'd be challenging, for a variety of
reasons, which is why I started this thread. I'd like to get a sense of
the potential value before we spend a bunch of time figuring out more of
> Yes, I'm thinking both of security risks and the npm-pocalypse. Using
> yarn instead of npm would mitigate the latter, though.
Indeed. I'm agnostic about the tool (and repository, although yarn
reuses NPM's repository). We could even vendor modules directly from
their source repositories, although distributing via NPM is handy for
enforcing a discipline of unit testing, documentation, and other best
practices for NPM-distributed modules.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the firefox-dev