Modules: Curly Free

David Herman dherman at
Sat Apr 20 19:15:16 PDT 2013

On Apr 20, 2013, at 5:17 AM, Brendan Eich <brendan at> wrote:

> Andreas Rossberg wrote:
>> I don't understand. Are you saying that it has a higher cost to
>> standardize a trivial convention than it is to standardize additional
>> ad-hoc syntax?
> Answering for Dave: you bet it is.
> The cost of the former is born by everyone in a large-N community who must learn the "trivial convention". The cost of the latter is born by we few TC39ers and JS implementors, who can make that sacrifice.
> Recall Mr. Spock's Kobayashi Maru solution from STII:TWoK.

Thanks, and let me also add the following points:

"Standardize additional ad-hoc syntax" is seriously hyperbolic. Anonymous export is simply about allowing library authors to indicate a module's main entry point. Semantically, we're talking about the difference between a string and a symbol; syntactically, we're talking about one production. It's all cleanly layered on top of the rest of the system. Let's keep some perspective.

Moreover, "ad-hoc" seems to suggest some sort of arbitrariness, as if it's not well-motivated. It is in fact well-motivated, by a real requirement that otherwise requires a manual design pattern -- on the part of both the creators *and* the clients of libraries, note well! In fact, I've seen the design pattern arise in practice in other languages. And yet in existing JS module systems, no such pattern is required of a library's clients. (The clients are of course the important case. Yet another instance of the applicability of Mr. Spock's solution!)

I am constantly, repeatedly met with impassioned requests [*] for anonymous export support by JS developers of multiple communities, e.g., NPM and AMD users alike. Do we wish to just ignore them? Do we favor minor convenience of engine implementors over the readability and clarity of every client of large numbers of idiomatic JavaScript modules?


[*] G-rated version of the story.

More information about the es-discuss mailing list