how many async-modules can js-app practically load?
kaizhu256 at gmail.com
Mon Jun 3 04:12:42 UTC 2019
you would need to introduce a new language-syntax that hints delimited
* 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
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 gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss