Monthly Archives: April 2012

Throwing out the kitchen sink

In a recent post on the BBC Responsive News blog, Tom Maslen makes the case for a significantly more aggressive browser grading strategy.

Browser grading, as a formal concept, was popularised by Yahoo! back in the day. At the time, their support matrix was understandably generous: IE6 and Firefox 2.0 were both “A-grade” browsers at the time, which by Yahoo!’s standards meant that they deserved the full, bells-and-whistles experience. Their policy has changed over the years; they no longer explicitly specify an A/C/X grade to indicate support, but instead use the woolier term “test baseline” to determine which browsers belong in their QA suite. IE6 and their low percentage ilk remain C-grade, meaning they receive:

…nothing more than semantic HTML, the content and experience is highly accessible, unenhanced by decoration or advanced functionality, and forward and backward compatible. Layers of style and behavior are omitted.

Progressive Enhancement in a nutshell.

Maslen’s hierarchy of browser needs

The BBC’s approach, while sharing the PE philosophy, is significantly more exclusionary. A single line of JavaScript leverages browser feature detection to decide whether you’re one of the chosen few:

if ('querySelector' in document
&& 'localStorage' in window
&& 'addEventListener' in window) {
// bootstrap the javascript application
}

The upshot of this simple check is that IE9+ and all other modern browsers get the progressive sugar. And, according to Maslen, it also means that (because you now know that your visitor’s browser supports such useful shortcuts as document.querySelector and window.addEventListener) you can avoid the need for large and slow-to-download JavaScript libraries. Instead:

…we can now develop JavaScript solutions that use native implementations of features that we have grown accustomed to using without having to download polyfilling libraries.

I have a problem with this approach.

Baby with the bath water

Reducing page weight is a noble aim. A recent article from Pingdom contains some statistics on the increase in average KB over the last year; it’s certainly true that the golden rule I grew up with – no page should ever be over 100Kb – has long since been mothballed. And, as Maslen’s and Pingdom’s articles indicate, the explosion in the use of JavaScript libraries is definitely a part of the problem, despite also evidently being the solution to many developers’ prayers. By abstracting away all of the cross-browser headaches and leaving novices with a single, easy to learn API, libraries such as jQuery have secured a place in almost every developer’s default template.

Maslen contends that, if the primary reason for using a library is to work around the lack of universal support for querySelector and the like, you don’t need it providing you are only targeting browsers with native support for that feature. Bang – well done, you just reduced your page weight by 32Kb or more!

I have two main issues here:

  1. By excluding users on IE8 and lower, you are potentially cutting off a quarter or more of your audience from experiencing the intended experience. This proportion will also vary depending on what day it is (IE usage rises during the week when people are at work without the freedom to choose their browser) and from what part of the world your site is being accessed (IE6′s share of US traffic might be sub 1%, but could be closer to 50% in China according to Wikipedia).
  2. Replacing library functionality with native doesn’t really gain you anything in modern browsers. Any decent library will be checking for the native functionality first, so the library function simply becomes a reference to the native function.

So, if ‘going native’ has no meaningful benefit for A-grade browsers, and you don’t want to exclude large swathes of your traffic, what are we left with in the “No” column for library usage? File size.

I accidentally a whole JavaScript library

jQuery and other libraries are attractive because they make it possible to do clever things with web pages without the need to actually learn or understand JavaScript. Novices can drop the core library into a page, throw in a few other plugins, maybe the jQuery UI module as well, and get started on making things appear, disappear, or fly around the page. And for the hobbyist or small business that might be okay, but at scale you naturally start to worry about download speed, concatenation, minification, and all the other site speed buzzwords. But I’m going to let you in on a little secret…

Nobody ever said that you had to use the whole library.

Don’t need to use any AJAX requests? Strip that shit out. Same for animation, event handlers you’re never going to use, dimension calculations – in fact, anything that you don’t actually need to use can be removed (or commented out, then minified using a minifier that ignores comments).

Of course, this approach requires you to know what you’re doing when it comes to native JavaScript; but so does Maslen’s proposal, and by choosing to keep the library you’re scoring some significant benefits:

  • There is now no need to exclude older browsers that don’t support the native features simulated by the library;
  • You can spend your time creating new functionality, instead of painstakingly recreating something that was already present in the library you threw away.

Library authors have put in many thousands of hours figuring out the most efficient, compact and bug-free way to do most of the things you’re likely to need on a web site. Ignoring that free labour in favour of doing it yourself to help fewer people just seems like the wrong decision.