Forgot to copy the list...
-------- Message original -------- Sujet: Re: Static Module Resolution Date : Tue, 03 Jul 2012 09:27:50 +0200 De : Aymeric Vitte <[email protected]> Pour : Brendan Eich <[email protected]> Copie à : Kevin Smith <[email protected]> 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). /be
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 ? -- jCore Email : [email protected] Web : www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
