Working with Node's callbacks for I/O feels a lot like working with jQuery's XHR/animation callbacks. It's a consistent flow that will feel familiar for a lot of js coders immediately. Speaking from personal experience, it really does help the brain keep moving.
Many javascript programmers are more than familiar with server-side development, they just haven't necessarily had a super productive environment within which to flex their skills, but that may be changing.
socket.addListener("connect", function () {
socket.write("hello\r\n");
});
$("#my-element").click(function() {
alert('Element Clicked!');
});
public void service(ServletRequest req, ServletResponse res) throws IOException {
res.getWriter().println("hello");
}
(Which it sort of did; I used to use JScript in ASP, but it's not quite the same.)
(Yes, I am the person who frequently compares Node.js to Erlang, unfavorably. But my objection is to the hype that Node.js is a unique and beautiful snowflake, rather than a retread of ideas done endlessly in other languages. I still think that on the whole it's a good idea, even if I don't think it can actually live entirely up to the hype, it can still do good things.)
Node.js will get better, but it will get spanked by Erlang at high loads and with lots of processes, and while there isn't nothing that Node.js can do about it, there's a limit to what they can do and still be JS.
(Interestingly, this is not necessarily true in general. It is particularly true here because Javascript is the colloquial term for ECMAScript, which is a standard. To get the requisite primitives in there would require changes that violate the standard, such as the execution environments and the way references are treated. A language that isn't standardized could change and still claim to just be the next version.)
I think CommonJS is the more important project to consider here.