Tech Stuff: Full Frontal ‘09: Simon Willison on Server-Side Javascript and Node.js

Sent to you by Hunny via Google Reader:

Full Frontal ‘09: Simon Willison on Server-Side Javascript and Node.js

via Ajaxian » Front Page by Michael Mahemoff on 11/20/09

Simon Willison snuck in a last-minute topic change, and is now going to give the server-side Javascript talk.

The news of the past 24 hours is ChromeOS. For the first time in years, someone's re-thinking how an OS should work. With Chrome, you turn on your computer and you're in the browser. What's really interesting is to contrast it to the introduction of the iPhone, where Apple's apps used native APIs while they expected developers to write web apps running in the browser with limited abilities. Here, Google's apps are using the same web platform...it's a level playing field.

Javascript combined with JSONP makes it real easy to write quick and dirty apps. An example of a quick app is Tweetersation Simon wrote with Natalie Downe. Simple app, 200 lines, written in an afternoon. At a larger system level, there's Google Moderator, which is essentially a pure-Javascript solution with a no-op in the noscript tag.

These pure Javascript apps are great for experimenting and prototyping. The problem with this style of development, though, is you're completely breaking web standards. The web Simon "felll in love with" is one where you point to a URL and you get content coming back.

With server-side Javascript, we can get the benefits of the things we like about Javascript, but without throwing away with the things we like about the web. Simon has been playing with node.js, and evidently the results were important enough to throw out the old talk and make this new one.

Take a step back and look at the interaction patterns with a web server. The conventional model is straightforward request-response, where the server tries to respond and disconnect as quickly as possible. But ... there's also the event loop model. As in Comet; it's generally considered to be more efficient, so why do web developers avoid it? Simon says traditional server-side languages aren't designed to deal with event-driven programming. It's more like "do A, do B, do C, exit". Javascript, on the other hand, is well suited to do callback-driven event programming.

Brave Simon now proceeds to live code with node.js. He shows a "Hello World" daemon, where the code looks like Ajax in reverse, and runs extremely fast. But where it gets really interesting - and useful - is with Comet. Another demo. The code is tiny and the benchmark looks good.

Simon's built his own framework on top of node.js: Djangode takes the best features from Django and sticks them on the server.

PLAIN TEXT

JAVASCRIPT:

var dj = require('./djangode');
dj.serve(dj.makeApp([
['^/$', function(req, res) { dj.respond(res, '<h1>Homepage</h1>'); }], ['^/other$', function(req, res) {
dj.respond(res, '<h1>Other page</h1>');
}],
['^/page/(\\d+)$', function(req, res, page) {
dj.respond(res, '<h1>Page ' + page + '</h1>');
}]
]), 8008); // Serves on port 8008

The more interesting example is Comet, which he's demo'd here.

Moving on to persistence, there's the NOSQL trend of the past 18 months, and he shows how simple it is to write CouchDB queries from node. It's easy to talk to CouchDB from Node.js apps. Redis is another interesting database, which could lead to pages being rendered very quickly, given its performance benchmarks.