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

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Logan Smyth
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Isiah Meadows-2
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
[hidden email]
www.isiahmeadows.com

On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com

On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

guest271314
> so async-loading 50 ```<script type="module">``` tags has equivalent side-effect
as sync-loading single webpack-rollup (of same 50 modules)?

Why would 50 separate ```<script type="module">``` tags be needed?

> has anyone tried native async-loading large numbers (>10) of ```<script type="module">``` tags, and verify it resolves identically to using a single webpack-rollup?

Have you tried the two described approaches and compared the result?

How is "identically" determined?

On Sat, May 25, 2019 at 6:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com

On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
Why would 50 separate ```<script type="module">``` tags be needed?

because a reason for es-module's existence in the first place is to bring "large-scale modular development" to the browser.  i want to test that claim (hence this thread's subject-title).

Have you tried the two described approaches and compared the result? How is "identically" determined?

no i haven't, and i suspect nobody does in practice, because they all use babel/webpack.  identicality would be determined by if the app functions the same regardless whether you used a webpack-rollup or individual ```<script type="module">``` tags.

-kai



On 25 May 2019, at 01:20, guest271314 <[hidden email]> wrote:

> so async-loading 50 ```<script type="module">``` tags has equivalent side-effect
as sync-loading single webpack-rollup (of same 50 modules)?

Why would 50 separate ```<script type="module">``` tags be needed?

> has anyone tried native async-loading large numbers (>10) of ```<script type="module">``` tags, and verify it resolves identically to using a single webpack-rollup?

Have you tried the two described approaches and compared the result?

How is "identically" determined?

On Sat, May 25, 2019 at 6:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com

On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

guest271314
Have not tried babel or webpack. You can write the test to answer your own inquiry and post the result at a gist.

On Sat, May 25, 2019 at 6:34 AM kai zhu <[hidden email]> wrote:
Why would 50 separate ```<script type="module">``` tags be needed?

because a reason for es-module's existence in the first place is to bring "large-scale modular development" to the browser.  i want to test that claim (hence this thread's subject-title).

Have you tried the two described approaches and compared the result? How is "identically" determined?

no i haven't, and i suspect nobody does in practice, because they all use babel/webpack.  identicality would be determined by if the app functions the same regardless whether you used a webpack-rollup or individual ```<script type="module">``` tags.

-kai



On 25 May 2019, at 01:20, guest271314 <[hidden email]> wrote:

> so async-loading 50 ```<script type="module">``` tags has equivalent side-effect
as sync-loading single webpack-rollup (of same 50 modules)?

Why would 50 separate ```<script type="module">``` tags be needed?

> has anyone tried native async-loading large numbers (>10) of ```<script type="module">``` tags, and verify it resolves identically to using a single webpack-rollup?

Have you tried the two described approaches and compared the result?

How is "identically" determined?

On Sat, May 25, 2019 at 6:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com

On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Wes Garland
If you come up with a benchmark for this, would you mind sharing the code and not just the results?  I'm curious how my stuff will fare.

I'm in an environment where it is still not practical to use ES modules, and have started work again on BravoJS, which implements the old CommonJS Modules/2.0 strawman. (Same primordial development soup as AMD, but with a different set of flaws; favouring correctness/compatibility instead of brevity)

How I've solved this problem historically is to have some smarts on the server side, that feeds (transitive) dependencies of a module at the same time as the module.  It will be interesting to play with that type of loader -- if possible -- once ES module loaders become well-defined/implemented/available.

We also have to remember that loading via SCRIPT tags -- type=module or not -- is important to developers, so that we can load modules from CDNs and so on without cross-site security pain.

Thanks,
Wes

On Sat, 25 May 2019 at 02:41, guest271314 <[hidden email]> wrote:
Have not tried babel or webpack. You can write the test to answer your own inquiry and post the result at a gist.

On Sat, May 25, 2019 at 6:34 AM kai zhu <[hidden email]> wrote:
Why would 50 separate ```<script type="module">``` tags be needed?

because a reason for es-module's existence in the first place is to bring "large-scale modular development" to the browser.  i want to test that claim (hence this thread's subject-title).

Have you tried the two described approaches and compared the result? How is "identically" determined?

no i haven't, and i suspect nobody does in practice, because they all use babel/webpack.  identicality would be determined by if the app functions the same regardless whether you used a webpack-rollup or individual ```<script type="module">``` tags.

-kai



