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

guest271314 guest271314 at gmail.com
Sat May 25 22:02:13 UTC 2019


> 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> 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> 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> 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> 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> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190525/5fca06f2/attachment-0001.html>


More information about the es-discuss mailing list