There is still some confusion for me as to whether it's "production ready." Ryan Dahl said for a long time that it wasn't ready for production, but I haven't heard anything like that recently. In fact, I've heard others proclaim they're using it for larger sites just fine (citing poor SSL support as one of the primary drawbacks). I also remember Ryan saying that the memory management within V8 caused a lot of the bugs they were dealing with. So what's the real status of the project in terms of putting it into production?
I was all set to start a new project on node.js a couple of months ago, but ended up back on Rails. Not because node.js itself seemed flaky, but because libraries were scarce (e.g. anyone know of a credible ORM?) and, where available, often in alpha.
This isn't a criticism: it's inevitable in a young platform, and I'd happily help develop the libraries. But it didn't seem a feasible option for a project that (a) had deadlines and (b) needed features beyond the (impressive) node.js core.
Node devs tend to take a different approach to Rails/Django in this regard, there's no single ORM with lots of database backends (ala ActiveRecord). This is probably related to the fact that Node devs tend to use tools like Redis, Mongo and Couch rather than traditional relational databases like MySQL and Postgres which all have similar SQL interfaces. There are some really nice libraries and modeling tools available but they're not database agnostic SQL ORMs, for example recently I've been using Mongoose: http://mongoosejs.com/
I've come from the Django world so I empathise with the "How do I do [insert Django/Rails feature here]?" mindset, but a lot of the time the Django/Rails just doesn't work well Node. Node.js is a single-threaded, event-based, non-blocking server; it really is a totally different paradigm so you have to be prepared to rethink the modus operandi for developing web applications.
Of course, I did think about Redis/Mongo/etc. But the project (a) had deadlines, so I thought I'd go experimental on only half the software stack, (b) seemed very nicely suited to relational data modelling, and (c) allowed me to indulge my infinite love and respect for Postgres (stable! solid! powerful! frugal! fast! free!).
Also, I didn't find a lot of help online with how to do this modus operandi rethink. (Again, no whining implied).
I don't speek for Ryan Dahl or the community at large, but from what I can tell hanging out in the IRC room and reading the mail list is that it is ready for production for just about anyone. Now mind you, anything this young isn't going to be perfect, but what systems are? As far as I know the SSL issues are fixed or being patched ASAP, so you should be able to get something up and running and feel fairly secure in it
0.4.0 brings quite a few API changes from 0.2.6, so if you haven't been keeping up, you should really scour the API docs. You can also check out the wiki for a guide on migrating. https://github.com/ry/node/wiki/Migrating-from-v0.2-to-v0.3
It is very hard to define "production ready". I think that one could say that a new version of a software tends to have a lot of bugs. The more work you put into fixing this bugs (assuming you are not adding new code), the more stable it starts to be, and discovery of new bugs is more and more rare. It does not mean the software is bug free, but that the bugs that it contains are either edge cases that is rare to run across, or they manifest very rarely as real world consequences. I guess that what we call stable is just the state where no obvious bugs arise in normal usage and at the same time is pretty rare for the developers to discover, get notified, and fix, new important bugs.
It seems like that under this assumptions node.js is stable enough, but what are you doing with it? Maybe it's not going to be "mission critical", but good enough to run production web applications.
We have been running one of our critical services with node for a couple months now without any problems. It has been excellent to work with and I'm going to do more with it.
Nave plays well with npm, so you can have different sets of libraries for the different versions of node that you have installed (similar to rvm if you're a rubyist.) This is mostly important when you have libraries that are compiled C/C++.
> A specially named directory, node_modules/, is searched in the current directory for any modules.
Awesome. Currently NPM expects unprivileged users to have
access to /usr/local, and a lot of node tutorials encourage global repermissioning of this directory, which is Bad Unix.
Hopefully, once NPM gets updated, you'll have a Python virtualenv/Ruby equivalent style project-specific install system.
But then you are still relying on modules available and their versions on the system where the node app is running. Bundling is a much more reliable way of doing things.
Bundling (and the like) is a necessary evil of ecosystems riding hard on the bleeding edge, like node.js...
... and I would say Ruby/Rails, but they ought to be growing up by now, and integrating sensibly with platform package management. :-)
The difference between Python and Ruby on Debian/Ubuntu systems is astounding, and as the node.js ecosystem matures I dearly hope it will look more like the Python world than the unending adolescence of Ruby/Rails.
It really just depends on what you're trying to do. As a desktop user you probably care most about stability; we can't have a python upgrade breaking apt. As a developer it's often important to have an up-to-date version of the tools and libraries you're using.
It has nothing to do with adolescence, and everything to do with different priorities. Debian favors stability, Ruby favors breakneck progress. Each has their pros and cons.
Awesome! Alas the doc I've been reading all points to the normal /usr/local method (eg, https://github.com/isaacs/npm/blob/master/doc/faq.md doesn't mention the new stuff). How can I make it use ~/.node_modules?
> Currently NPM expects unprivileged users to have access to /usr/local, and a lot of node tutorials encourage global repermissioning of this directory, which is Bad Unix
NPM reminds you do "sudon't" if you run it as root.
Configuring it to use ~/.node_modules is not very straight forward or obvious but once you do it everything would work with an unprivileged user and without messing up Unix.
> NPM reminds you do "sudon't" if you run it as root.
To install NPM itself, you either get a bunch of 'sudont' errors or have the app fail with the normal, secure /usr/local permissions when it can't write there.
I ran into this a few days ago. I ended up reinstalling node with a prefix of ~/local, and then when I built npm it automatically used the same prefix.
Looking at the recent commits in the last two days, it doesn't look like visionmedia has changed anything for 0.4.0 in particular. If you're interested, you should try it out and file issues appropriately.
