The King is dead
When we started the responsive refactoring of BBC News, one of the core strategies was to take performance really seriously (super serious). Because of this we decided to use a collection of micro JavaScript libraries instead of a monolithic one. But that was in 2011, and this month we made a change you may find odd.
Since the launch of responsive News in March 2012 two things have changed:
- Our requirements now involve supporting the desktop site.
- jQuery 2 has been released.
I’ve been criticised in the past for being a jQuery hater, that my dislike of it was irrational. I never did hate jQuery, what I did dislike though was people’s attitude to it. “Just use jQuery” was something that many people said to me over the past few years. jQuery is a tool, and like any other tool a developer who is good at their craft will know when the best time is to use it.
We chose to go with Ender instead of jQuery, this is because Ender is modular so you download only the bits of it that you will use. We kept our use of Ender to a minimum, adding it into the page as an AMD dependency and using it in our JS view files for DOM manipulation and AJAXing.
The latest release of our codebase, however, has swapped Ender out for jQuery 2. Because of the way we used Ender, it was very easy (ish) for us to extract it out for a better alternative.
Right now, that better alternative is jQuery 2. But this doesn’t mean that we will now change our usage and litter our code with jQuery chaining. We’ll continue to keep our usage of it light, so next year when something better appears, we can swap the dependency out again.
But it’s only 10Kb…
jQuery 2 can be compiled into a small file size – about 20Kb if you remove most of it. While this is still bigger than the ender modules that we’re using (qwery-mobile, bonzo and reqwest), we’ve decided that the benefits (much better documentation and support) it gives us outweigh the extra 10Kb it takes to download.
10Kb is a lot when you look at the overall size of our JavaScript, especially when you consider we’re not adding any additional content or functionality. But the new requirement to deploy our code onto the desktop site as well as the responsive site causes complications for us.
The change in the responsive website to jQuery 2.0 also co-incides with the desktop site moving to jQuery 1.9. These two new versions of jQuery are API compatible. We did have other options, such as Zepto which is smaller and also has the goal of keeping API compatibility with jQuery 1.* (jQuery Classic). Ender also states jQuery API compatibility as a project goal, however Ender changes parts of the API where it feels (justifiably) that jQuery gets it wrong, while the browser support for Zepto does not fit our needs.
Our JavaScript uses AMD, so any DOM manipulation library the code depends on is injected into scope as a dependency. This means our code is a completely separate concern to the external DOM library. We can deliver modules of business logic onto the responsive or desktop site and have it interact with which ever version of jQuery is on the page.
Long live the king
Eventually the desktop site will be retired, so this new requirement to support it with the responsive codebase is not permanent. It will be archived and the responsive website will become the primary product.
Over the coming years browser support is going to change, and what we want to do on the page will change. jQuery will be bested (like it was in 2011 and 2012 by Ender) and we’ll want to move away from it. But until then, its the King again.