Not all tools are appropriate for all niches. The author made it clear they don't have an issue with Javascript as a whole or even with Node.js necessarily, but rather the use of Node.js as a major server platform or as a platform for large applications.

These things aren't pain points in the browser the way they are in Node. I have never felt the need for an ORM in the browser. I have never dealt with client-side code that was using so many libraries I had to worry about whether exceptions would be handled via exceptions, or the first argument of the callback, or rejected promises. No one (at least, no one I know) is installing node modules like isArray to use in the browser.

Yes, these things _could_ technically apply to the browser, but it's not commonplace. In the node world, these are all things you deal with consistently.

Erm, well, considering the adoption rate of Browserify and Webpack, I'm going to disagree with you there. Especially considering React's momentum practically requiring some form of module builder.

Webpack doesn't bundle at runtime, it doesn't add any amount of code overhead per module that I can easily measure, and it doesn't trash startup speed.

It's something like tens of bytes (minified), FWIW, for the closure that each module gets put into.

Node has support for the built in isArray, and you only need that "micro module" if you want to support IE8

For example the OP got fed up with Python and switched to Node. Now he is fed up with Node and switching back. I can say that focusing on the downsides of the tool I am currently using and the upsides of the tool I am not using is a fairly common thought pattern for me too. Of course the way to combat it is to remember that it is very rare for some tool to be strictly superior to others and just focus on the task at hand.

Choice is a very dangerous thing. When reading the book "Coders at work" I was struck by how primitive some of the old computing environments were. But that did not stop those people from doing amazing things with them. I now think that was partially to their advantage because they were freed from choosing the language/framework and so could concentrate on doing, you know, actual stuff.

I agree that when programming mostly alone one can get by very nicely in any reasonably popular language since its popularity necessarily means that it's workable in the areas where it's typically used. I disagree that languages can not get in your way if you know what you're doing once you're not doing it alone.

Things like long term support, stability and security rate in how mature different technologies are for production. Considering a lot of the problems the author ran into with node.js aren't secret, I think he might actually have liked it quite a bit to go on to try it in production for a full year.

Sure. If you're a good novelist you can write something great even on a keyboard with a broken 'e' key (btw, your 'I' key is about to break; you should replace it asap).

But novelists don't have deadlines and when the novel is done, they usually don't take reader requests to change this or that part of the story.

"The advantages and limitations", what works and what doesn't, "areas to avoid" are precisely the point of that kind of review.

haha - touché, point taken :-)

Deadlines seem like a great excuse for compromising quality. Sure, life is complicated, the boss is demanding, the mortgage has to be paid, the children need to be supported etc. etc. but compromising quality and enthusiasm (they usually are correlated) because of the "terror" of a deadline will just leave you at the mercy of the next "terror", only this time you'll even have even less enthusiasm to fix the spaghetti. Doesn't sound like an enjoyable existence.

Of course, very few people have the privilege of never having to compromise, but it's never black or white and there are many more degrees of freedom to choose the path with more quality than are implied.

>"The advantages and limitations", what works and what doesn't, "areas to avoid" are precisely the point of that kind of review.

The "area to avoid" in the review is Node.js and considering that large and impressive projects have been written in it, it seems that this is another case of throwing the baby out with the bathwater.

I hate to "well actually" you :) , but a great number of authors have contracts that demand one or two novels a year over a fixed period of time. I know Iain Banks did with his publisher, he mentioned it at a one of his readings of a new but yet unpublished novel I was lucky to attend back in 2007'ish.

> they usually don't take reader requests to change this or that part of the story.

Even well known authors are reigned in by their editors and proof readers, and sometimes things have to be changed.

[1]: At least, not for long.

[2]: created in the past thirty/forty years