Not to worry - there will be a new hot technology within a year or two, and a good percentage of the node.js people will scramble to rewrite in it to avoid looking old fashioned.
Why? In one word I'd say its speed. Its freaking fast and I'm not just talking about io performance, thats just the icing on the cake. Learning curve, development time, configuration, all extremely quick and easy.
One thing I think people forget or don't put enough emphasis on is that node is a networking library, its not just server side JS the way that asp.net is server side C#, its JavaScript from the bottom to the top. Web server, load balancing, pretty much anything you need can be written in just JS. That makes it extremely easy to set up your own stack that you actually have the potential to comprehend or even write yourself and launch something on the cheap. For 5 bucks on digital ocean you can set up a node app that will probably scale enough to survive a slashdot effect or launch a mvp.
Node and its related frameworks still have a ways to go but I think it is a mistake to dismiss it. And finally I'd like to mention that its first release was 2009 and people have been talking about it a lot ever since. I think its already passed the trendy technology phase and will continue to see widespread adoption.
They were pretty gung-ho about Ruby and Ruby on Rails between 2005 and 2010 or so. Then their hype moved to JavaScript and Node.js quite rapidly. It'll very likely move on to something else soon enough.
Lots of bad ideas. I mean, it is an ok feature, but by no means a killer-feature really. Ocsigen does the same thing: you can write your code in OCaml and the client-side part will by translated to JS automatically. Neat? Yes. Killer-feature? Probably not.
And JavaScript is really not that great to start with, so daveloping in something else server-side is not the worst idea.
And JavaScript is really not that great to start with
It's fine. IMO, all languages have warts you have to work around, once you know them it becomes a non-issue. I can't think of the last time one of those "JavaScript WTF" moments actually tripped me up in real code.
JavaScript is a convenience language across the stack for when the team is small, or even a single person.
The problem with web dev (I've thought about this a lot) is really that the browser is kindof the hinge. So no matter what you do for unifying languages, even porting modules so they're same on node front to back-end... you still can't really ever get to a point where you're unit testing pretty reliably through the full-stack.
So might as well test parts in isolation & who cares if there is one language throughout the whole stack as long as your devs are good at the languages required.
One day I think the impedance between server & client will disappear, but only when the browser's role as a rendering engine diminishes or finds better integration/intimacy with the codebase.
(and incidentally, i stopped caring so much about this struggle once i learned how to develop pretty reliable SOA. Haven't totally given up trying to conceptualize the perfect stack tho)
That's because there is a separate module for everything! Want to run "mkdir -p"? There is a module "mkdirp" just for doing that.
If you implemented every command as a separate library, of course there is going to be a lot of code out there.