It's disappointing to see unnecessary and unjustifiable censorship of perfectly legitimate comments like that.
I think it has become more of an issue in general as the discussion of software projects has moved away from mailing lists and newsgroups to blogs and other more centralized discussion forums.
I recently saw similar censorship happen at Opera's blogs. I would read some of the comments one evening, and there'd be some good discussion about features that the newer versions of Opera's desktop browsers are still missing. They weren't always positive comments, but they'd be relevant and remarkably civilized given the circumstances. Then I'd read the same blog post a day or two later, and entire discussion threads full of useful content would be gone.
Criticism and negative discussion is often the most valuable that there is. It often highlights real problems that need to be solved. To delete such commentary is not at all helpful, and actually probably quite harmful.
And now that comment seems to have disappeared behind an "awaiting moderation" message after it has already been out there four hours. Nice. But the above link still works (for now).
Hi! As I said in the comment's on Rob's own post: we didn't censor any comments. We did no moderation of any kind on any comments today; we were way too busy trying to fix the problem. I don't know what happened to Rob's comment, but it was nothing anyone at npm did.
Seems to have been moderated away by the blog owners. Classy. Here's the comment under discussion:
==
Hey. Crazy kids. This probably needs to be that one event where you sort of realize: "Oh. Shit. Other people...like...use this & stuff. We need a damn road map and a release schedule. Stop smoking dabs all day, breh."
Now is also a great time to learn how to think about the potential ramifications a production push will have prior to making said production push. And, if your change might impact some or perhaps even all of the other people who use your technology, then some degree of coordination - perhaps an email? - would be nice. It's one of those things that will help make you look professional. I suck at professionalism. You have no idea. But, even I know this much.
Because, right now, I sort of feel like I'm asking some very rightfully fearful people to consider entrusting perhaps their actual career into the development of technology they need to succeed and thrive. And, I just started recommending Node.js - with a caveat - that npm basically sucks. I hate having to do that and it needs to stop.
So, here we are.
Your words continue to be one thing, and your actions continue to be quite another. If it is even possible to break a tool like this, that tool is not enterprise grade. If there is nothing that can be done to successfully insulate a tool from unexpected behavior like this, then that tool scores less in evaluations that consider the risk of using it.
npm, at this point, has more going against it in the discussion than going for it right now. Events like this are, in the grand context, very significant and telling. They are also ill-timed. Because big, important decisions are trying to happen right now regarding the use of Node.js. It is literally on the cusp of going mainstream. And, that seems to be generating some pressure that at least one team (npm) doesn't seem to be equipped to handle.
So, before you find yourself facing a community that forks instead of trying to work with you, I would like to just make a simple recommendation. In the future, you seriously need to sit and think about the potential ramifications of a production push. And...this is the important part...if those changes are going to have a wide impact on your users - send some sort of email WELL IN ADVANCE. A flippant blog post the day of is not Doing It Right™.
Because, and I feel like I might not only be speaking for myself, I'm not going to allow the promise of Node.js to be voided by the lackluster and problematic performance of its weird bolt-on archive service. Someone, perhaps even me (as in: today), will simply replace you with a workable, decentralized solution that enterprise can specialize to purpose and communities can use to grow and thrive.
If you have any questions, ask somebody. Anybody. If you're struggling with some concept of enterprise grade operations, what people expect of you and how you can succeed with events like this in the future, I'm positive every capable person here would provide some level of guidance and support. We want you to succeed.
Please, try harder or get forked. Not sure how else to say that.
We didn't moderate away anything. I am literally the only person who CAN moderate those comments, and I was at a conference all day. 100% of my online time was spent working with my team to figure out the fastest path to a fix. We didn't realize the extent until way too late, and that's bad on us. I apologize.
I didn't delete your comment. I'll look at the moderation queue and see if maybe disqus is set to auto-hide after some time or something. I'm sorry for the confusion there.
Who is Rob? (Was it simply attributed to "Rob", or am I supposed to know who Rob is? I do not do much with node.js, and Google searches for "rob node.js" are not pulling up anyone terribly canonical-looking; mostly just some one-off talks, and from node.js only people who work at companies I also haven't heard of that use node.js.)
I am Rob (Colbert) rob.isConnected@gmail.com. I'm nobody special other than someone who faces the constant up-hill struggle to convince IT that Node.js is ready only to have it shot down time and time again. I'm unemployed right now just trying to find a way to use the right tools for the job. And, I'm sick of failing because other people suck, won't learn, won't adapt, won't address problems or make progress.
The "canonical" resource for my comment on npmjs.org today can be found here:
That is my personal blog running on my personal server on a DSL line that I can't afford while about to go homeless. I have no choice. I have to speak up and fight for what I want to be using or throw in the towel.
> who faces the constant up-hill struggle to convince IT that Node.js is ready only to have it shot down time and time again
So it sounds like it is not ready. _This_ drama, tangled slinkies of callbacks, drama with the Node.JS contributor that got pushed out because if "her" vs "his" pronouns and so on. Nothing of that says it is ready. So I pretty much agree with your IT department. Sorry.
> And, I'm sick of failing because other people suck, won't learn, won't adapt, won't address problems or make progress.
Maybe they did, they just didn't arrive at the same conclusion as you. Maybe they are even right.
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.
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.
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.
I would observe the CPAN community. I highly recommend reading http://www.cpan.org/misc/ZCAN.html and then begin forking+mirroring the registry immediately.
Recommended it once. Literally the first time. I've waited a very, very long time to do that. Once. And, it was for building a prototype. Project went well. Very well. Wanted to be able to keep it. Gave up. And, I have stopped recommending it. I left.
Presently seeking to either find a place that's already working with Node, earn a living on my own project based on Node or switch careers. I intend for this to be my last attempt at being able to work my way. It's never going to make sense to others, so I have to make this work.
Sorry if my outburst asked all the hard questions, but reality is: How is this stuff going to get ready if there isn't some pressure to move it in that direction? And, given this is the environment I want to build in, what am I supposed to do? Wait for someone else to kick a tire & light a fire?
No, thanks. Done with that. Don't care if Node's not perfect for what you want to do. It's the right tool for my jobs and the kind of jobs I want to be working on. We're not all docking space shuttles to space stations in real life.
Anyway, I have stopped recommending Node.js. I just personally use it and won't work anywhere that doesn't.
Software development as a career isn't about making you as the developer comfortable. Your job is to build high quality software using the tools given to you. If you are good at your job, and you are able to be a convincing salesman, you can often build software using the tools _you_ want (this has never been an issue for me anyways), but it is not going to be given to you on a silver platter.
It sounds to me like you are convinced that Node is the one and only way to build the software you work on (I think that's bullshit frankly), and you won't accept any alternatives. Well, you are about to find out the hard way what happens when you aren't willing to work past your own pride.
First, I will point out that when a bunch of people are talking about some guy by his name in a way that feels like everyone kind of knows who it is, it is natural to be curious. However, in this case, there is a very important reason why this is the first thing you should ask: the meat of the message is a threat that "Rob" will somehow build something and replace npm: if Rob were someone well-known in the community, is someone who maintains a package manager for another large community, or even if he had a history of rampaging through communities and disrupting them with successful solutions, this would be a meaningful threat; if Rob is just an angry user, then the threat is hyperbole which should be ignored. Like, I appreciate that "arguments should have weight regardless of who said them", but applying that knee-jerk as if that is true in all situations is harmful to discourse... in this case, what we are looking at is mostly a rant and a threat, not an "argument": it matters greatly who the speaker is.
"Please, try harder or get forked. Not sure how else to say that."