I've always loved Crazyegg's heatmap functionality. It's a very cool method of seeing where users are clicking on your site and where the most activity is. I just stumbled upon Heatmap.js which lets you do that same thing. It uses the HTML5 Canvas element to dynamically generate the heatmaps based on your data.

Heatmap instances contain a store in order to colorize the heatmap based on relative data, which means if you're adding only a single datapoint to the store it will be displayed as the hottest(red) spot, then adding another point with a higher count, it will dynamically recalculate.

If you check out the image below, you can see how hovering over the button accentuates the heatmap's colorization  on that section:

The source is released under a very liberal MIT and Beerware license (yep, Beerware) and the author, Patrick Wied, is actively looking for contributions.

InfoWorld has published an interesting comparison of several server-side JavaScript-based server implementations. Of course, Node.js but they also cover Jaxer, EJScript, RingoJS and AppengineJS. At this point, it feels that Node.js has so much momentum that other JS-based servers are often overlooked so it's nice to see a broader view of the landscape.

It's going to be interesting to see how developers of more traditional server-side options like PHP, Python or ASP.Net adapt to Node's asychronous model. I think this quote speaks volumes to Node's model:

In the right hands connected to a right-thinking mind, the results can be staggeringly efficient. When the programmer spends a few minutes and separates the work done before and after a delay, there's no need for the machine to tie up RAM to hold the state in the thread just so it will be ready when the data finally shows up from the database or the distant server or even the file system. It was undeniably easier for the programmer to let the computer keep all of the state, but it's much more efficient this way. Just as businesses try desperately to avoid tying up capital in inventory, a programmer's job is to think like a factory boss, treat RAM as capital, and avoid consuming any of it.

Tom Robinson, a developer on Narwhal, actually comments on the difficulties of the async model:

I'm increasingly convinced this asynchronous callback style of programming is too difficult for most developers to manage. Without extreme discipline it can easily lead to 'callback hell,' with deeply nested callbacks and complex code to implement logic that would be simple on a synchronous platform.

JavaScript developers are fairly used to this style of development but in the "post back" world, this isn't as commonplace so I can see where Tom is coming from.

I was kind of perplexed by this statement though: 

One developer referred to CommonJS, an attempt at building a standard server-side API, as "so 2009."

I've felt that the CommonJS movement had some teeth and this sounds like there may be some splintering.

I think once the tooling becomes more mature, we're going to see much easier transition path for developers and broader adoption of these JavaScript servers.

When we launched Script Junkie last June, our focus was (and still is) to provide in-depth articles that helped developers solve specific problems. The feedback has been great and Script Junkie continues to grow rapidly, due in no small part to the awesome authors who produce excellent content for SJ readers.

Now that the site is chugging along nicely, we want to continue to support the JavaScript, HTML and CSS community by providing information in a more timely fashion. This is why we've launched the Script Junkie blog. Here, you'll be able to find news posts about the latest and greatest libraries, frameworks and technologies in the web development space. This will be very different than the deep technical articles found on our main site and will offer much more frequent, bite-sized posts to keep you up-to-date with what's going on in the community. And we're actively looking for the community to submit news to us so if you have something new and exciting you want to share, please be sure to email us at sjsiteteam@microsoft.com.

Having timely information is invaluable and we hope to provide the best resource for keeping the community in the loop.