If you're a Boston JavaScript nerd, I hope to see you there.

Here's the description:

Our next JavaScript Meetup will be held on Thursday, April 30th at Microsoft Research Center located at One Memorial Drive in Cambridge. You should come to the 11th floor to be let in. There is also parking available at a cheap evening rate in the building.

Rob Larsen , Principal Presentation Engineer at Cramer, will demonstrate comparisons between raw JavaScript and utilizing the more popular JavaScript libraries currently available.

After the presentation | demonstration, we will go around the room introducing ourselves and asking the group for advice | opinions on any JavaScript-related issues members are facing.

Microsoft will provide pizza again. What a nice company!

Please RSVP and bring guests. We always have lots of pizza left over.

And the meetup.com link:

April Boston JavaScript Meetup Meeting – JavaScript Library Comparisons – The Boston JavaScript Meetup Group Cambridge, MA – Meetup.com

robreact.com was relaunched over the weekend. There's a completely new visual design, some slightly adjusted architecture and a whole bunch of technical improvements.

Here are some things to keep in mind…

• With my CloudFront instance set in my preferences the site is a ySlow 97. Far and away the highest score I've ever produced. I can't really improve it either, as one of the downgrades is for the Google Analytics objects.

  There is one I can do, and in some ways it would be tempting to implement, if just for the technical challenge. To move my style sheet over to CloudFront, I'd have to manually create plain text and GZipped versions and then manually write the proper headers for the compression negotiation. I'd really understand that process after completing those tasks. The only issue with that is that it would be a drag to update the style sheet for bug fixes and the like.

  I guess I'll just have to live with a 97. Google's 99 can rest easy at the top of the heap.

• I used no JavaScript on the site. 100% straight HTML across the board. Of course, GA is JavaScript, but I didn't write that, so the oddity still stands. A JavaScript nerd launches a site, in 2009, using no custom JavaScript. There was just no need
• There's only minimal custom support for IE6. I only saw a couple of serious issues and serious issues were the only issues I fixed. As I've mentioned before, I'm transitioning to IE7/IE8 only support for my own sites, so robreact.com will hopefully end up being the last site I personally support IE6 on at all (albeit in a limited fashion.)

All in all, I'm really happy with it. I hope you are too.

And no, I wouldn't be offended at all if you pimped the freshly scrubbed site all over the internet. In fact, nothing would please me more.

Anyway, I'm a couple of weeks into my CloudFront experiment and while the traffic numbers are still too fresh to offer any insight on what the speed improvement might be doing for my European and Asian bounce rate (I cache everything, so it should really only affect initial page views,) I do have enough data to compare and contrast the absolute speed difference at play here.

Serving my site sprite from the three different locations I get the following results using pingdom's excellent monitoring service:

As you can see CloudFront is a significant relative improvement over the other two servers (by two and three times.)

Without researching it extensively it seems like a pretty good absolute result as well. While the sprite is slightly larger than the Lookery JS file he used to test, CloudFront performs well within the standard that CacheFly and EdgeCast set when Dave Cancel tested a few different CDN options earlier this year. Granted, his research wasn't exhaustive so someone out there might be pushing closer to 100ms for smaller files, but for the price and ease of use, I'll gladly take 134ms.

Anyone know of any broader research into CDN response times? I'd love to see it if you do, so drop it into the comments.

• Moved my interface images over to CloudFront, Amazon's new Content Delivery Network (CDN.) I'm especially hoping this will increase initial page view performance for my site in Europe and Asia, where I've always had some lag. I'll be monitoring my bounce rate to see if that's the case. The initial results are positive (an overall reduction of 1-2% in my bounce rate over the past week), but the numbers are still too small to really draw any conclusions.
• Took advantage of Firefox's Link Prefetching to speed up all those next gallery links. I tested it out and between link prefetching and all the caching I do, browsing gallery pages in Firefox 2+ is screaming fast.
• Added some copy and rewrote some of the text/labels right here on the blog. Spurred on by the blog chapter in Designing the Obvious, I decided to implement a couple of his recommendations. Within 20 minutes of having read the chapter, I'd changed the header for the comment section, added the little descriptive blurb below it and changed the label for my RSS icon from "FEED" to "Subscribe."

  Small changes all, but maybe they'll improve the experience for folks.

  Or maybe not.

  And if they don't? I'll try something else

This kind of ongoing enhancement is core to the way I approach web design/development. I often speak of sites as being living organisms and this is the kind of thing I do to keep mine growing/evolving in positive ways.

Fun times.

<link rel="prefetch" href="/images/big.jpeg">

With the href being the target content and the rel attribute triggering the prefetching mechanism. Pretty simple. I've already implemented it here on my gallery pages.

One thing I would like to see, and this is hinted at on the above linked Mozilla FAQ page, is prefetching performed automatically on anchor (<a>) tags with rel attribute set appropriately. In my mind that would be any anchor with a rel attribute of next, but the prefetch value would be fine as well. Personally, if that were supported I wouldn't have any (or very little) work to do to take advantage of this feature and in a general sense it would build on what people are already doing using prev, next and toc rel attributes on gallery links.

*it was scrapped because I hated the idea of forcing bandwidth usage on people with metered accounts. Since this is a browser based mechanism, it should be relatively painless for people in that situation to control whether or not content is prefetched.