> 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 <[email protected]> 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 > [email protected] > www.isiahmeadows.com > > On Thu, May 23, 2019 at 10:49 AM kai zhu <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
