May 21, 22, 23 TC39 Meeting Notes

Andreas Rossberg rossberg at
Tue Jun 4 03:36:55 PDT 2013

On 4 June 2013 00:31, Brendan Eich <brendan at> wrote:
> Dmitry Soshnikov wrote:
>> I see. Yeah.. it looks at least weird (even if not lexical, which, yeah --
>> bad, why still ugly string names?), and I agree it could lead to a
>> fundamental mistake since will stick for years until ES7.
> The fundamental mistake would be rejecting the detailed rationale for ES6
> modules, in favor of something more verbose and error prone.
> Lexical modules can be added, but deferring them does not mean the current
> design is "fatally flawed". "Incomplete" I could see, not "fatally flawed".
> And arguing for *only* lexical modules and *requiring* people to register
> them manually after declaring them, one by one, is a user-hostile move that
> TC39 will not agree to.
> So you're left arguing "incomplete", at best.

Yeah, from my point of view, this argument is based on entirely the
wrong premise, namely that manually providing registration names is
both common and good practice. Looking at require.js or node, the
opposite is true: not only do people _not_ normally write named module
definitions, they are in fact explicitly _discouraged_ from doing so.
The recommended practice is to put modules in files and have named
module definitions only as the result of invoking a _tool_, like the
optimizer of require.js.

The natural syntax of ES6 module declarations, on the other hand, will
probably _encourage_ people to use these declarations, and make them
believe that they are the best way to structure application. If you
ask me, that's a fundamental flaw. The only places where you really
want to manually use explicit module declarations is for local
modules, and those are exactly the cases where you really want lexical
naming and no global namespace pollution.

That said, there clearly needs to be a way for tools (and humans, if
they desire) to create module bundles and register the modules defined
in those. But designing the whole language around an optimized syntax
for the latter and compromising good PL principles for it still seems
backwards to me. And yes, fundamentally flawed. (Not sure anybody said


More information about the es-discuss mailing list