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

kai zhu kaizhu256 at
Mon Jun 3 04:12:42 UTC 2019

you would need to introduce a new language-syntax that hints delimited
module-scope, e.g.

 * es-module.rollup.js
 * example rolling-up es-modules with [hypothetical] pragma
 * "use module_scope xxx";
 * which would be web-compat and minifier-friendly

"use module_scope ./aa.js";
// foo is scoped inside module_scope ./aa.js
var foo = ...

"use module_scope ./bb.js";
// foo is scoped inside module_scope ./bb.js
var foo = ...

i'll be honest.  i'm not really proposing this language-syntax in
good-faith, as javascript is already chock-full of confusing-features that
are distracting/harmful to UX-workflow programming.

i'm mainly criticizing tc39 for their design-decision pushing through
es-modules, and how disruptive it is to operationalize (natively, w/o
transpiling) in production-systems.  web-development could've stayed
simpler if the committee had done absolutely nothing.  people would've
continued using es5-style rollups (w/ yui/amdjs-like module-loaders), and
devop-folks wouldn't be forced to deal with import-maps and http2-push to
solve a problem that shouldn't have existed.

On Sun, Jun 2, 2019 at 9:25 PM guest271314 <guest271314 at> wrote:

> > but that requires coordination among modules, which is not always
> possible.  the idea is to inline/rollup es-modules that may not have come
> from same developers (and whom are unaware their es-modules collide w/
> others when rolled-up).
> How do you intend to know the names of the identifiers to import without
> "coordination" and check for duplicate identifier names and duplicate
> exports?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list