> 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/20190601/8de8dec1/attachment-0001.html>

> 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? Naming identifiers within exported and imported modules (JavaScript code)?

> 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? Identifiers of exported and imported (code) modules?

> 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?