Having spent a lot of time in both Rails and Node, the author's unequivocal endorsement of Node as better than Rails is just silly.
Building a non-trivial app on Node requires that you do an awful lot of plumbing. Yes, the performance is very nice. And it's going to be great when the community grows up a bit and things start to Just Work with each other. But that day is not here yet.
A lot of the components that people depend on are still really buggy. In the last three days I've had to debug and fix four bugs in other people's npm modules. The community's attention is spread all over the place, because there isn't one dominant way of doing things.
People can't even agree on sane interoperable packaging for code that needs to work on both browsers and in node. It's a mess.
I don't see an unequivocal endorsement of Node in this rant. He only said that Node is better by his criteria if you really want to use a dynamic language.
For what it's worth, I'm using express, and it doesn't come close to solving my plumbing problems.
Example 1: express can't reliably send a 500 if your code hits an unexpected exception somewhere down in the callback chain. To do it correctly, it would need to either use Node's Domains feature, or would need to use Promises. My own code uses Promises, so I had to extend express to respect them.
Example 2: I have quite a few modules that need to be shared by both node and the browser. Browserify is almost good enough, but to get it actually working, I had to find and fix bugs in four different npm packages.
Example 3: Then I try to add engine.io, which generates client code completely incompatible with browserify. To get the engine.io client included in my javascript bundle, I literally do a regexp replace on its source code.
Example 4: Then I try to add Ember.js to the client bundle. It's packaged in yet another incompatible way. I need to write a wrapper for it so it can find its dependencies, and so that the top level symbol can actually get exported other than on window. I write another slightly different wrapper for ember_runtime so I can load the models on server side.
Example 5: Does anybody do automated management of templates as clientside dependencies? It doesn't seem like it -- it seems like most people just package up all templates into one big pile. Well, I did some more plumbing, and now my code can say "require('templates/foo')" and template foo will automatically get precompiled into the relevant bundle.
Except that nearly all of the cool kids in the community hate Express and nearly all of them believe that chaining micro-utilities together is the wave of the future. (Because, of course, researching 25 utilities takes the same time as researching one.)
Express uses a convention that is not harmonious with many of the later best practices that have been emerging.
Does the community hate Express? You can't really hate that much on it considering that TJ's one of those who's leading the movement: http://component.io
Building a non-trivial app on Node requires that you do an awful lot of plumbing. Yes, the performance is very nice. And it's going to be great when the community grows up a bit and things start to Just Work with each other. But that day is not here yet.
A lot of the components that people depend on are still really buggy. In the last three days I've had to debug and fix four bugs in other people's npm modules. The community's attention is spread all over the place, because there isn't one dominant way of doing things.
People can't even agree on sane interoperable packaging for code that needs to work on both browsers and in node. It's a mess.