A few years ago (during my first attempted venture) I was creating a Microsoft MSN Messenger client for regular feature phones (with Java ME.) And part of what we did was to create a proxy that we ran on a server. This proxy basically translated the MSN Messenger protocol into a purpose built protocol for the client we were developing. There’s a ton of good reasons to do this; The phones at the time didn’t handle many simultaneous connections very well, and connections were also often dropped. So we needed something that would take all the MSN Messenger connections pr client, merge them into one optimized connection and also tolerate a few seconds of disconnection/reconnection every now and then.
The other horrible thing about developing for feature phones back then was the crappy support for socket connections. Often, the network operator would only allow a HTTP connection through their own proxy, so we also needed to support long pooling over an infrastructure that didn’t really support it.
Anyway, the point that started making me feel that good cozy warm feeling when watching the video was when I started thinking about how much easier it would have been to create that proxy using node.js.
Sure, we could have used blocking IO, and dealt with the scalability issues later on. But as sure as we were about the coming success of our client, non-blocking IO was the way to go. Dealing with partal reads, thread pools, sessions (remember, we needed to tolerate dropped connections) and all that was not very fun. Far from as fun as it is creating web apps with modern JS libraries.
And, this is where node.js might come to the rescue. Sure, it might be very early right now, but give it some time and a few killer frameworks, and maybe even back-end server programming will become just as fun as front-end browser programming. And looking at the future trend of web apps, with long pooled HTTP connections and WebSockets, tools like node.js is essential.