On 25 May 2019, at 01:20, guest271314 <[hidden email]> wrote:

> so async-loading 50 ```<script type="module">``` tags has equivalent side-effect
as sync-loading single webpack-rollup (of same 50 modules)?

Why would 50 separate ```<script type="module">``` tags be needed?

> has anyone tried native async-loading large numbers (>10) of ```<script type="module">``` tags, and verify it resolves identically to using a single webpack-rollup?

Have you tried the two described approaches and compared the result?

How is "identically" determined?

On Sat, May 25, 2019 at 6:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com

On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

guest271314
> If you come up with a benchmark for this, would you mind sharing the code and not just the results?  I'm curious how my stuff will fare.

What specifically should be compared? What are you trying to determine?

The current question asks 

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

which leads to asking how many async-modules are actually needed?

From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules, similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used; e.g., see How to solve Uncaught RangeError when download large size json
 https://stackoverflow.com/q/39959467 where the result is can be vary vastly when using devices having different available RAM and hard-disk space. 

Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.

On Sat, May 25, 2019 at 7:57 PM Wes Garland <[hidden email]> wrote:
If you come up with a benchmark for this, would you mind sharing the code and not just the results?  I'm curious how my stuff will fare.

I'm in an environment where it is still not practical to use ES modules, and have started work again on BravoJS, which implements the old CommonJS Modules/2.0 strawman. (Same primordial development soup as AMD, but with a different set of flaws; favouring correctness/compatibility instead of brevity)

How I've solved this problem historically is to have some smarts on the server side, that feeds (transitive) dependencies of a module at the same time as the module.  It will be interesting to play with that type of loader -- if possible -- once ES module loaders become well-defined/implemented/available.

We also have to remember that loading via SCRIPT tags -- type=module or not -- is important to developers, so that we can load modules from CDNs and so on without cross-site security pain.

Thanks,
Wes

On Sat, 25 May 2019 at 02:41, guest271314 <[hidden email]> wrote:
Have not tried babel or webpack. You can write the test to answer your own inquiry and post the result at a gist.

On Sat, May 25, 2019 at 6:34 AM kai zhu <[hidden email]> wrote:
Why would 50 separate ```<script type="module">``` tags be needed?

because a reason for es-module's existence in the first place is to bring "large-scale modular development" to the browser.  i want to test that claim (hence this thread's subject-title).

Have you tried the two described approaches and compared the result? How is "identically" determined?

no i haven't, and i suspect nobody does in practice, because they all use babel/webpack.  identicality would be determined by if the app functions the same regardless whether you used a webpack-rollup or individual ```<script type="module">``` tags.

-kai



On 25 May 2019, at 01:20, guest271314 <[hidden email]> wrote:

> so async-loading 50 ```<script type="module">``` tags has equivalent side-effect
as sync-loading single webpack-rollup (of same 50 modules)?

Why would 50 separate ```<script type="module">``` tags be needed?

> has anyone tried native async-loading large numbers (>10) of ```<script type="module">``` tags, and verify it resolves identically to using a single webpack-rollup?

Have you tried the two described approaches and compared the result?

How is "identically" determined?

On Sat, May 25, 2019 at 6:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com

On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Frederick Stark
Pretty sure your issue here is the multiple <script type="module"> tags.

In an ES module environment, you're supposed to set one entry point (with one script type module tag). Then use import statements to load in the other modules. The from string should be a URI that the browser can load modules from.

To make this async, you would use the dynamic import( ... ) function syntax.

Currently this has the issue that the browser has to parse each file to find and fetch it's dependencies.

There's a couple of proposals to address this. Currently, in chromium based browsers, you can add module preload links in the header like so:
<link rel="modulepreload" href="lib.mjs">
<link rel="modulepreload" href="main.mjs">
So for your example, you would use one <script type="module"> tag and 50 <link rel="modulepreload"> tags.
"modulepreload" has been added to the HTML standard, but is not implemented everywhere.

There's also the import maps proposal https://github.com/WICG/import-maps which would use a single manifest file to hint the dependency map to the browser instead of a stack of tags. It also contains a method for recognising package names, so,  like in node, you can import from a package name instead of from a URL
On May 26 2019, at 8:02 am, guest271314 <[hidden email]> wrote:
> If you come up with a benchmark for this, would you mind sharing the code and not just the results?  I'm curious how my stuff will fare.

What specifically should be compared? What are you trying to determine?

