On: Joe Armstrong on Programmer Productivity

[grncdr]

Yes. The biggest difference is that there is no global namespace for modules.

    require('my-dependency')

returns a value, rather than aliasing identifiers into the current scope. So you end up with code like:

    var myDep = require('my-dependency')
    exports.doSomething = function (x) {
      myDep.doSomethingToAnX(x);
      // more code here
    }

The Python import (and Go and probably others) works in a similar way, except that in node, even the module names (the argument to require) are local to each module. That is: `require('my-dependency')` can return different values depending on the location of the file that called it. This means your project can depend on two different libraries that both depend on conflicting versions of "my-dependency". The mechanism by which this is accomplished is simple and straightforward. Another nice side-effect (as compared to Ruby) is that you can easily isolate a copy of any given dependency to monkey-patch or otherwise modify it, without affecting anybody else. (Not true of built-in globals such as String or Function, but that's a shortcoming of JavaScript, not Node)

Of course, the event+callback architecture and preference for writing everything in a manual continuation-passing-style makes working in Node suck for a host of other reasons, but the module system is really quite nice.

[doublerebel → grncdr]

Modified globals is the fault of bad coding, not node. There are valid reasons for using globals, but it's well known to be bad practice to modify standard classes these days.

If someone wants not yet released features, they can compile to JS/node with source maps (i.e. Traceur, Coffeescript). This also solves the cps/callback issue (i.e. Iced Coffeescript).

Npm is also incredibly easy to publish to (one line in the CLI). That leads to a ton of packages released that would otherwise hit friction in release process in other package managers.