A Weekend With Node.js

Last weekend was the Node Knockout which I talked about my preparation for last week. 48 hours to develop an application in Node.js. My friend Michelle and I set out to learn Node.js more than win the competition. We did a little fiddling before hand but nothing particularly major. Our particular application was a MUD, something we thought would provide an interesting mix of server challenges and general complexity as well as being amusing to us(we first met on the Discworld mud many years ago).

Working with Node.js is a different mindset from most other application work I've done in the last couple of years. The event driven model requires more thought to get state right, particularly as Javascript's notoriously awkward scope becomes so much more prominent when building a full server application rather than just responding to events in the browser. There is power there once you get going though, and we definitely started churning out functionality towards the end of our 48 hours.

By the end of 48 hours we had an evented server that was serving telnet on port 8000, a webserver and Socket connection on 80 and a crossdomain.xml file on 843. All of this in the context of a single Node instance. This was also where the power of something like Node.js really becomes apparent, we had managed to implement a relatively powerful server supporting a wide array of interaction options in a shared space that a number of people could inhabit at once.

(We also managed to create a suitably crazy design with a late ring-in to do some photo-shopping and logo creation.)

The server was able to handle a number of players all talking to each other and interacting in that space without any particular issue or noticeable performance effect. This is an excellent example of how the Node.js style leads to higher performance by default rather than needing to optimize processes for performance later.

Node.js is straight-forward to deploy given that you run the server as part of the application in most cases so it's easy to move it around and put it in convenient places. Unfortunately we didn't have much access server wise as we had a choice between heroku and a locked down joyent instance on solaris which meant we couldn't do some of the more complex ideas we had for separating out our server processes a bit. But it's definitely something to take advantage of for quick apps in the future, it's rare for efficient and easy to deploy to go hand-in-hand.

I've still got an ongoing gripe with the state of naming in Javascript. Everyone seems to be terribly afraid of using too many letters in their method and variable names, probably due to Javascript's history as something that weighed down the client when they had to download the files to their browser. For more complex apps that don't need to be optimized for size people really need to think about improving communicability over code size, it's much much easier to read complete words the describe what something is.

In the end it was fun, I learned a good deal and, as always, I enjoyed the 48 format. I highly recommend 48 hours of something to learn it and doing at the same time as a bunch of other people means there's an active IRC channel full of all the same problems at once.

If you're interested our code from the weekend is on github, as far as I can tell we had written ~1700 lines of code that were part of the final deploy.