<div dir="ltr">> 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.<div><br></div><div>What specifically should be compared? What are you trying to determine?</div><div><br></div>The current question asks <div><br></div><div>> how many async-modules can js-app practically load?</div><div><br></div><div>which leads to asking how many async-modules are actually needed?</div><div><br></div><div>From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules, similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used; e.g., see How to solve Uncaught RangeError when download large size json</div><div> <a href="https://stackoverflow.com/q/39959467">https://stackoverflow.com/q/39959467</a> where the result is can be vary vastly when using devices having different available RAM and hard-disk space. <br></div><div><br></div><div>Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 25, 2019 at 7:57 PM Wes Garland <<a href="mailto:wes@page.ca">wes@page.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>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.<br><br></div>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)<br><br></div><div>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.<br><br></div><div>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.</div><div><br></div><div>Thanks,<br></div>Wes<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 25 May 2019 at 02:41, guest271314 <<a href="mailto:guest271314@gmail.com" target="_blank">guest271314@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Have not tried babel or webpack. You can write the test to answer your own inquiry and post the result at a gist.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 25, 2019 at 6:34 AM kai zhu <<a href="mailto:kaizhu256@gmail.com" target="_blank">kaizhu256@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div dir="ltr"><div>Why would 50 separate <font face="Courier">```<script type="module">```</font> tags be needed?</div></div></blockquote><br></div><div>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).</div><br><blockquote type="cite"><div dir="ltr"><div>Have you tried the two described approaches and compared the result? How is "identically" determined?</div></div></blockquote><div><div dir="ltr"><div><br></div><div>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 <font face="Courier">```<script type="module">```</font> tags.</div><div><br></div><div>-kai</div><div><br></div><div><br></div></div></div><div><br><blockquote type="cite"><div>On 25 May 2019, at 01:20, guest271314 <<a href="mailto:guest271314@gmail.com" target="_blank">guest271314@gmail.com</a>> wrote:</div><br class="gmail-m_7138528805602302357gmail-m_2441562360542798457gmail-m_-5288448846394902485Apple-interchange-newline"><div><div dir="ltr">> so async-loading 50 <font face="Courier">```<script type="module">```</font> tags has equivalent side-effect<div>as sync-loading single webpack-rollup (of same 50 modules)?</div><div><br></div><div>Why would 50 separate <font face="Courier">```<script type="module">```</font> tags be needed?</div><div><br></div><div>> has anyone tried native async-loading large numbers (>10) of <font face="Courier">```<script type="module">```</font> tags, and verify it resolves identically to using a single webpack-rollup?</div><div><br></div><div>Have you tried the two described approaches and compared the result? </div><div><br></div><div>How is "identically" determined?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 25, 2019 at 6:12 AM kai zhu <<a href="mailto:kaizhu256@gmail.com" target="_blank">kaizhu256@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite">Asynchronous loading differs only in<br>that it takes more code to express the same logic and you have to take<br>into account concurrent requests (and you need to cache the request,<br>not the result), but it's otherwise the same from 1km away.<br></blockquote><br></div>so async-loading 50 <font face="Courier">```<script type="module">```</font> tags<div>has equivalent side-effect</div><div>as sync-loading single webpack-rollup (of same 50 modules)?</div><div><div><div><br></div><div>i have nagging suspicion of doubts.  has anyone tried native async-loading large numbers (>10) of</div><div><font face="Courier">```<script type="module">```</font> tags, and verify it resolves identically to using a single webpack-rollup?</div><div></div><div><div><br></div><div>again, i'm not that knowledgeable on es-modules, so above question may be trivially true, and i'm just not aware.</div><div><br></div><div>-kai</div><div><br><blockquote type="cite"><div>On 24 May 2019, at 23:41, Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>> wrote:</div><br class="gmail-m_7138528805602302357gmail-m_2441562360542798457gmail-m_-5288448846394902485gmail-m_4014858903265910730Apple-interchange-newline"><div><div>There's two main reasons why it scales:<br><br>1. Modules are strongly encapsulated while minimizing global pollution.<br>2. The resolution algorithm applies the same logic no matter how many<br>modules are loaded.<br><br>It's much easier for it to scale when you write the code unaware of<br>how many modules you might be loading and unaware of how deep their<br>dependency graph is. Fewer assumptions here is key. It's an<br>engineering problem, but a relatively simple one.<br><br>If you want a short example of how sync module resolution works, you<br>can take a look at this little utility I wrote:<br><a href="https://github.com/isiahmeadows/simple-require-loader" target="_blank">https://github.com/isiahmeadows/simple-require-loader</a>. That doesn't<br>asynchronously resolve modules, but it should help explain the process<br>from a synchronous standpoint. Asynchronous loading differs only in<br>that it takes more code to express the same logic and you have to take<br>into account concurrent requests (and you need to cache the request,<br>not the result), but it's otherwise the same from 1km away.<br><br>-----<br><br>Isiah Meadows<br><a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a><br><a href="http://www.isiahmeadows.com/" target="_blank">www.isiahmeadows.com</a><br><br>On Thu, May 23, 2019 at 10:49 AM kai zhu <<a href="mailto:kaizhu256@gmail.com" target="_blank">kaizhu256@gmail.com</a>> wrote:<br><blockquote type="cite"><br>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.<br><br>On Wed, May 22, 2019 at 10:42 PM Logan Smyth <<a href="mailto:loganfsmyth@gmail.com" target="_blank">loganfsmyth@gmail.com</a>> wrote:<br><blockquote type="cite"><br>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()`?<br><br>On Wed, May 22, 2019, 20:17 kai zhu <<a href="mailto:kaizhu256@gmail.com" target="_blank">kaizhu256@gmail.com</a>> wrote:<br><blockquote type="cite"><br>i don't use es-modules.<br>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.<br><br>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?<br><br>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.<br>_______________________________________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br></blockquote></blockquote><br>_______________________________________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br></blockquote></div></div></blockquote></div><br></div></div></div></div>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
</div></blockquote></div><br></div></blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_7138528805602302357gmail_signature">Wesley W. Garland<br>Director, Product Development<br>PageMail, Inc.<br>+1 613 542 2787 x 102</div>
</blockquote></div>