I am cranking through some code examples and plenty of research for this thing. It should kick incredible amounts of JavaScript ass. Come to think of it, it's a ninety minute presentation, so it better kick ass I'm going to look at load times, execution times, ySlow scores, codebase and add pure editorial commentary for several popular libraries (at minimum, jQuery, YUI, Prototype, and Dojo), as well as pure JavaScript and my own bare-bones library.

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…
(more…)

Yeah, Even to You.

I suspect it's because the people that are most vocal about the subject are from places like Google and Yahoo!, but it seems to me that a lot of people think that front end performance really only matters for extremely high traffic sites. When talking about these kind of things with other engineers at conferences and the like I've heard something similar to the following a few times and it left me scratching my head:

"That stuff is for the Googles of the world. We don't really need to focus on that with what we do."

(more…)

Yes, another CloudFront post. I'm a penny-pinching, performance minded AWS user, what do you expect?

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.

It made quite a splash recently so I'm sure some of you are curious about Amazon's new Content Delivery Network (CDN) service, CloudFront. I know the Amazon Web Services suite of tools can be a little intimidating for non-developers, so this article outline how pretty much any reasonably technical person can get themselves up and running on CloudFront and can start reaping the benefits of geographical optimized content delivery.
(more…)