|
As a noder, I'm like half-way with you. In javascript, as with other languages, you can totally use inheritance (prototypal in js) when making things. But, it's usually better to expose an object than a constructor (imo) when it comes to exports. Being expected to do something like: var Foo = require('foobar').Foo;
var Bar = function (opts) {
Foo.call(this, opts);
this.baz = "biff";
}
require('util').inherits(Bar, Foo);
This sort of behavior is all well-and-good, but it should be contained because it's boilerplate-y. In javascript, at least, it's not a very good pattern, and I suspect this carries over to other environments (to an extent).I also think that standard libraries have to strike a balance between "batteries included" and "not cluttered with a bunch of crap that was relevant in 1995", and that different standard libraries attempt this in different ways. I think python neglects the latter to supply the former, while node swings the other way and compensates by having a really nice package manager. Time will tell which is a better approach, but I'm betting on Node's model. > The "radical reusability" section is just the author realizing that modules are awesome. Again, welcome to the party. Modules are awesome! You sound like a python guy, meaning your module system is actually pretty good when it comes to qualified imports. Compare python imports to ruby's require, or browser-side script tags sometime, and I think you'll find that there's an awareness problem when it comes to qualified imports. :( That said, the package management side is kinda shitty for python (at least when compared to npm). |