> 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 <[email protected]> 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 <[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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
