<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 6/4/13 9:52 AM, Jason Orendorff wrote:<br>
    <blockquote
cite="mid:CAPh8+ZpNDmwB1k7MzjciqM0peJJnDTz_myuM+vkBnc1xxMaK2A@mail.gmail.com"
      type="cite">
      <div dir="ltr">On Tue, Jun 4, 2013 at 11:44 AM, Jeff Morrison <span
          dir="ltr"><<a moz-do-not-send="true"
            href="mailto:lbljeffmo@gmail.com" target="_blank">lbljeffmo@gmail.com</a>></span>
        wrote:<br>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> 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.<br>
                <br>
                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).<span class="HOEnZb"><font color="#888888"><br>
                  </font></span></div>
            </blockquote>
            <div><br>
            </div>
            <div>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)?<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    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 downloaded.<br>
    <br>
    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:<br>
    <br>
    var importantDep = require('importantDep');<br>
    <br>
    class Foo extends importantDep {<br>
      bar() {<br>
        var lazyDep = require('lazyDep');<br>
        lazyDep.baz();<br>
      }<br>
    }<br>
    <br>
    exports.Foo = Foo;<br>
    <br>
    Here, the loader understands that this module has two dependencies
    "importantDep" and "lazyDep" and it downloads both before executing
    the module.<br>
    However, we don't "force execution" of the lazyDep module until
    someone comes along and calls the Foo.prototype.bar function.<br>
    <br>
    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.<br>
    <br>
    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.
    <blockquote
cite="mid:CAPh8+ZpNDmwB1k7MzjciqM0peJJnDTz_myuM+vkBnc1xxMaK2A@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>
              <br>
              -j<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>