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

guest271314 guest271314 at gmail.com
Mon Jun 3 02:25:23 UTC 2019


> but that requires coordination among modules, which is not always
possible.  the idea is to inline/rollup es-modules that may not have come
from same developers (and whom are unaware their es-modules collide w/
others when rolled-up).

How do you intend to know the names of the identifiers to import without
"coordination" and check for duplicate identifier names and duplicate
exports?

On Mon, Jun 3, 2019 at 2:12 AM kai zhu <kaizhu256 at gmail.com> wrote:

> but that requires coordination among modules, which is not always
> possible.  the idea is to inline/rollup es-modules that may not have come
> from same developers (and whom are unaware their es-modules collide w/
> others when rolled-up).
>
> you should be able to natively transition from development-env (individual
> es-modules) -> production-env (rolled-up es-modules), w/o down-transpiling
> to es5-amdjs.
>
>
>
> On Sun, Jun 2, 2019 at 8:29 PM guest271314 <guest271314 at gmail.com> wrote:
>
>> One option is to utilize ```shortName```
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#Import_an_export_with_a_more_convenient_alias
>>
>> ```
>> import {foo as foo1} from "./aa.js";
>> let bar1 = { baz: foo1 };
>> export { bar1 };
>>
>> import {foo as foo2} from "./bb.js";
>> const bar2 = { baz: foo2 };
>> export { bar2 };
>> ```
>>
>> On Sun, Jun 2, 2019 at 11:05 PM kai zhu <kaizhu256 at gmail.com> wrote:
>>
>>> 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/20190603/d16534af/attachment-0001.html>


More information about the es-discuss mailing list