On the other hand, we’ll have many pseudo-modules, which is also a barrier against making progress later on.
On Jun 9, 2014, at 15:51 , John Barton <[email protected]> wrote: > If the 'module' form is left out, it can be added later. If the 'module' form > is left in, it can never be removed. > jjb > > > On Mon, Jun 9, 2014 at 6:39 AM, Axel Rauschmayer <[email protected]> wrote: >>> Isn't the problem, though, that default-exporting an object prevents static >>> checking? It feels like an abuse of this feature to me. >> >> We don't have static checking today, so this is no loss to me. > > If I understand ES6 modules correctly, importing a non-exported identifier > gives you a load-time error (that’s what I meant with “static checking”). If > you default-import an object with exports, you only get run-time errors. > > This is more subjective, but what I like about modules is that they lead us > away from objects-as-modules. If default exports, used in this manner, become > popular, that won’t really happen. We’ll have pseudo-modules, used inside a > module system. > >> (And ES6 modules give enough benefits over ES5 ones without static checking >> to still have a chance in the marketplace, e.g. they statically require >> imports being at top-level and string-only, and automatically introduce >> `"use strict"` for you.) > > I agree. I also love tools such as the es6-module-transpiler, which allow us > to move beyond the AMD/CJS schism right now. > > > -- > Dr. Axel Rauschmayer > [email protected] > rauschma.de > > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Dr. Axel Rauschmayer [email protected] rauschma.de
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
