how many async-modules can js-app practically load?

kai zhu kaizhu256 at gmail.com
Sun Jun 2 23:05:15 UTC 2019


not inline multiple ```export```'s, but inline multiple module-scopes.

```js
/*
 * how do you inline the two es-modules below
 * with colliding `foo` and `bar` variables?
 *
 * you can't unless you introduce new language-syntax
 * to somehow delimit their scopes
 */

// [hypothethical] es-module-scope delimiter
# es-module-scope "./inline.js"

// module ./inline.js
import { foo } from "./aa.js"
const bar = { baz: foo };
export { bar };



// [hypothethical] es-module-scope delimiter
# es-module-scope ./nextinline.js

// module ./nextinline.js
import { foo } from "./bb.js"
const bar = { baz: foo };
export { bar };
```

On Sun, Jun 2, 2019 at 2:54 PM guest271314 <guest271314 at gmail.com> wrote:

> Multiple imports are already possible
>
> ```
> import {inline} from "./inline.js";
> import {nextInline} from "./nextInline.js";
>
> const o = {
>   a:1, b:2, c:3
> };
>
> // ...
>
> export {o, cities, video, inline, nextInline};
> ```
>
> Are you proposing multiple ```export```s?
>
> ```
> export {o, cities, video, inline, nextInline};
> o.c = 7;
> export {o};
> ```
>
>
>
> On Sun, Jun 2, 2019 at 6:19 PM kai zhu <kaizhu256 at gmail.com> wrote:
>
>> @guest271314 <guest271314 at gmail.com>, your example again is not a
>> [native] bundle of two or more inlined es-modules.  its just a single
>> es-module that that fetches json data.
>>
>> i'm asking if its desirable to inline multiple es-modules into a single
>> file natively, e.g.:
>>
>> ```
>> /*
>>  * es-module.rollup.js
>>  * this [hypothetical] rollup-file contains multiple inlined es-modules
>>  * to improve load-performance in production-deployment.
>>  */
>>
>> // 1. inlined es-module ./main.js
>> import { foo } from "./counter.js"
>> import { bar } from "./display.js"
>> foo(bar);
>>
>> // 2. inlined es-module ./counter.js
>> var foo;
>> foo = function (bar) {
>>     bar();
>> };
>> export { foo }
>>
>> // 3. inlined es-module ./display.js
>> var bar;
>> bar = function () {
>>     console.log("hello world");
>> };
>> export { bar }
>> ```
>>
>> this native es-module inline-capability may not be desirable to you,
>> which is fine.  it would be a datapoint against this feature (and rely
>> instead on pre-emptive import-maps and http2-push, as explained by
>> @frederick and @isiah).
>>
>>
>> On Sun, Jun 2, 2019 at 11:22 AM guest271314 <guest271314 at gmail.com>
>> wrote:
>>
>>> 1) original-question - is native es-module's async-behavior desirable?
>>>> async side-effects are difficult to manage -- i conjecture that
>>>> async-loading 20 es-modules (with dependent side-effects) is not practical
>>>> for most mortals to handle.
>>>
>>>
>>> It depends on what *you *mean by "desirable" in a given context.
>>>
>>> There is no difference from loading 1 module and loading 1000 modules
>>> except for network cost, memory and disk space usage.
>>>
>>> Mortals can handle far more than loading 20 es-modules.
>>>
>>> What are the specific  "side-effects" that you are referring to?
>>>
>>> describes the mechanism for how to hint the brower to pre-fetch 20
>>>> es-modules. but if you pre-fetch, then is loading-behavior effectively
>>>> synchronous?
>>>
>>>
>>> Resources can be "pre-fetched" using various means. From caching the
>>> first request and using the cached data instead of making future requests
>>> for the same resources to storing one or more entire directories in the
>>> browser configuration folder using `requestFileSystem` (Chromiom/Chrome).
>>>
>>> but was unclear whether they were individual [async] ```<script
>>>> type="module">``` tags, or some es5-transpiled rollup
>>>
>>>
>>> There should not be any difference between the two approaches. If there
>>> is a difference then you should be able to clearly state what the
>>> difference is, and demonstrate the difference by reproduction, without
>>> speculating and not demonstrating a difference by means of reproduction.
>>>
>>> 2) the second-question about es-module rollups (which you and i are
>>>> debating) stemmed from @isiah's response -- if he and everyone-else use
>>>> es5-transpiled rollups (which i suspect),
>>>
>>>
>>> Do not care what "everyone-else" is supposedly doing. How can you
>>> possibly know what everyone-else is doing and even if you did know what
>>> third-parties are doing how does that affect what you are doing?
>>>
>>> then shouldn't it be desirable for es-modules to natively support
>>>> rollups as well?  currently, there's no way to natively rollup multiple
>>>> es-modules into a single bundle.
>>>
>>>
>>> There are ways to "bundle" multiple modules into a single export
>>> "natively", as demonstrated at the previously posted code.
>>>
>>> Another example approach
>>>
>>> ```
>>> // sync
>>> const o = {
>>>   a:1, b:2, c:3
>>> };
>>> // async
>>> const cities = fetch("
>>> https://gist.githubusercontent.com/guest271314/ffac94353ab16f42160e/raw/aaee70a3e351f6c7bc00178eabb5970a02df87e9/states.json
>>> ")
>>>                .then(response => response.json())
>>>                .catch(e => {console.error(e); return "error fetching
>>> cities module"});
>>> // async
>>> const video = fetch("
>>> https://upload.wikimedia.org/wikipedia/commons/d/d9/120-cell.ogv")
>>>                .then(response => response.blob())
>>>               .catch(e => {console.error(e); return "error fetching
>>> video module"});
>>> // multiple "modules" exported
>>> export {o, cities, video};
>>> ```
>>>
>>> at single ```<script type="module">```
>>>
>>> ```
>>>     <script type="module">
>>>       import * as o from "./script.js";
>>>       (async(mods) => {
>>>         for (const [key, value] of mods) {
>>>           if (value instanceof Promise) {
>>>             console.log("async module", key, await value)
>>>           } else {
>>>             console.log("sync module", key, value);
>>>           }
>>>         }
>>>       })(Object.entries(o));
>>>     </script>
>>> ```
>>>
>>> Still there is no actual problem statement. Rather, there is conjecture
>>> without a definitive issue to solve.
>>>
>>>
>>>
>>>
>>> On Sun, Jun 2, 2019 at 3:54 AM kai zhu <kaizhu256 at gmail.com> wrote:
>>>
>>>> i apologize for poor framing of my questions.  they are still
>>>> formative, but i can clarify abit as follows:
>>>>
>>>> 1) original-question - is native es-module's async-behavior desirable?
>>>> async side-effects are difficult to manage -- i conjecture that
>>>> async-loading 20 es-modules (with dependent side-effects) is not practical
>>>> for most mortals to handle.
>>>> @frederick describes the mechanism for how to hint the brower to
>>>> pre-fetch 20 es-modules. but if you pre-fetch, then is loading-behavior
>>>> effectively synchronous?
>>>> @isiah says he has experience loading 50-100 modules, but was unclear
>>>> whether they were individual [async] ```<script type="module">```
>>>> tags, or some es5-transpiled rollup.
>>>>
>>>> i may be wrong about everything, as i'm a bit ignorant on what async
>>>> actually means in es-modules (and appreciate it, if someone can clarify
>>>> that).
>>>>
>>>>
>>>>
>>>> 2) the second-question about es-module rollups (which you and i are
>>>> debating) stemmed from @isiah's response -- if he and everyone-else use
>>>> es5-transpiled rollups (which i suspect), then shouldn't it be desirable
>>>> for es-modules to natively support rollups as well?  currently, there's no
>>>> way to natively rollup multiple es-modules into a single bundle.
>>>>
>>>> this 2nd question also has implications about es-module's
>>>> async-behavior (because rollups "load" modules in sync/blocking fashion).
>>>> this could change side-effect behaviors between development-mode (20
>>>> [async] ```<script type="module">``` tags) and production-mode (1
>>>> rollup-bundle).  again, i may be wrong about that, as i'm ignorant about
>>>> what async actually is in es-modules.
>>>>
>>>> -kai
>>>>
>>>> On Sat, Jun 1, 2019 at 9:22 PM guest271314 <guest271314 at gmail.com>
>>>> wrote:
>>>>
>>>>> > it doesn't actually ```import``` 1000+ es-modules inside the
>>>>> rollup-file. it just creates one es-module that exports a dictionary -- and
>>>>> assigns the dictionary 1000+ vanilla json-objects and functions.
>>>>>
>>>>> The code provides a means to fetch N resources and export those
>>>>> resources within a single object.
>>>>>
>>>>> > currently, as i'm aware, nobody uses native es-modules in
>>>>> production, because it cannot be rolled-up.
>>>>> > in practice es-modules are [babel] transpiled down to es5-amd (or
>>>>> similar) for rollup-purposes.
>>>>> >
>>>>> > if we're actually committed to native es-modules, then we either
>>>>> > 1) need to depend on embedders like loading-dev at chromium.org to
>>>>> create sophisticated cache-systems, or
>>>>> > 2) introduce new language-syntax to delimit es-modules for
>>>>> rollup-purposes, e.g.
>>>>>
>>>>> You still have not clearly defined what you mean by "rolled-up". That
>>>>> language appears to be a random nickname, not any immutable principle that
>>>>> individuals are bound to recognize or observe (even if "rolled-up" were
>>>>> some form of a coding style or standard).
>>>>>
>>>>> Nor is it clear what you mean by "production".
>>>>>
>>>>> There is no external central committee that stamps code as
>>>>> "production". Even if there were no individual is obliged to submit to such
>>>>> a procedure nor have any concern for such an arbitrary and irrelevant
>>>>> presumptive review of code.
>>>>>
>>>>> The only observable points are input and output. In general, how
>>>>> output is achieved is immaterial. If there are specific restrictions as to
>>>>> how the output can be achieved then those restrictions need to be clearly
>>>>> defined.
>>>>>
>>>>>
>>>>>
>>>>> The original post asked "how many async-modules can js-app practically
>>>>> load?" and mentioned "circular-references" (the thread appears to
>>>>> mainly be about one or more coding styles, not code itself) though as yet
>>>>> no code has been posted which demonstrates "circular-references" or any
>>>>> other coding problem.
>>>>>
>>>>> On Sun, Jun 2, 2019 at 1:30 AM kai zhu <kaizhu256 at gmail.com> wrote:
>>>>>
>>>>>> i played around with your code in jsfiddle [1], and understand it a
>>>>>> little more.
>>>>>> it doesn't actually ```import``` 1000+ es-modules inside the
>>>>>> rollup-file.
>>>>>> it just creates one es-module that exports a dictionary
>>>>>>  -- and assigns the dictionary 1000+ vanilla json-objects and
>>>>>> functions.
>>>>>>
>>>>>> ```js
>>>>>> // the "rollup-file" is a single es-module
>>>>>> // that exports 1000+ vanilla dictionary-entries
>>>>>> const modules = {};
>>>>>>
>>>>>> // this is not a es-module, nor is it rolled-up (external fetch)
>>>>>> modules.image = <await fetch json from gist.github.com>
>>>>>>
>>>>>> // this is not a [rolled-up] es-module
>>>>>> modules.fn = function () {...}
>>>>>>
>>>>>> // these are not [rolled-up] es-modules
>>>>>> Object.assign(modules, <1000 json-entries>)
>>>>>>
>>>>>> export {modules}
>>>>>> ```
>>>>>>
>>>>>> currently, as i'm aware, nobody uses native es-modules in production,
>>>>>> because it cannot be rolled-up.
>>>>>> in practice es-modules are [babel] transpiled down to es5-amd (or
>>>>>> similar) for rollup-purposes.
>>>>>>
>>>>>> if we're actually committed to native es-modules, then we either
>>>>>> 1) need to depend on embedders like loading-dev at chromium.org to
>>>>>> create sophisticated cache-systems, or
>>>>>> 2) introduce new language-syntax to delimit es-modules for
>>>>>> rollup-purposes, e.g.
>>>>>>
>>>>>> ```js
>>>>>> // rollup.js with [hypothetical] # delimited es-modules
>>>>>> # module aa
>>>>>> import {bb} as bb;
>>>>>> export ...;
>>>>>>
>>>>>> # module bb
>>>>>> export ...;
>>>>>> ```
>>>>>>
>>>>>> i'm generally skeptical of option 1, given how poorly npmjs.com has
>>>>>> handled similar problems deduplicating children in node_modules/ directory.
>>>>>>
>>>>>> [1] jsfiddle pseudo-module rollup
>>>>>> https://jsfiddle.net/06twrLfd/
>>>>>>
>>>>>> On Sat, Jun 1, 2019 at 5:30 PM guest271314 <guest271314 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> > your rollup solution is interesting,
>>>>>>>
>>>>>>> What  is "rollup" referring to?
>>>>>>>
>>>>>>> > but i get an error when run in chrome (i changed to n=20 to
>>>>>>> prevent name-collision, but it still happens).
>>>>>>>
>>>>>>> The duplicate ("collision") entry an ```try..catch``` block is
>>>>>>> included in the code to demonstrate given an array of module names to be
>>>>>>> exported and imported as identifiers 1) duplicate entries can be filtered;
>>>>>>> 2) if a plain object is exported duplicate identifiers ("collision") is not
>>>>>>> possible as a JavaScript plain object does not have duplicate property
>>>>>>> names ("collision"); if there is an issue with identifiers in a module the
>>>>>>> cause would not be the number of async-modules loaded ("how many"), but the
>>>>>>> naming of the identifiers within the code, using or not using ```const```
>>>>>>> or ```let```. Still not sure what the actual issue is?
>>>>>>>
>>>>>>> > don't completely understand how it works,
>>>>>>>
>>>>>>> Use an ```async``` function to fetch data, check for the described
>>>>>>> "collision" , create a ```data URI``` to be imported, optionally, append
>>>>>>> addition code to be executed within the ```<script type="module">```.
>>>>>>>
>>>>>>> > but not sure of suitability for production-use, because of its
>>>>>>> dynamic <script> tag generation.
>>>>>>>
>>>>>>> What is the issue with dynamic ```<script>``` tag generation?
>>>>>>>
>>>>>>> There is more than one possible approach to achieve the presumptive
>>>>>>> requirement, that is still not clear to the exclusion of what is not the
>>>>>>> expected result.
>>>>>>>
>>>>>>> There were no restrictions described at the OP and following
>>>>>>> messages other than other than
>>>>>>>
>>>>>>> > pure-es6 application with 20 es-modules rolled-up into one
>>>>>>> [production] bundle?
>>>>>>>
>>>>>>> The example code uses only JavaScript implementation shipped with
>>>>>>> the browser without any external, third-party libraries.
>>>>>>>
>>>>>>> What standard or definition are you relying for the meaning of the
>>>>>>> term "production-use"? What procedure are you using to determine if code is
>>>>>>> "production-use" "suitable"? How is that procedure related to "how many
>>>>>>> async-modules can js-app practically load?"?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jun 1, 2019 at 9:42 PM kai zhu <kaizhu256 at gmail.com> wrote:
>>>>>>>
>>>>>>>> your rollup solution is interesting, but i get an error when run in
>>>>>>>> chrome (i changed to n=20 to prevent name-collision, but it still
>>>>>>>> happens).  don't completely understand how it works, but not sure of
>>>>>>>> suitability for production-use, because of its dynamic <script> tag
>>>>>>>> generation.
>>>>>>>>
>>>>>>>> ```console
>>>>>>>> ReferenceError: module names ["yeqjqb02mvg3yze26rc5"] are not unique
>>>>>>>>     at
>>>>>>>> data:application/javascript,%0A%20%20%20%20%20%20const%20modules...
>>>>>>>> ```
>>>>>>>>
>>>>>>>> On Sat, Jun 1, 2019 at 2:33 PM guest271314 <guest271314 at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Re: how many async-modules can js-app practically load?
>>>>>>>>>
>>>>>>>>> An example of exporting and importing loading 1000 properties in a
>>>>>>>>> single module, where duplicate property names are checked for. Since
>>>>>>>>> JavaScript plain objects cannot have duplicate property names there should
>>>>>>>>> not be any "collisions"; the code can check for and modify the object to be
>>>>>>>>> exported, though the last duplicate property name will be exported without
>>>>>>>>> any errors thrown unless the code is composed to throw such an error.
>>>>>>>>>
>>>>>>>>> ```
>>>>>>>>>   (async() => {
>>>>>>>>>     const oneThousandModules = encodeURIComponent(
>>>>>>>>>       // substitute rand for a Set of module names to be exported
>>>>>>>>>       // e.g. const moduleNames = ['moduleA', 'moduleB',
>>>>>>>>> ...moduleZ]
>>>>>>>>>       `
>>>>>>>>>       const modules = {};
>>>>>>>>>       // set a function to be exported
>>>>>>>>>       modules.fn = function() {return 'a function'};
>>>>>>>>>       // function to set (1000) 'random' module names to be
>>>>>>>>> exported
>>>>>>>>>       const rand = (seed = 'abcdefghijklmnopqrstuvwxyz0123456789',
>>>>>>>>> n = 5, len = seed.length) =>
>>>>>>>>>         '.'.repeat(n).replace(/./g, _ => seed[~~(Math.random() *
>>>>>>>>> len)]);
>>>>>>>>>         // use Set for unique module identifiers
>>>>>>>>>         const moduleNames = [...Array(1000)].map(_ => rand());
>>>>>>>>>         const moduleIdentifiers = new Set(moduleNames);
>>>>>>>>>         // below line will cause ReferenceError to be thrown
>>>>>>>>>         moduleNames.push(moduleNames[0]);
>>>>>>>>>         try {
>>>>>>>>>           if (moduleIdentifiers.size !== moduleNames.length) {
>>>>>>>>>             // check for duplicates
>>>>>>>>>             const duplicates = moduleNames.filter((moduleName,
>>>>>>>>> index) => moduleNames.indexOf(moduleName) !== index);
>>>>>>>>>             // notification of duplicate module names
>>>>>>>>>             throw new ReferenceError('module names ' +
>>>>>>>>> JSON.stringify(duplicates) + ' are not unique');
>>>>>>>>>             // perform the designated task if duplicate module
>>>>>>>>> names are found here
>>>>>>>>>           }
>>>>>>>>>         } catch (e) {
>>>>>>>>>           console.error(e);
>>>>>>>>>           console.trace();
>>>>>>>>>         }
>>>>>>>>>         // get, set (sync or async) exported module here
>>>>>>>>>         Object.assign(modules, ...[...moduleIdentifiers].map((id,
>>>>>>>>> value) => ({[id]:value})));
>>>>>>>>>         // since JavaScript plain object cannot have duplicate
>>>>>>>>> property names
>>>>>>>>>         // modules object will still be exported without duplicate
>>>>>>>>> property names
>>>>>>>>>         // without collisions
>>>>>>>>>         export {modules}
>>>>>>>>>     `);
>>>>>>>>>     const scriptText = `import {modules} from
>>>>>>>>> "data:application/javascript,${oneThousandModules};${encodeURIComponent('console.log(modules);for
>>>>>>>>> (const key in modules) {if (typeof modules[key] === \'function\')
>>>>>>>>> {console.log(modules[key]());}}')}"`;
>>>>>>>>>     const script = document.createElement("script");
>>>>>>>>>     script.type = "module";
>>>>>>>>>     script.textContent = scriptText;
>>>>>>>>>     document.head.appendChild(script);
>>>>>>>>>   })();
>>>>>>>>> ```
>>>>>>>>>
>>>>>>>>> plnkr https://plnkr.co/edit/CgEhBY?p=preview
>>>>>>>>>
>>>>>>>>> On Sat, Jun 1, 2019 at 1:51 AM kai zhu <kaizhu256 at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> > Place all of the code to be exported in 1 file?
>>>>>>>>>>
>>>>>>>>>> that obviously will not work, because of module-scope collision.
>>>>>>>>>> can anyone share their experience on deploying a [babel-free] pure-es6
>>>>>>>>>> application with 20 es-modules rolled-up into one [production] bundle?  is
>>>>>>>>>> it even possible?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, May 31, 2019 at 7:55 PM guest271314 <
>>>>>>>>>> guest271314 at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> > how would i transition from development-mode (20 es-module
>>>>>>>>>>> files) -> production-mode (1 rollup file)?
>>>>>>>>>>>
>>>>>>>>>>> Place all of the code to be exported in 1 file?
>>>>>>>>>>>
>>>>>>>>>>> > with some of them having circular-references
>>>>>>>>>>>
>>>>>>>>>>> Not certain how that is possible when using ```import``` within
>>>>>>>>>>> ```<script type="module">```?
>>>>>>>>>>>
>>>>>>>>>>> > how many async-modules can js-app practically load?
>>>>>>>>>>>
>>>>>>>>>>> Again, how many have you tried to load? 100? 500? 1000? Either
>>>>>>>>>>> should be possible.
>>>>>>>>>>>
>>>>>>>>>>> What specific issue are you actually to resolve?
>>>>>>>>>>>
>>>>>>>>>>> On Fri, May 31, 2019 at 5:40 PM kai zhu <kaizhu256 at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> > Oh, and yes, I've loaded upwards of 50-100 modules in
>>>>>>>>>>>> development. 20
>>>>>>>>>>>> modules is *easy* to achieve in single-page apps.
>>>>>>>>>>>>
>>>>>>>>>>>> was that with some combination of babel/rollup/webpack or
>>>>>>>>>>>> pure-es6?
>>>>>>>>>>>> if i want to develop a pure-es6 webapp (no babel), how would i
>>>>>>>>>>>> transition from development-mode (20 es-module files) -> production-mode (1
>>>>>>>>>>>> rollup file)?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, May 31, 2019 at 10:47 AM Isiah Meadows <
>>>>>>>>>>>> isiahmeadows at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> If it's bundled by Rollup or Webpack into a single bundle, it's
>>>>>>>>>>>>> equivalent to a single `<script type="module" src="...">`
>>>>>>>>>>>>> pointing
>>>>>>>>>>>>> towards the original entry point, excluding network requests.*
>>>>>>>>>>>>> But in
>>>>>>>>>>>>> either case, you aren't listing 50 scripts, you're only
>>>>>>>>>>>>> listing the
>>>>>>>>>>>>> entry module and importing child modules within parent
>>>>>>>>>>>>> modules. Rollup
>>>>>>>>>>>>> and Webpack do mostly the same thing browsers do when it comes
>>>>>>>>>>>>> to
>>>>>>>>>>>>> resolving dependencies, just they generate a bundle afterwards
>>>>>>>>>>>>> where
>>>>>>>>>>>>> browsers execute code afterwards. Also, it's worth noting that
>>>>>>>>>>>>> the gap
>>>>>>>>>>>>> between a single large request and multiple smaller requests
>>>>>>>>>>>>> has
>>>>>>>>>>>>> shrunk a lot since HTTP/2 came along, since it's binary, it
>>>>>>>>>>>>> allows
>>>>>>>>>>>>> requests and response data to be interleaved, it better
>>>>>>>>>>>>> leverages the
>>>>>>>>>>>>> underlying TCP protocol format, and it allows servers to send
>>>>>>>>>>>>> data
>>>>>>>>>>>>> pre-emptively without the client requesting it first. (Web
>>>>>>>>>>>>> sockets are
>>>>>>>>>>>>> built on this functionality.) It's still better to bundle in
>>>>>>>>>>>>> general,
>>>>>>>>>>>>> but it's less of a problem not to.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is *not* the case for `<script type="module">` elements -
>>>>>>>>>>>>> those
>>>>>>>>>>>>> operate more like inline scripts that happen to have the
>>>>>>>>>>>>> ability to
>>>>>>>>>>>>> `import`.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Oh, and yes, I've loaded upwards of 50-100 modules in
>>>>>>>>>>>>> development. 20
>>>>>>>>>>>>> modules is *easy* to achieve in single-page apps.
>>>>>>>>>>>>>
>>>>>>>>>>>>> * This is, of course, not the case if you are using pure ES6
>>>>>>>>>>>>> and you
>>>>>>>>>>>>> aren't using any plugins to, say, run the original source
>>>>>>>>>>>>> through
>>>>>>>>>>>>> Babel for React + JSX or something.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>> Isiah Meadows
>>>>>>>>>>>>> contact at isiahmeadows.com
>>>>>>>>>>>>> www.isiahmeadows.com
>>>>>>>>>>>>> On Sat, May 25, 2019 at 2:12 AM kai zhu <kaizhu256 at gmail.com>
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> isiahmeadows at gmail.com> 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
>>>>>>>>>>>>> > contact at isiahmeadows.com
>>>>>>>>>>>>> > www.isiahmeadows.com
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > On Thu, May 23, 2019 at 10:49 AM kai zhu <
>>>>>>>>>>>>> kaizhu256 at gmail.com> 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 <
>>>>>>>>>>>>> loganfsmyth at gmail.com> 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 <kaizhu256 at gmail.com>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> > es-discuss at mozilla.org
>>>>>>>>>>>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>>>> > es-discuss mailing list
>>>>>>>>>>>>> > es-discuss at mozilla.org
>>>>>>>>>>>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> es-discuss mailing list
>>>>>>>>>>>> es-discuss at mozilla.org
>>>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>>>>
>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190602/f08cddbd/attachment-0001.html>


More information about the es-discuss mailing list