1459770 - prototype & benchmark pure runtime ES module loading for New Tab

Status: REOPENED

(Firefox :: Messaging System, task, P3)

Comment 1

[Punam Dahiya [:pdahiya]]

NI @dmosedale if the task is still valid thanks

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

@Punam -- this is still valid.

Right now, our in-content web-pages are all bundled with webpack. The idea here is that once omnijar caching for local content ES modules is sufficiently good, it's conceivable (though not clear how likely) that we could simply stop bundling entirely (or partly) and load the es modules we use directly (possibly some of them lazily), and performance could be good enough.

It's not particularly clear that this is likely, so I suspect the first steps here would be to:

• figure out approximately what this would look like (eg how many files, particularly at startup time)
• do a very simple, very-time-boxed prototype
• if we hit the time-box, find the right person in the JS team or elsewhere to give us a sense of whether this is worth prototyping further.

Adding a few folks to the CC (Hi, Mark & Gijs) who might have some sense of this off the top of their heads.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

The motivations here are that if the perf is good enough:

• we could stop checking in bundle artifacts
• we'd never have to vendor in a bundler in the future
• things would be a bit easier for regular fx to get up to speed on and everyone to hack on

Comment 4

[Mark Banner (:standard8)]

(In reply to Dan Mosedale (:dmosedale, :dmose) from comment #2)

Adding a few folks to the CC (Hi, Mark & Gijs) who might have some sense of this off the top of their heads.

Loading/compiling individual modules is still likely to have a performance impact vs them all being combined. That said, it might be possible to adjust the existing caching system to provide some kind of caching there, but getting ideas for that would need someone to talk to the JS team.

Comment 5

[:Gijs (out for now; he/him)]

Between all the caching done by the about home startup cache and the tab preload system, it just seems really unlikely that the few-ms-at-most overhead of loading modules on the very first run is likely to feature heavily in real user perceived performance. If it does, I'd be more interested in having an installer task that pre-caches into the about home startup cache than in continuing to have preprocessed files checked in in addition to the "real" source code. Though then again, it seems we haven't shipped the cache - bug 1614351.