What's with the weird require convention

[Mario Gutierrez]

What's with the weird require convention?

    # when is keyword in CoffeeScript

    var When = require("when");

    var sequence = require("when/sequence");

Instead of a single module

    // when.sequence

    var When = require("when");

    var sequence =  when.sequence;

   // coffeescript

  {defer, sequence} = require("when")

[Brian Cavalier]

Hey Mario,

I don't think it's weird :) But, it can certainly be a matter of preference.  We have come to prefer smaller, focused modules, over one big file.  We feel it makes the code more manageable and easier to read and refactor.  It loads less code during development in an environment like AMD (faster development load/turnaround times), and also allows a build tool/optimizer like cram.js or r.js to include only the modules that are used.  There are probably cases where importing one large file is more succinct, just as there are probably cases where importing a smaller module is more succinct.

Admittedly, the 'when' module itself isn't as small and focused as something like when/sequence.  That's mostly historical.  Our preference for smaller modules has evolved over the past 2 years.

[unscriptable]

Hey Mario, 

Like everything we do in cujo.js, we try to make it easy and straightforward for devs to start using core functionality without being burdened by the bazillion useful features in the libs.  when.js does this perfectly.  I have no idea why you'd think it "weird".  

-- J

On Wednesday, March 20, 2013 2:59:34 AM UTC-4, Mario Gutierrez wrote:

[Mario Gutierrez]

I think of module/package as being a library of related things. Instead of having a single "when" dependency, when is many dependencies "when", "when/sequence", "when/parallel", "when/pipeline" ... A namespace is created for every helper function which is unusual.

[Brian Cavalier]

On Thursday, March 21, 2013 11:58:43 AM UTC-4, Mario Gutierrez wrote:

I think of module/package as being a library of related things. Instead of having a single "when" dependency, when is many dependencies "when", "when/sequence", "when/parallel", "when/pipeline" ... A namespace is created for every helper function which is unusual.

We agree that modules and packages are indeed the new coarse and fine grained units of organization of Javascript.  However, we feel that "one giant file of all functionality" as the primary unit of organization of a library is not the way forward and isn't the direction Javascript is headed.  Our design philosophy is that smaller, focused modules are easier to maintain, refactor, and consume.  This is supported by looking at the evolution of Javascript.  For example, CommonJS packages are, by definition, collections of modules, package.json describes the collection of related modules making up the package.  If packages were intended to be a single file, then package.json's "main" property wouldn't really be necessary.  Also, TC39 is designing a module system for ES6, and is looking at packages and modules as the primary units of organization.

The when package is a single top-level namespace "when", with submodules that provide functionality.  This is in-line with the general direction of CommonJS packages and modules, so feels quite natural to us, and feedback cujo.js users has been very positive on these smaller, focused modules.

FWIW, Javascript objects and functions have been used extensively for namespacing purposes in old school approaches that rely on globals, so I'll argue that something like when.sequence is just as much a namespace as `when/sequence`.

Of course, our fine-grained approach may raise the concern of browser load times in production.  That is mitigated by optimization tools like cram.js and r.js, which build packages and modules into an larger unit of organization (we call them "bundles" in cujo.js).  For example, you may build your entire application into a single bundle file, and deliver it to the browser in a single http request.  Larger applications may be built into several bundles which are loaded on demand or in the background as a user navigates around an application.

I appreciate that not everyone will agree, but we'll stand by our design philosophy that smaller, focused modules are a good thing.