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