> 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/637cfa36/attachment.html>

> 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?