<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">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 style="overflow-wrap: break-word;"><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_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>