Minor questions on new module BNF

Jeff Morrison lbljeffmo at gmail.com
Tue Jun 4 11:08:43 PDT 2013

On 6/4/13 9:52 AM, Jason Orendorff wrote:
> On Tue, Jun 4, 2013 at 11:44 AM, Jeff Morrison <lbljeffmo at gmail.com 
> <mailto:lbljeffmo at gmail.com>> wrote:
>     FWIW this is what we have been doing at Facebook for a while now
>     (over a year), and it's worked pretty well for us.
>     We use a require() function for pulling in dependencies. We then
>     statically extract all require() callsites for a given module
>     during our build step, and use that to identify the
>     dependency-graph of a file (for packaging, etc).
> Thanks, this is a useful data point. Does your require() execute stuff 
> lazily, on demand? How much time does that save on startup (and are 
> there other benefits)?
require() is a synchronous call in to our module system, and we don't 
execute a given module until all of its require() dependencies have been 

90% of the time we place all of our require()s at the top of the file 
(for grokkability/style reasons mostly), but we have done several 
experiments that show that evaluation time of JS in certain critical 
scenarios is a measurable bottleneck at scale. We've also shown 
engagement wins from optimizing said scenarios by deferring execution of 
'less' important dependencies until they are needed. Contrived example:

var importantDep = require('importantDep');

class Foo extends importantDep {
   bar() {
     var lazyDep = require('lazyDep');

exports.Foo = Foo;

Here, the loader understands that this module has two dependencies 
"importantDep" and "lazyDep" and it downloads both before executing the 
However, we don't "force execution" of the lazyDep module until someone 
comes along and calls the Foo.prototype.bar function.

More realistic scenarios where we have employed this kind of 
optimization include initial page loads (especially on slower devices 
such as older mobile phones), our platform widgets such as the like 
button, etc.

In general, it is true that it should not be the common case to optimize 
these kinds things, but the language should still allow for such 
optimizations when they arise.
> -j

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130604/4f466add/attachment.html>

More information about the es-discuss mailing list