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

Frederick Stark coagmano at gmail.com
Fri May 31 04:52:28 UTC 2019


Pretty sure your issue here is the multiple <script type="module"> tags.

In an ES module environment, you're supposed to set one entry point (with one script type module tag). Then use import statements to load in the other modules. The from string should be a URI that the browser can load modules from.
To make this async, you would use the dynamic import( ... ) function syntax.
Currently this has the issue that the browser has to parse each file to find and fetch it's dependencies.
There's a couple of proposals to address this. Currently, in chromium based browsers, you can add module preload links in the header like so:

<link rel="modulepreload" href="lib.mjs">
<link rel="modulepreload" href="main.mjs">
So for your example, you would use one <script type="module"> tag and 50 <link rel="modulepreload"> tags.
"modulepreload" has been added to the HTML standard, but is not implemented everywhere.

There's also the import maps proposal https://github.com/WICG/import-maps which would use a single manifest file to hint the dependency map to the browser instead of a stack of tags. It also contains a method for recognising package names, so, like in node, you can import from a package name instead of from a URL
On May 26 2019, at 8:02 am, guest271314 <guest271314 at gmail.com> wrote:
> > If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare.
>
> What specifically should be compared? What are you trying to determine?
>
> The current question asks
>
> > how many async-modules can js-app practically load?
>
> which leads to asking how many async-modules are actually needed?
>
> From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules, similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used; e.g., see How to solve Uncaught RangeError when download large size json
> https://stackoverflow.com/q/39959467 where the result is can be vary vastly when using devices having different available RAM and hard-disk space.
>
>
> Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
> On Sat, May 25, 2019 at 7:57 PM Wes Garland <wes at page.ca (mailto:wes at page.ca)> wrote:
> > If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare.
> >
> > I'm in an environment where it is still not practical to use ES modules, and have started work again on BravoJS, which implements the old CommonJS Modules/2.0 strawman. (Same primordial development soup as AMD, but with a different set of flaws; favouring correctness/compatibility instead of brevity)
> > How I've solved this problem historically is to have some smarts on the server side, that feeds (transitive) dependencies of a module at the same time as the module. It will be interesting to play with that type of loader -- if possible -- once ES module loaders become well-defined/implemented/available.
> > We also have to remember that loading via SCRIPT tags -- type=module or not -- is important to developers, so that we can load modules from CDNs and so on without cross-site security pain.
> >
> > Thanks,
> > Wes
> >
> >
> > On Sat, 25 May 2019 at 02:41, guest271314 <guest271314 at gmail.com (mailto:guest271314 at gmail.com)> wrote:
> > > Have not tried babel or webpack. You can write the test to answer your own inquiry and post the result at a gist.
> > >
> > > On Sat, May 25, 2019 at 6:34 AM kai zhu <kaizhu256 at gmail.com (mailto:kaizhu256 at gmail.com)> wrote:
> > > > > Why would 50 separate ```<script type="module">``` tags be needed?
> > > > >
> > > >
> > > >
> > > > because a reason for es-module's existence in the first place is to bring "large-scale modular development" to the browser. i want to test that claim (hence this thread's subject-title).
> > > > > Have you tried the two described approaches and compared the result? How is "identically" determined?
> > > >
> > > > no i haven't, and i suspect nobody does in practice, because they all use babel/webpack. identicality would be determined by if the app functions the same regardless whether you used a webpack-rollup or individual ```<script type="module">``` tags.
> > > >
> > > > -kai
> > > >
> > > >
> > > >
> > > > > On 25 May 2019, at 01:20, guest271314 <guest271314 at gmail.com (mailto:guest271314 at gmail.com)> wrote:
> > > > > > so async-loading 50 ```<script type="module">``` tags has equivalent side-effect
> > > > > as sync-loading single webpack-rollup (of same 50 modules)?
> > > > >
> > > > > Why would 50 separate ```<script type="module">``` tags be needed?
> > > > >
> > > > > > 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?
> > > > >
> > > > > Have you tried the two described approaches and compared the result?
> > > > >
> > > > > How is "identically" determined?
> > > > > On Sat, May 25, 2019 at 6:12 AM kai zhu <kaizhu256 at gmail.com (mailto: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 (mailto: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 (mailto:contact at isiahmeadows.com)
> > > > > > > www.isiahmeadows.com (http://www.isiahmeadows.com/)
> > > > > > >
> > > > > > > On Thu, May 23, 2019 at 10:49 AM kai zhu <kaizhu256 at gmail.com (mailto: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 (mailto: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 (mailto: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 (mailto:es-discuss at mozilla.org)
> > > > > > > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > es-discuss mailing list
> > > > > > > > es-discuss at mozilla.org (mailto:es-discuss at mozilla.org)
> > > > > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > es-discuss mailing list
> > > > > > es-discuss at mozilla.org (mailto:es-discuss at mozilla.org)
> > > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > es-discuss mailing list
> > > es-discuss at mozilla.org (mailto:es-discuss at mozilla.org)
> > > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> >
> > --
> > Wesley W. Garland
> > Director, Product Development
> > PageMail, Inc.
> > +1 613 542 2787 x 102
> >
>
>
> _______________________________________________
> 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/e8b0bef5/attachment-0001.html>


More information about the es-discuss mailing list