Fwd: Re: Static Module Resolution
vitteaymeric at gmail.com
Tue Jul 3 00:29:06 PDT 2012
Forgot to copy the list...
-------- Message original --------
Sujet: Re: Static Module Resolution
Date : Tue, 03 Jul 2012 09:27:50 +0200
De : Aymeric Vitte <vitteaymeric at gmail.com>
Pour : Brendan Eich <brendan at mozilla.org>
Copie à : Kevin Smith <khs4473 at gmail.com>
Le 02/07/2012 20:09, Brendan Eich a écrit :
> Again, sync loading is anathema in the browser. Any require usage must
> be (1) callback-based, or else (2) based on a preprocessor (if not
> full CPS-transforming compiler).
> In case (1), let's say the underlying system (AMD) uses XHR and eval.
> The March meeting's resolution would throw an early error (early in
> the eval's phase structure, later in the script's phase structure) on
> any import syntax in the eval'ed program.
> In case (2), the require dependency is loaded before runtime, one way
> or another. If the compiler generates ES6, no problem. If it generates
> ES5, also no problem (ES6 -> ES5 compilation entails compiling import
> into something like what require compiles to).
All this is logical, today we have the situation of scripts (sync)
loading scripts (async) which is not really nice to handle, the debate
here was about compatibility between require and import, now what about
normal scripts (ie non modules), why can't we have in the module
proposal (or somewhere) just the possibility to load code and eval it
(in browsers and server side environments) ? ie why should I be obliged
to transform my script into a module and have to maintain both, or more
if I want to insure perfect compatibility ? The question is trivial and
not entirely related to modules or ES but since modules are considered,
why not adding this possibility now ?
Email : avitte at jcore.fr
Web : www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss