Modules: Curly Free

Andreas Rossberg rossberg at
Mon Apr 22 06:48:38 PDT 2013

On 22 April 2013 15:27, Quildreen Motta <quildreen at> wrote:
> On 22 April 2013 09:18, Andreas Rossberg <rossberg at> wrote:
>> On 21 April 2013 04:15, David Herman <dherman at> wrote:
>> > On Apr 20, 2013, at 5:17 AM, Brendan Eich <brendan at> wrote:
>> >
>> > 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'm sorry, but I'm afraid this is one of these moments where I have no
>> idea what the heck you guys are talking about. ;)  It is a trivial
>> naming convention, for a single identifier! How is a single name
>> possibly more difficult to learn or remember than any additional piece
>> of syntax, however simple that may be? And how is calling it a "manual
>> design pattern" less hyperbolic?
> The fact that explicitly naming things in your modules requires the user to
> know the internal structure of the module they're dealing with when that
> isn't exactly necessary adds some complexity (or a "manual design pattern").
> Patterns are nasty, patterns are eugh.

Just to be clear, what I suggested was having a single global
convention for the name of the 'anonymous' export in every module, say
,"it". No need to know the "internals" of anything. Your Node example,

> var json_request = require('json-request-middleware')
> var json_output = require('json-output-middleware')

would e.g. become

import it as json_request from 'json-request-middleware'
import it as json_output from 'json-output-middleware'

(and similarly, on the export side).

> The second use case would be encoding parametric modules by a single
> function exports. In this case, you need to unwrap the module anyways before
> you can use it, because it depends on external stuff that you as the client
> have to provide. Again, this maps rather straight-forwardly to first-class
> modules in CommonJS.
> var dom = require('dom')(cssSelector, eventBridge)
> dom.query('.foo').on('click', function(ev) { /* event is sanitised here by
> the eventBridge library */ })
> This doesn't map that well to current ES modules because they're second
> class (unless I've been so out of the loop that I've missed they being
> promoted):
> import dom as domFactory
> var dom = domFactory(cssSelector, eventBridge)

In the syntax Dave proposed that would actually be:

import default domFactory from dom
var dom = domFactory(cssSelector, eventBridge)

Is that so notably better than

import it as domFactory from dom
var dom = domFactory(cssSelector, eventBridge)

to be worth adding the new syntax? (And semantics, I presume, because
Dave hasn't actually told us how the "anonymous" export would be
distinguished internally.)


More information about the es-discuss mailing list