how many async-modules can js-app practically load?
guest271314 at gmail.com
Mon Jun 3 04:50:35 UTC 2019
Thus far each of the prospective edge cases relevant to the proposal have
been technically solved, save for duplicate identifier names and exports
from the same file, which appears to be avoidable.
Have no "faith" in anything, therefore "good" and "bad" preceding "faith"
are as irrelevant as "good" or "bad".
You can use what is available now and write your own language in your spare
(What programming languages have been created by PPCG users?
https://codegolf.meta.stackexchange.com/q/6918) though beware ("Anyone,
from the most clueless amateur to the best cryptographer, can create an
algorithm that he himself can't break." -Schneier, Bruce (1998-10-15). Memo
to the Amateur Cipher Design
newsletter. (aka Schneier's Law)
On Mon, Jun 3, 2019 at 4:12 AM kai zhu <kaizhu256 at gmail.com> wrote:
> 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
> 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