Recently, I’ve been toying around with a little web framework called Zappa. Well, I guess you could call building two fully-functional websites, one of which is running for a live client with decent traffic “toying”. I must say, I’m very, very impressed by what I’ve seen so far.
For those of you who haven’t heard of it yet, node.js is a recent serverside framework that uses Google’s V8 Javascript engine serverside. That’s right, you run JavaScript on your server, and it serves up your html pages and can do low-level sockets. If that sounds a little backwards, it kind of is at first. Node.js itself is very much a low-level framework, essentially just an asynchronous sockets library and the standard javascript functions, so trying to do much of anything using just node.js is a pain.
Enter Express. This wonderful little framework imitates Sinatra (and several other web frameworks) and turns the process of defining routes, handling html templates, and setting up a proper MVC into childsplay. On top of this, we run Zappa, which takes everything that makes Express great, and lets you code it in Coffeescript instead of straight JavaScript. Suddenly, you’re using a super-clean language that’s just a joy to use.
This leads to something interesting. Zappa ships with CoffeeKup as the templating engine, so you write your HTML templates, serverside logic, and clientside behavior all in CoffeeScript. No more funky data formats and weird convention differences– your client and server can literally share libraries and source code if you so desire. That alone speeds up the process of development tremendously. On any given day, I touch the database, controllers, several views, and the CSS stylesheets. The fewer times I need to re-adjust my slow, human brain to parse a different language syntax, the happier I am. (The only part of my codebase that isn’t in CoffeeScript right now is the CSS, because Stylus is cleaner, and CSS is sort of weird to begin with.)
This is not without some oddities of course. node.js is primarily an asynchronous framework– this means that all of the library calls pause execution while waiting for IO, and then resume that execution later. Rather than using functions that, for example, return data from a database, you instead pass a callback function as an argument, and deal with the data in the callback whenever IO gets around to finishing. For anyone who’s used to a traditional procedural language, this is a royal pain to adjust to. The main benefit of course is performance (because node.js can serve other pages while it’s waiting for your IO to complete) but it’s a rather unconventional way to code coming from a background in PHP. CoffeeScript does make anonymous functions and callbacks very easy, which helps a lot.
The other major benefit is performance. The way node.js works, when you start up your server, it parses and JITs your code (V8, Google, totally awesome) and leaves the instance running in memory. Because node.js can queue up requests and handle everything asynchronously, it doesn’t need to spawn a new processing environment for each pageload, but does it all using the instance that’s already
there. That means response times are quick and memory usage is minimal. It does mean that all of your code is always loaded, but that’s hardly an issue for the vast majority of sites. I find that, running no less than 4 node.js instances during development, the small PHP site that my server runs still uses 4x the RAM as all of the node instances combined, and that’s running through lighttpd with some rather restrictive process spawning limitations. I’m not sure how well node.js can balance high traffic, and I’ve yet to try load balancing, but I’m hoping this new project gives me an opportunity to do both.
Yesterday, I started doing gruntwork on a new project in Zappa, one that I’ll reveal later this month as it starts to come together. In the course of a single day, I was able to put together a fancy ajax navigation system, a real-time chat window, and a forums system. All that in a one day using Zappa! In any other framework that might have taken me several days. It is some seriously rapid development. The community is already strong around nodejs as well, even though it’s so young and not widely adopted. I’m using Sequelize to make MySQL work a breeze, Cradle for CouchDB when I’m feeling adventerous, node-validator to sanitize inputs, and several other odds and ends that make things breezy.
Would I recommend node.js? Absolutely. Is it the best language for any job? Of course not. No language is. It’s certainly capable of being a general-purpose server, especially with its low level socket APIs, but right now the support isn’t quite there for everything. As an HTTP server it totally rocks. If you’re willing to take the time to learn it, I think it’s well worth the effort.

















