It plays a lot more smoothly with MongoDB and I find it far simpler to hook into more modern functionality with Websockets and client side JS rendering. I had a few issues with jugglingdb (which I forked and fixed) and it's all going smoothly.
I still use Rails for some sites but Node and railway.js let me bootstrap the whole API on MongoDB in a few days and get very acceptable performance.
On the flip side, code can be hard to maintain and you need to be more disciplined so that you can read the code later otherwise it becomes a callback spaghetti. Doing everything through callbacks also requires a mental shift.
Like with everything in life, there are pros and cons and tradeoffs. So choose wisely :).
It's fast, easy to setup (npm install), and relatively hardened, while still keeping everything JS.
As for static assets, those should probably be served from a CDN anyway, if one is concerned with performance.
If you write modular and/or functional code, JS code bases can be just as easy / hard to maintain as any other language.
Gevent in python for example is pretty popular and similar is the case with Em-synchony in Ruby.
I have used callback objects but really that is not even close to what one can achieve with Fibers or Greenlets.
In, say, Ruby, you've got EventMachine for something equivalent but it's definitely "bolted" on to the language. Python has Twisted, with which I have no personal experience. In PHP, there are really no options.
The Node / EventMachine / Twisted version of nonblocking IO is built on the Reactor Pattern. The common use case is to minimize IO delay. Whenever there is IO, a NodeJS script will cheerfully continue execution of other code, whereas in PHP and other purely synchronous languages, the script would block while waiting for the result. In practice, this has more use cases than just IO, of course. For example, one can send heavy computations to background processes and execute other code while waiting for the result.
So back to the original point, yes, writing nested callbacks can be more difficult to decipher than "flat" code, but the results may very well be worthwhile if you are looking to squeeze maximum performance out of your hardware.
That you can actually do in PHP, for example with gearman:
http://docs.php.net/manual/en/gearman.examples-reverse-bg.ph...
http://www.unlimitednovelty.com/2012/08/debunking-nodejs-gis...
https://github.com/faye/faye-websocket-ruby
Faye is the the most feature complete websocket implementation out there and it works quite well.
The alternative of using node.js for everything sounds good but I am not really sure, how good node and its web frameworks are for building typical CRUD applications. Rails really solves building database backed applications problem pretty well.
I receive some kind of request in a Rails controller. I need to send, as a consequence, a notification via the web socket. How does it get from point A to point B? In Erlang, it's all likely to be quite contained and fast, and not involve writing anything to external queueing software, and to boot, it's all going to happen in the same unix process, rather than having one process that's the Rails server, and another that's the eventmachine server.
I don't know Node.js and how you'd handle sending messages from point A to point B, but I'd be interested in hearing some opinions.
It's a fact that you can create functional abstractions in JavaScript. Just like you can in Python and Ruby.
This is basically just restating "Javascript has first-class functions."
While first-class functions are nice, it's only the barest tip of the iceberg when it comes to what's needed for true functional programming. When you add more and stronger assumptions to your functions and types - referential transparency, static typing, immutable data structures - you get more and more back in functional expressive power and the tools that make it possible: memoization, concurrency, tail recursion, lazy evaluation, pattern matching, and so on.
The less assumptions you allow in the language, the more these powerful functional techniques and abstractions simply won't be possible. You still stand to gain from a modular, functional style, but you will have to go back to working around the inherently imperative language in most cases.
I am curious as to what most HNers think of doing server side development in JS. It's obviously the flavor of the month, but I have yet to see the appeal. JS is certainly not a bad language, but it seems a lot more tedious than, say, ruby. The nesting of callbacks, the lack of built in OO infrastructure (given that most of us are trained with class based inheritance), the many quirks associated with making the language accessible to nonprogrammers. Am I missing something? Is there a really good reason to use JS on the server?