ES Modules: suggestions for improvement
mikeal.rogers at gmail.com
Wed Jun 27 15:08:37 PDT 2012
On Jun 27, 2012, at June 27, 20121:06 PM, Isaac Schlueter wrote:
>> I just disagree. I think it's fine if you like that style [one module exports one thing], and you can use it. But we shouldn't force it on users.
> I'm having trouble articulating why it is that module.exports=blah is
> better than exports.blah=blah. Surely, you can just choose to only
> put one thing on the exports object, right? It seems obviously better
> to allow the flexibility, and I was strongly in favor of this early in
> node's history.
> However, after using it a lot, I've found that `exports.foo = bar`
> often ends up being more painful than `module.exports = foo`, even
> with the transitive issues. I'm not sure why that is, and "Go write
> couple hundred KLoC of module JS and then you'll get it" is not an
> argument, I know
I think I might be able to articulate it a little.
Substack had this great quote while Max and I were trying to name our module: "libraries should never be nouns, they should be verbs."
That's not just about naming, that's pretty much his entire design philosophy for modules. Small discreet pieces of code that do one task well. A healthy module ecosystem is built from thousands of small components and not from dozens of "frameworks" and other nouns.
The single function export encourages this design pattern while exporting a hash with several properties encourages the module to be more of a "noun."
This isn't a theory, you can observe that the most popular node modules are the simplest to use anda, with the exception of express and underscore, are single function exports.
More information about the es-discuss