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

Wes Garland wes at page.ca
Sat May 25 19:56:49 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.

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/1f632f1e/attachment.html>


More information about the es-discuss mailing list