The node.js aesthetic

It generally dumps a ton of colorful errors to your terminal. If you find them obscure, please be comforted by the fact that I certainly do not find them obscure, and would love to fix whatever problem they indicate. It's actually my job.

Also, npm is a software program, and not intelligent. It doesn't "like" things. To the extent that it has preferences, it loves semantic versions, accurate metadata, and especially you.

Node allows you to do the same thing very elegantly.

I don't think the problem is unaddressed, but node has the most elegant solution I've seen.

As a rough strawman to move forward, let's say that a "Class" is a programming object consisting of:

- A constructor method.

- A set of properties and methods

- Optionally, a parent Class from which it inherits properties and methods, which may be overridden.

And that, when invoked, a "Class" returns an Object which is said to be an "instance of" that Class. The constructor method is called in the context of the instance, and the properties and methods are inherited by the instance.

JavaScript has those things that I'm calling "Classes". In fact, every single function is a "Class" if it's just invoked with "new", and every single object can be a prototype. It's so full of classes, the only excuse for missing them is that you weren't even looking.

Please see almost any JavaScript tutorial ever for an explanation of the "new" and "instanceof" operators, or any from the last 5 years for an explanation of the "Object.create" method.

Or better yet, just sit down with the ES5 spec, and actually read it before you talk about what this language does and does not have.

Additionally, if you mean something by "object inheritance" other than "objects can inherit from objects", then I don't even think we're on the same planet. That's actually something that JS has which most other "object-oriented" languages don't have.

I'm done being trolled for now, I think. Have fun, kids.

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);

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).

usually not. if your framework builds off the common web integration system for the target environment, i.e. Java Servlets, WSGI in Python, etc., you're already handed a request scope within a thread. It's only web servers and containers that really have a heavy lifting job to do.