InfoWorld has published an interesting comparison of several server-side JavaScript-based server implementations. Of course, Node.js but they also cover Jaxer, EJScript, RingoJS and AppengineJS. At this point, it feels that Node.js has so much momentum that other JS-based servers are often overlooked so it's nice to see a broader view of the landscape.
It's going to be interesting to see how developers of more traditional server-side options like PHP, Python or ASP.Net adapt to Node's asychronous model. I think this quote speaks volumes to Node's model:
In the right hands connected to a right-thinking mind, the results can be staggeringly efficient. When the programmer spends a few minutes and separates the work done before and after a delay, there's no need for the machine to tie up RAM to hold the state in the thread just so it will be ready when the data finally shows up from the database or the distant server or even the file system. It was undeniably easier for the programmer to let the computer keep all of the state, but it's much more efficient this way. Just as businesses try desperately to avoid tying up capital in inventory, a programmer's job is to think like a factory boss, treat RAM as capital, and avoid consuming any of it.
Tom Robinson, a developer on Narwhal, actually comments on the difficulties of the async model:
I'm increasingly convinced this asynchronous callback style of programming is too difficult for most developers to manage. Without extreme discipline it can easily lead to 'callback hell,' with deeply nested callbacks and complex code to implement logic that would be simple on a synchronous platform.
JavaScript developers are fairly used to this style of development but in the "post back" world, this isn't as commonplace so I can see where Tom is coming from.
I was kind of perplexed by this statement though:
One developer referred to CommonJS, an attempt at building a standard server-side API, as "so 2009."
I've felt that the CommonJS movement had some teeth and this sounds like there may be some splintering.
I think once the tooling becomes more mature, we're going to see much easier transition path for developers and broader adoption of these JavaScript servers.
I said on Twitter:
"CommonJS got bogged down in cross-engine politics. npm was more pragmatic, and could keep up with what node.js users needed."
The reality is that writing stuff to be portable across multiple server side javascript engines is not easy. As somebody who wants to just push something quickly up to GitHub and npm after a night of hacking, there's not much incentive to do it when the other CommonJS implementations have little in-common, and have approximately 0% market share.
@Jim: So how we motivate the ones that just want to do quick pushes to work towards a common set of APIs? Seems like the right direction but it sounds that some think it's hindering progress.