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.

My First Day With Node.js

Today I spent a good number of hours playing with node.js the hip new concurrent evented javascript server that runs on Google's V8 javascript server.

I've been meaning to play with it for a while given its recent popularity and a couple of weeks ago I casually committed to taking part in the Node Knockout(a node.js event inspired by the Rails Rumble) next weekend. Competitions like this are a good way for me to convince myself to learn new stuff and they're fun. The first Rails project I spent a decent amount of time thinking about was for the Rails Rumble a couple of years ago.

So far playing with node has been quite entertaining. I've managed to set up a tcp/ip server running chat and some minor interactiveness in a few hours, with most of those hours having been taking up with upgrading my javascript skills to deal with more complex things than some fancy browser manipulation. I haven't done any serious load testing but it performed well and took up minimal resources under my very basic attempt at hitting it with a few users trying to spam each other.

One of the big issues I initially had was getting stuff to split into separate files nicely instead of massive scripts running the entire system. But that turned out to be relatively straight forward to fix once I got a better idea of what was going where and a handle on module system that node provides.

My biggest rant about node and to a certain degree JavaScript so far today has been the lack of sensibly descriptive naming in a lot of the code floating around. It certainly didn't help my initial understanding that the example chat app had server.js and fu.js with the server initialization occurring fu.js. It reminds me how much I love that the Ruby community has favoured very descriptive names for things.

So far I've enjoyed the change in headspace as well as doing some "serious" programming with JavaScript for a change. I certainly think most people will find their Javascript skills will improve from spending some time with node.js. Hopefully a couple more evenings and I'll have learned enough to not completely embarrass myself during the node knockout. At least there's not going to be any insane last minute problems getting the server setup right.