how many async-modules can js-app practically load?

kai zhu kaizhu256 at gmail.com
Fri May 31 17:39:59 UTC 2019


> Oh, and yes, I've loaded upwards of 50-100 modules in development. 20
modules is *easy* to achieve in single-page apps.

was that with some combination of babel/rollup/webpack or pure-es6?
if i want to develop a pure-es6 webapp (no babel), how would i transition
from development-mode (20 es-module files) -> production-mode (1 rollup
file)?


On Fri, May 31, 2019 at 10:47 AM Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> If it's bundled by Rollup or Webpack into a single bundle, it's
> equivalent to a single `<script type="module" src="...">` pointing
> towards the original entry point, excluding network requests.* But in
> either case, you aren't listing 50 scripts, you're only listing the
> entry module and importing child modules within parent modules. Rollup
> and Webpack do mostly the same thing browsers do when it comes to
> resolving dependencies, just they generate a bundle afterwards where
> browsers execute code afterwards. Also, it's worth noting that the gap
> between a single large request and multiple smaller requests has
> shrunk a lot since HTTP/2 came along, since it's binary, it allows
> requests and response data to be interleaved, it better leverages the
> underlying TCP protocol format, and it allows servers to send data
> pre-emptively without the client requesting it first. (Web sockets are
> built on this functionality.) It's still better to bundle in general,
> but it's less of a problem not to.
>
> This is *not* the case for `<script type="module">` elements - those
> operate more like inline scripts that happen to have the ability to
> `import`.
>
> Oh, and yes, I've loaded upwards of 50-100 modules in development. 20
> modules is *easy* to achieve in single-page apps.
>
> * This is, of course, not the case if you are using pure ES6 and you
> aren't using any plugins to, say, run the original source through
> Babel for React + JSX or something.
>
> -----
>
> Isiah Meadows
> contact at isiahmeadows.com
> www.isiahmeadows.com
> On Sat, May 25, 2019 at 2:12 AM kai zhu <kaizhu256 at gmail.com> wrote:
> >
> > Asynchronous loading differs only in
> > that it takes more code to express the same logic and you have to take
> > into account concurrent requests (and you need to cache the request,
> > not the result), but it's otherwise the same from 1km away.
> >
> >
> > so async-loading 50 ```<script type="module">``` tags
> > has equivalent side-effect
> > as sync-loading single webpack-rollup (of same 50 modules)?
> >
> > i have nagging suspicion of doubts.  has anyone tried native
> async-loading large numbers (>10) of
> > ```<script type="module">``` tags, and verify it resolves identically to
> using a single webpack-rollup?
> >
> > again, i'm not that knowledgeable on es-modules, so above question may
> be trivially true, and i'm just not aware.
> >
> > -kai
> >
> > On 24 May 2019, at 23:41, Isiah Meadows <isiahmeadows at gmail.com> wrote:
> >
> > There's two main reasons why it scales:
> >
> > 1. Modules are strongly encapsulated while minimizing global pollution.
> > 2. The resolution algorithm applies the same logic no matter how many
> > modules are loaded.
> >
> > It's much easier for it to scale when you write the code unaware of
> > how many modules you might be loading and unaware of how deep their
> > dependency graph is. Fewer assumptions here is key. It's an
> > engineering problem, but a relatively simple one.
> >
> > If you want a short example of how sync module resolution works, you
> > can take a look at this little utility I wrote:
> > https://github.com/isiahmeadows/simple-require-loader. That doesn't
> > asynchronously resolve modules, but it should help explain the process
> > from a synchronous standpoint. Asynchronous loading differs only in
> > that it takes more code to express the same logic and you have to take
> > into account concurrent requests (and you need to cache the request,
> > not the result), but it's otherwise the same from 1km away.
> >
> > -----
> >
> > Isiah Meadows
> > contact at isiahmeadows.com
> > www.isiahmeadows.com
> >
> > On Thu, May 23, 2019 at 10:49 AM kai zhu <kaizhu256 at gmail.com> wrote:
> >
> >
> > actually, i admit i don't know what i'm talking about.  just generally
> confused (through ignorance) on how large-scale es-module dependencies
> resolve when loaded/imported asynchronously.
> >
> > On Wed, May 22, 2019 at 10:42 PM Logan Smyth <loganfsmyth at gmail.com>
> wrote:
> >
> >
> > Can you elaborate on what loading state you need to keep track of? What
> is the bottleneck that you run into? Also to be sure, when you say
> async-load, do you mean `import()`?
> >
> > On Wed, May 22, 2019, 20:17 kai zhu <kaizhu256 at gmail.com> wrote:
> >
> >
> > i don't use es-modules.
> > but with amd/requirejs, I start having trouble with
> module-initializations in nodejs/browser at ~5 async modules (that may or
> may not have circular-references).  10 would be hard, and 20 would be near
> inhuman for me.
> >
> > can we say its somewhat impractical for most applications to load more
> than 50 async modules (with some of them having circular-references)?  and
> perhaps better design/spec module-loading mechanisms with this usability
> concern in mind?
> >
> > p.s. its also impractical for me to async-load 5 or more modules without
> using globalThis to keep track of each module's loading-state.
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190531/5ea8d4c9/attachment.html>


More information about the es-discuss mailing list