Pretty sure your issue here is the multiple <script type="module"> tags.
In an ES module environment, you're supposed to set one entry point (with one script type module tag). Then use import statements to load in the other modules. The from string should be a URI that the browser can load modules from. To make this async, you would use the dynamic import( ... ) function syntax. Currently this has the issue that the browser has to parse each file to find and fetch it's dependencies. There's a couple of proposals to address this. Currently, in chromium based browsers, you can add module preload links in the header like so: <link rel="modulepreload" href="lib.mjs"> <link rel="modulepreload" href="main.mjs"> So for your example, you would use one <script type="module"> tag and 50 <link rel="modulepreload"> tags. "modulepreload" has been added to the HTML standard, but is not implemented everywhere. There's also the import maps proposal https://github.com/WICG/import-maps which would use a single manifest file to hint the dependency map to the browser instead of a stack of tags. It also contains a method for recognising package names, so, like in node, you can import from a package name instead of from a URL On May 26 2019, at 8:02 am, guest271314 <[email protected]> wrote: > > 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. > > What specifically should be compared? What are you trying to determine? > > The current question asks > > > how many async-modules can js-app practically load? > > which leads to asking how many async-modules are actually needed? > > 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 > https://stackoverflow.com/q/39959467 where the result is can be vary vastly > when using devices having different available RAM and hard-disk space. > > > 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. > On Sat, May 25, 2019 at 7:57 PM Wes Garland <[email protected] > (mailto:[email protected])> wrote: > > 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. > > > > 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) > > 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. > > 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. > > > > Thanks, > > Wes > > > > > > On Sat, 25 May 2019 at 02:41, guest271314 <[email protected] > > (mailto:[email protected])> wrote: > > > Have not tried babel or webpack. You can write the test to answer your > > > own inquiry and post the result at a gist. > > > > > > On Sat, May 25, 2019 at 6:34 AM kai zhu <[email protected] > > > (mailto:[email protected])> wrote: > > > > > 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] > > > > > (mailto:[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. 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > es-discuss mailing list > > > > > > > > [email protected] (mailto:[email protected]) > > > > > > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > es-discuss mailing list > > > > > > [email protected] (mailto:[email protected]) > > > > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > es-discuss mailing list > > > [email protected] (mailto:[email protected]) > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > > > -- > > Wesley W. Garland > > Director, Product Development > > PageMail, Inc. > > +1 613 542 2787 x 102 > > > > > _______________________________________________ > 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
