After relaunching my personal site and realizing all my other sites are in pretty good shape for the first time in forever, I’ve suddenly found myself with plenty of free “tech time” to mess around with whatever I want to mess around with. Which is cool, because, while I appreciate being able to tinker in a very practical manner on production sites and learning from what what works now, I really miss being able to mess around with the newness out there. Sometimes, like with the HTML5 work I’ve been doing, the two can meet, but more often than not the brand new stuff needs to sit on the burner a little bit before it’s ready for prime time.

You’ll see where all of this is going when you see the first topic in this month’s recent reading roundup.

Node.js is Where It’s At

This is where it all began (go ahead, watch, I’ll wait…)

Even as distracted as I’ve been since November (with switching jobs, launching my site, etc. I’m surprised I can tell you my name,) I’ve heard a lot of buzz about node. After a week of messing around with it, I can understand why. It’s a hell of a lot of fun, really elegant and because of that there are all kinds of JavaScript only visions running around in my head.

If you too want to get started, this tutorial is a good place to start to get the basics up and running and then you can dive into the API Docs for full exploratory fun.

P3PC

Another great bit of research from Steve Souders. Here Souders is going through common widgets, analytics beacons and ad networks to identify the performance hit we all take from leveraging this 3rd party content. This is a big deal as there’s only so much a person can do before the performance of their site eventually ends up in the hands of another engineer (or team of engineers). I’d like to see companies react to and make use of the valuable advice he’s offering. With omnipresence of some of these systems it would make the entire web a better place.

There have been four so far, and I have to admit I’m waiting for some more bad code. So far, he’s profiled 3 reasonable implementations and one pretty crummy one (from digg.) While it’s actually way more useful to learn from people who get it, I want to see something really awful. I want to see a performance car crash.

This also leads into one thing I’m going to spend some time talking about when I present on front end performance in May- testing is the best thing you can do to speed up your site. Whether it’s testing different coding approaches in JavaScript or testing server set-ups (or even different servers) for static content, the most valuable knowledge you can gain about the performance of your application is from your application. The guidelines and best practices floating around the net are a great place to start, but each application and site is different, so you won’t ever really know until you’ve tested out your solutions.

Can you tell I’m already getting excited for my talk? I am.

JavaScript Event Delegation is Easier than You Think

Nothing Earth-shattering, clearly, but useful if you want to explain how delegation works under the hood. Watching people wrap their head around it as a library feature, it seems a bit like voodoo. The basics are actually pretty straightforward.

The Anatomy of a Whale

A really interesting article from the Twitter engineering team about how they hunt down the source of a a whale. I love reading about that kind of performance detective work, especially when it’s on Twitter’s scale.