4 ms·

>> struggle to convince IT that Node.js is ready only to have it shot down time and time again Devils advocate, is it actually ready? Especially in light of th

by s_kilk 13y ago

>> struggle to convince IT that Node.js is ready only to have it shot down time and time again Devils advocate, is it actually ready? Especially in light of the incompetence on display with this particular issue?

btown 13y ago
To be fair, Ruby's had similar issues with its gem repository, including an intrusion that one time (about a year ago).
- s_kilk 13y ago
  Fair point, but to my memory the Ruby tools/community were never quite as ramshackle as those around NodeJS.
weixiyen 13y ago
Node.js is not ready. The main problem with Node.js is that the libraries out there simply are not good, are broken / don't do what it says it does, or have critical issues outside of the most basic use cases. I'm talking about the popular libraries (like Socket.io) down to all the ones being contributed by the community. I've found flaws in every single library I've used so far, and they are flaws not present in their Python and Ruby counterparts. Error handling in Node.js is one of the worst of any language. NPM is now deploying breaking changes to production, without apology. Javascript is also a terrible language for larger teams, unless everyone follows the same exact convention, as the language itself is extremely flexible, more so than any language I've seen. I've spent 2 years in this ecosystem, and pretty much anything else feels liberating in comparison, be it Python, Ruby, Go, Erlang, etc etc. The only thing Node.js has going for it is a community of front-end developers who want to dabble in backend architecture, but I just feel this whole entire ecosystem is too fragile for my tastes. Like MongoDB, as people begin creating successful businesses out of it and reach a certain scale, similar articles bashing Node.js are all but inevitable.
- woah 13y ago
  What flaws did you find in Socket.io? What were some flaws in other libraries?
  - weixiyen 13y ago
    The flaw in socket.io had to do with redis-store. When deploying socket.io over multiple Node.js processes / servers, you want to use redis-store, at least, that's what they recommend. When you use redis-store, after running for a while, it puts your CPU usage at 100%, and you have no idea that it was because you used redis-store. Socket.io therefore is only really optimized for running a single process, which of course breaks down as soon as you have any significant I/O throughput or hit a certain # of connections. Same issue happened to me when using the Node zmq library. Inexplicable increase in CPU, which took 3 months to later fix. I could really go on, but these are mission critical libraries that have obscure bugs that are extremely difficult to track down and will bite you in production. Before I'd ever consider using Node.js again, I'd wait for - 1.0, this is taking too long. And even when they release a 1.0, it is more likely to be for marketing purposes than actual product stability. - Library Maturity (maybe another 2-3 years) - Better error handing. Nothing is worse than being left wondering why your server is failing in a production environment without relevant context and information. Another problem with the Node.js community (not all, but a lot) is that you have all these former front-end guys who can build great APIs with pretty web sites that make you believe the library is battle tested and safe to use, when in fact nothing is further from the truth.
    - woah 13y ago
      Wow that is a nasty bug.
  - andypants 13y ago
    Over 500 open issues, some over 3 years old. For 3 years without a fix, you'll have been able to DDOS your own server with socket.io: https://github.com/LearnBoost/socket.io/issues/438 https://github.com/LearnBoost/socket.io/issues/438
- 13y ago

by s_kilk 13y ago

btown 13y ago

To be fair, Ruby's had similar issues with its gem repository, including an intrusion that one time (about a year ago).

s_kilk 13y ago
Fair point, but to my memory the Ruby tools/community were never quite as ramshackle as those around NodeJS.

weixiyen 13y ago

Node.js is not ready. The main problem with Node.js is that the libraries out there simply are not good, are broken / don't do what it says it does, or have critical issues outside of the most basic use cases. I'm talking about the popular libraries (like Socket.io) down to all the ones being contributed by the community. I've found flaws in every single library I've used so far, and they are flaws not present in their Python and Ruby counterparts. Error handling in Node.js is one of the worst of any language. NPM is now deploying breaking changes to production, without apology. Javascript is also a terrible language for larger teams, unless everyone follows the same exact convention, as the language itself is extremely flexible, more so than any language I've seen. I've spent 2 years in this ecosystem, and pretty much anything else feels liberating in comparison, be it Python, Ruby, Go, Erlang, etc etc. The only thing Node.js has going for it is a community of front-end developers who want to dabble in backend architecture, but I just feel this whole entire ecosystem is too fragile for my tastes. Like MongoDB, as people begin creating successful businesses out of it and reach a certain scale, similar articles bashing Node.js are all but inevitable.

woah 13y ago
What flaws did you find in Socket.io? What were some flaws in other libraries?
- weixiyen 13y ago
  The flaw in socket.io had to do with redis-store. When deploying socket.io over multiple Node.js processes / servers, you want to use redis-store, at least, that's what they recommend. When you use redis-store, after running for a while, it puts your CPU usage at 100%, and you have no idea that it was because you used redis-store. Socket.io therefore is only really optimized for running a single process, which of course breaks down as soon as you have any significant I/O throughput or hit a certain # of connections. Same issue happened to me when using the Node zmq library. Inexplicable increase in CPU, which took 3 months to later fix. I could really go on, but these are mission critical libraries that have obscure bugs that are extremely difficult to track down and will bite you in production. Before I'd ever consider using Node.js again, I'd wait for - 1.0, this is taking too long. And even when they release a 1.0, it is more likely to be for marketing purposes than actual product stability. - Library Maturity (maybe another 2-3 years) - Better error handing. Nothing is worse than being left wondering why your server is failing in a production environment without relevant context and information. Another problem with the Node.js community (not all, but a lot) is that you have all these former front-end guys who can build great APIs with pretty web sites that make you believe the library is battle tested and safe to use, when in fact nothing is further from the truth.
  - woah 13y ago
    Wow that is a nasty bug.
- andypants 13y ago
  Over 500 open issues, some over 3 years old. For 3 years without a fix, you'll have been able to DDOS your own server with socket.io: https://github.com/LearnBoost/socket.io/issues/438 https://github.com/LearnBoost/socket.io/issues/438
13y ago