Rationale for dropping ModuleImport syntax?
johnjbarton at google.com
Mon Jun 9 06:51:40 PDT 2014
If the 'module' form is left out, it can be added later. If the 'module'
form is left in, it can never be removed.
On Mon, Jun 9, 2014 at 6:39 AM, Axel Rauschmayer <axel at rauschma.de> 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
> axel at rauschma.de
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss