The real problem with node.js is the libraries. Just don't use them.
A huge portion of existing libraries is full of hidden bugs, shortcomings, race conditions, edge cases, security issues, unscalable, or unmaintainable (and unmaintained).
This is exacerbated by the fact that npm makes it really easy to publish a library.
Many small buggy libraries.
Core modules are too low level (e.g. http), and you really don't want to use an overlay library.
Not to mention that doing something not trivial fully asynchronously is not as fun as it sounds. You will spend a significant time tracking bugs, fixing edge cases, and making your code stable.
There is still no way to make async code better in core (no promises); and there are a handful of incompatible promises implementations.
Oh, and node.js is not really fine actually. It's not doing everything using asynchronous I/O as you would expect. Node.js uses a thread pool for things like DNS resolution and disk I/O. Only 4 threads by default, for all those things with very different latencies. This means that 4 DNS queries can occupy node.js's 4 hidden worker threads, and block your disk I/O for minutes.
It isn't hard to find out which libraries are maintained and which ones aren't. Maintained libraries are of fairly good quality. This isn't very different from other languages, except that there is significantly more activity around node.
Promises not being in core is a good thing. Eventually many of those use cases will switch to using ES6 generators.
If you want to scale node, you would use multiple processes.
Your DNS example is a corner case. There are discussions around it, and such issues impact all frameworks.
As for security issues, unscalable, unmaintainable etc, those are too generic in nature to comment. I can say this though; node is in production at some of the largest companies in the world and they are talking about it too.
One of the many corner cases that will kill your application or open it to DoS (malicious or not).
I.e. you can DoS any nodejs application if
* you can trigger it in making 4 DNS queries
* and it does disk i/o (or uses any other core module using the thread pool)
> There are discussions around it
I've seen tickets opened since more than a year on this, without anything showing a willingness to improve that. Version 0.9 even removed the possibility to increase the number of thread (which they re-added in 0.10).
> such issues impact all frameworks
When you start using node, you don't expect that your bottleneck is a thread pool.
In non async frameworks you know you'll have this kind of problems, you can design around it, and a DNS query in some module can't block I/Os for the whole application.
> If you want to scale node, you would use multiple processes.
By "unscalable" I meant libraries using O(n) or O(n^2) algos, with 'n' the number of users or the size of your data, where it would have been easy to do it in O(log) or O(1).
> Promises not being in core is a good thing
Why ?
> Eventually many of those use cases will switch to using ES6 generators
It hope it will improve, but we are discussing the current state of nodejs
The real problem with node.js is the libraries. Just don't use them.
A huge portion of existing libraries is full of hidden bugs, shortcomings, race conditions, edge cases, security issues, unscalable, or unmaintainable (and unmaintained).
This is exacerbated by the fact that npm makes it really easy to publish a library.
Many small buggy libraries.
Core modules are too low level (e.g. http), and you really don't want to use an overlay library.
Not to mention that doing something not trivial fully asynchronously is not as fun as it sounds. You will spend a significant time tracking bugs, fixing edge cases, and making your code stable.
There is still no way to make async code better in core (no promises); and there are a handful of incompatible promises implementations.
Oh, and node.js is not really fine actually. It's not doing everything using asynchronous I/O as you would expect. Node.js uses a thread pool for things like DNS resolution and disk I/O. Only 4 threads by default, for all those things with very different latencies. This means that 4 DNS queries can occupy node.js's 4 hidden worker threads, and block your disk I/O for minutes.