Comment by weixiyen | Hacker News Reader

Comment by weixiyen | Hacker News Reader

Parent Full thread

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.

I'm going to address my opinions on your issues a few at a time.

As to the existing libraries, I find a bigger issue is sometimes the number of bad libraries that have become more popular than maybe better libraries. That and some bits have been abandoned for some time now. -- That said, I find that since most of them are out in the open, it's easy enough to fork and address the issues at hand, if the upstream author is unresponsive, then change the name in package.json, and publish your own version.

I've seen far worse error handling... you can use try/catch/finally, which is pretty standard, and most internals will do this for you, and return the error against the callback.

npmjs.org isn't the entirety of the node community, and I think this particular instance was a bit of a mistake, but perhaps not having npm fallback to regular CAs was also a mistake... if they'd done that, it would have continued to work. I don't know of a way they could have done this without breaking something... The lack of advance notice is the biggest issue, but many/most wouldn't have seen it anyways.

With node/npm it's easy enough to create more/smaller packages/modules that are easier for larger teams to maintain. We've been using git+ssh:// references for our internal packages.

I've spent the better part of 4 years following, and over 3 using node.js. I find that there is a huge mix of developers in the larger community, and that it's a lot like running with scissors at the moment, but things will stabilize when the dust settles a bit. I think it's uptake has been far faster than Ruby/Rails and there have been some growing pains.

More than the front end developers, we get to have full stack in one language for a lot of environments. We also have the benefit of a few very large companies participating (Yahoo, Walmart, and others). I'm at GoDaddy in Platform and Commerce development, and a huge portion of our new development server-side is going with node.js

I don't doubt that there will be detractors regarding the use of node.js in certain environments. I wouldn't use it for say image processing... but I might use it as a manager against a queue which launches image processing. It's a matter of using the right tool for the job.

> I'm at GoDaddy in Platform and Commerce development

ಠ_ಠ

sockjs is better than socket.io if you're into WebSocket (streaming support etc).

This is the right solution - unfortunately, socket.io has been essentially abandoned, but it's the library that everybody knows, and is mentioned in almost every node+websockets tutorial. We get questions about socket.io all the time in #node.js, and the answer is usually "use sockjs".

Guillermo Rauch is working on a complete rewrite (engine.io), but it's been very slow going. I don't envy him; socket.io has gotten very popular very fast, it's complicated software, and people expect it to be much more polished than it is.

What do you mean by "ready"? Because for me, ready means being able to run a relatively stable production system, which plenty of teams who use node are able to do.

You listed some downsides, but none of them are actually breaking problems that block running a stable node production system.

What flaws did you find in Socket.io? What were some flaws in other libraries?

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.

Wow that is a nasty bug.

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

Reply on news.ycombinator.com