guest271314 at gmail.com (2019-06-03T01:51:53.261Z)
One option would be 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";
const bar1 = { baz: foo1 };
export { bar1 };
import { foo as foo2 } from "./bb.js";
const bar2 = { baz: foo2 };
export { bar2 };
```
```
(async() => {
const {...bars} = await import("./inline.js");
console.log(bars);
})();
```guest271314 at gmail.com (2019-06-03T01:42:11.607Z)
One option would be 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 };
```
```
(async() => {
const {...bars} = await import("./inline.js");
console.log(bars);
})();
```guest271314 at gmail.com (2019-06-03T01:41:38.538Z)
One option would be 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 };
```
```
(async() => {
const {...bars} = await import("./script.js");
console.log(bars);
})();
```guest271314 at gmail.com (2019-06-03T01:34:15.273Z)
One option would be 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 };
```guest271314 at gmail.com (2019-06-03T01:33:48.239Z)
One option would be 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 };
```
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/f6113d23/attachment-0001.html>