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

kai zhu kaizhu256 at gmail.com
Sat Jun 1 01:51:06 UTC 2019


> Place all of the code to be exported in 1 file?

that obviously will not work, because of module-scope collision.  can
anyone share their experience on deploying a [babel-free] pure-es6
application with 20 es-modules rolled-up into one [production] bundle?  is
it even possible?


On Fri, May 31, 2019 at 7:55 PM guest271314 <guest271314 at gmail.com> wrote:

> > how would i transition from development-mode (20 es-module files) ->
> production-mode (1 rollup file)?
>
> Place all of the code to be exported in 1 file?
>
> > with some of them having circular-references
>
> Not certain how that is possible when using ```import``` within ```<script
> type="module">```?
>
> > how many async-modules can js-app practically load?
>
> Again, how many have you tried to load? 100? 500? 1000? Either should be
> possible.
>
> What specific issue are you actually to resolve?
>
> On Fri, May 31, 2019 at 5:40 PM kai zhu <kaizhu256 at gmail.com> wrote:
>
>> > Oh, and yes, I've loaded upwards of 50-100 modules in development. 20
>> modules is *easy* to achieve in single-page apps.
>>
>> was that with some combination of babel/rollup/webpack or pure-es6?
>> if i want to develop a pure-es6 webapp (no babel), how would i transition
>> from development-mode (20 es-module files) -> production-mode (1 rollup
>> file)?
>>
>>
>> On Fri, May 31, 2019 at 10:47 AM Isiah Meadows <isiahmeadows at gmail.com>
>> wrote:
>>
>>> If it's bundled by Rollup or Webpack into a single bundle, it's
>>> equivalent to a single `<script type="module" src="...">` pointing
>>> towards the original entry point, excluding network requests.* But in
>>> either case, you aren't listing 50 scripts, you're only listing the
>>> entry module and importing child modules within parent modules. Rollup
>>> and Webpack do mostly the same thing browsers do when it comes to
>>> resolving dependencies, just they generate a bundle afterwards where
>>> browsers execute code afterwards. Also, it's worth noting that the gap
>>> between a single large request and multiple smaller requests has
>>> shrunk a lot since HTTP/2 came along, since it's binary, it allows
>>> requests and response data to be interleaved, it better leverages the
>>> underlying TCP protocol format, and it allows servers to send data
>>> pre-emptively without the client requesting it first. (Web sockets are
>>> built on this functionality.) It's still better to bundle in general,
>>> but it's less of a problem not to.
>>>
>>> This is *not* the case for `<script type="module">` elements - those
>>> operate more like inline scripts that happen to have the ability to
>>> `import`.
>>>
>>> Oh, and yes, I've loaded upwards of 50-100 modules in development. 20
>>> modules is *easy* to achieve in single-page apps.
>>>
>>> * This is, of course, not the case if you are using pure ES6 and you
>>> aren't using any plugins to, say, run the original source through
>>> Babel for React + JSX or something.
>>>
>>> -----
>>>
>>> Isiah Meadows
>>> contact at isiahmeadows.com
>>> www.isiahmeadows.com
>>> On Sat, May 25, 2019 at 2:12 AM kai zhu <kaizhu256 at gmail.com> wrote:
>>> >
>>> > Asynchronous loading differs only in
>>> > that it takes more code to express the same logic and you have to take
>>> > into account concurrent requests (and you need to cache the request,
>>> > not the result), but it's otherwise the same from 1km away.
>>> >
>>> >
>>> > so async-loading 50 ```<script type="module">``` tags
>>> > has equivalent side-effect
>>> > as sync-loading single webpack-rollup (of same 50 modules)?
>>> >
>>> > i have nagging suspicion of doubts.  has anyone tried native
>>> async-loading large numbers (>10) of
>>> > ```<script type="module">``` tags, and verify it resolves identically
>>> to using a single webpack-rollup?
>>> >
>>> > again, i'm not that knowledgeable on es-modules, so above question may
>>> be trivially true, and i'm just not aware.
>>> >
>>> > -kai
>>> >
>>> > On 24 May 2019, at 23:41, Isiah Meadows <isiahmeadows at gmail.com>
>>> wrote:
>>> >
>>> > There's two main reasons why it scales:
>>> >
>>> > 1. Modules are strongly encapsulated while minimizing global pollution.
>>> > 2. The resolution algorithm applies the same logic no matter how many
>>> > modules are loaded.
>>> >
>>> > It's much easier for it to scale when you write the code unaware of
>>> > how many modules you might be loading and unaware of how deep their
>>> > dependency graph is. Fewer assumptions here is key. It's an
>>> > engineering problem, but a relatively simple one.
>>> >
>>> > If you want a short example of how sync module resolution works, you
>>> > can take a look at this little utility I wrote:
>>> > https://github.com/isiahmeadows/simple-require-loader. That doesn't
>>> > asynchronously resolve modules, but it should help explain the process
>>> > from a synchronous standpoint. Asynchronous loading differs only in
>>> > that it takes more code to express the same logic and you have to take
>>> > into account concurrent requests (and you need to cache the request,
>>> > not the result), but it's otherwise the same from 1km away.
>>> >
>>> > -----
>>> >
>>> > Isiah Meadows
>>> > contact at isiahmeadows.com
>>> > www.isiahmeadows.com
>>> >
>>> > On Thu, May 23, 2019 at 10:49 AM kai zhu <kaizhu256 at gmail.com> wrote:
>>> >
>>> >
>>> > actually, i admit i don't know what i'm talking about.  just generally
>>> confused (through ignorance) on how large-scale es-module dependencies
>>> resolve when loaded/imported asynchronously.
>>> >
>>> > On Wed, May 22, 2019 at 10:42 PM Logan Smyth <loganfsmyth at gmail.com>
>>> wrote:
>>> >
>>> >
>>> > Can you elaborate on what loading state you need to keep track of?
>>> What is the bottleneck that you run into? Also to be sure, when you say
>>> async-load, do you mean `import()`?
>>> >
>>> > On Wed, May 22, 2019, 20:17 kai zhu <kaizhu256 at gmail.com> wrote:
>>> >
>>> >
>>> > i don't use es-modules.
>>> > but with amd/requirejs, I start having trouble with
>>> module-initializations in nodejs/browser at ~5 async modules (that may or
>>> may not have circular-references).  10 would be hard, and 20 would be near
>>> inhuman for me.
>>> >
>>> > can we say its somewhat impractical for most applications to load more
>>> than 50 async modules (with some of them having circular-references)?  and
>>> perhaps better design/spec module-loading mechanisms with this usability
>>> concern in mind?
>>> >
>>> > p.s. its also impractical for me to async-load 5 or more modules
>>> without using globalThis to keep track of each module's loading-state.
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>> >
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>> >
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190531/6668dc6a/attachment.html>


More information about the es-discuss mailing list