The current question asks 

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

which leads to asking how many async-modules are actually needed?

From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules, similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used; e.g., see How to solve Uncaught RangeError when download large size json
 https://stackoverflow.com/q/39959467 where the result is can be vary vastly when using devices having different available RAM and hard-disk space. 

Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.

On Sat, May 25, 2019 at 7:57 PM Wes Garland <[hidden email]> wrote:
If you come up with a benchmark for this, would you mind sharing the code and not just the results?  I'm curious how my stuff will fare.

I'm in an environment where it is still not practical to use ES modules, and have started work again on BravoJS, which implements the old CommonJS Modules/2.0 strawman. (Same primordial development soup as AMD, but with a different set of flaws; favouring correctness/compatibility instead of brevity)

How I've solved this problem historically is to have some smarts on the server side, that feeds (transitive) dependencies of a module at the same time as the module.  It will be interesting to play with that type of loader -- if possible -- once ES module loaders become well-defined/implemented/available.

We also have to remember that loading via SCRIPT tags -- type=module or not -- is important to developers, so that we can load modules from CDNs and so on without cross-site security pain.

Thanks,
Wes

On Sat, 25 May 2019 at 02:41, guest271314 <[hidden email]> wrote:
Have not tried babel or webpack. You can write the test to answer your own inquiry and post the result at a gist.

On Sat, May 25, 2019 at 6:34 AM kai zhu <[hidden email]> wrote:
Why would 50 separate ```<script type="module">``` tags be needed?

because a reason for es-module's existence in the first place is to bring "large-scale modular development" to the browser.  i want to test that claim (hence this thread's subject-title).

Have you tried the two described approaches and compared the result? How is "identically" determined?

no i haven't, and i suspect nobody does in practice, because they all use babel/webpack.  identicality would be determined by if the app functions the same regardless whether you used a webpack-rollup or individual ```<script type="module">``` tags.

-kai



On 25 May 2019, at 01:20, guest271314 <[hidden email]> wrote:

> so async-loading 50 ```<script type="module">``` tags has equivalent side-effect
as sync-loading single webpack-rollup (of same 50 modules)?

Why would 50 separate ```<script type="module">``` tags be needed?

> has anyone tried native async-loading large numbers (>10) of ```<script type="module">``` tags, and verify it resolves identically to using a single webpack-rollup?

Have you tried the two described approaches and compared the result?

How is "identically" determined?

On Sat, May 25, 2019 at 6:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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:
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

On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 mailing list

_______________________________________________
es-discuss mailing list

_______________________________________________
es-discuss mailing list


--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
_______________________________________________
es-discuss mailing list
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Isiah Meadows-2
In reply to this post by kai zhu
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
[hidden email]
www.isiahmeadows.com
On Sat, May 25, 2019 at 2:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> www.isiahmeadows.com
>
> On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com
On Sat, May 25, 2019 at 2:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> www.isiahmeadows.com
>
> On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

guest271314
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com
On Sat, May 25, 2019 at 2:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> www.isiahmeadows.com
>
> On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com
On Sat, May 25, 2019 at 2:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> www.isiahmeadows.com
>
> On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

guest271314
Where identifiers have unique names there should not be any collisions. What is the actual code tried?

On Sat, Jun 1, 2019 at 1:51 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com
On Sat, May 25, 2019 at 2:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> www.isiahmeadows.com
>
> On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

guest271314
In reply to this post by kai zhu
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);
  })();
```


On Sat, Jun 1, 2019 at 1:51 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com
On Sat, May 25, 2019 at 2:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> www.isiahmeadows.com
>
> On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
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 <[hidden email]> 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);
  })();
```


On Sat, Jun 1, 2019 at 1:51 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com
On Sat, May 25, 2019 at 2:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> www.isiahmeadows.com
>
> On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

guest271314
> 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 <[hidden email]> 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 <[hidden email]> 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);
  })();
```


On Sat, Jun 1, 2019 at 1:51 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com
On Sat, May 25, 2019 at 2:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> www.isiahmeadows.com
>
> On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
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 [hidden email] 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

On Sat, Jun 1, 2019 at 5:30 PM guest271314 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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);
  })();
```


On Sat, Jun 1, 2019 at 1:51 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com
On Sat, May 25, 2019 at 2:12 AM kai zhu <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> www.isiahmeadows.com
>
> On Thu, May 23, 2019 at 10:49 AM kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12