3 ms·

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

by jeswin 13y ago

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.

fooyc 13y ago
> Your DNS example is a corner case 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

by jeswin 13y ago

fooyc 13y ago

> Your DNS example is a corner case 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