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

guest271314 guest271314 at gmail.com
Sat May 25 06:41:05 UTC 2019


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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190525/2031de73/attachment.html>


More information about the es-discuss mailing list