I've recently had another blog post published for GOV.UK, titled How and why we removed jQuery from GOV.UK. It was followed shortly by The impact of removing jQuery on our web performance, which relates to the same thing but written by Matt Hobbs (I was given co-author credit but all I did was review it).
In praise of jQuery
First things first. I didn't manage to fit it into the official post, but I think jQuery is brilliant. It makes writing JavaScript simpler, it solves browser incompatibilities with ease, and I'm fairly sure we wouldn't be where we are with JavaScript right now if jQuery hadn't shown what was possible.
Removing it from GOV.UK was important, but I wanted to acknowledge that jQuery has really helped me over the years and I'm in awe of the people that thought it up and maintain it to this day.
Writing the post
I think this is my seventh for GDS? I'm starting to lose track.
In blogging terms this might be my pinnacle. This was a huge piece of work spanning many years and involving many developers. After it was all finished I genuinely wondered what could possibly be next, but that was only a brief moment (there's always a next thing).
I'm quite pleased with the post, although naturally it doesn't include all of the detail of this three year piece of work. The original draft aimed to document the entire thing and came in at more than 2000 words, covering everything from how we did it and why, to the technical challenges and some interesting things we discovered along the way.
There were some scripts where removing jQuery was so complicated and interesting that I could probably write a whole post about them, but I'm not inclined to right now.
One small technical story
I will highlight one particular hurdle, which was a script that relied heavily on jQuery's animate function and a complex arrangement of promises and callbacks to animate something only after an Ajax request had completed.
Animate is an interesting function. You can apply it to an element with a desired change to a CSS property, which then creates an animation. For example say you had an element with a height of 100px that you wanted to smoothly shrink to 90px in one second.
The way animate works is also interesting. It works out each step of the animation then spams the DOM with inline updates. In the example above this sequence would look like:
- <div style="height: 99px"></div>
- <div style="height: 98px"></div>
- <div style="height: 97px"></div>
...and so on, each change applied within a fraction of the timeframe given. It feels strangely inefficient but I can't think of a better way of doing it.
There's no native JavaScript equivalent for animate (although I briefly considered writing one), but I was eventually able to reproduce the required effects using CSS transitions and simple class switching, which turned out to be really fun to implement. The end result was indistinguishable from the original.
That particular page has since been completely redesigned and all the JavaScript removed, so I can't demo it or explain further, but what's replaced it is far more usable, which is the important thing.
Online response to the post
We weren't the first people to talk about this work, as Matt originally talked about it on Twitter back when it was first completed back in March, then Jeremy Wagner wrote about it, which was very complimentary. The blog post was picked up on Reddit and Hacker News, and also got a mention on CSS Tricks - which was a real personal thrill for me.
There were also a lot of comments online. A lot of them were very positive. Some were... less positive.
I find it interesting to look at some of the responses and try to understand where they're coming from. I don't want to respond to specific comments but I think it's worth considering some of these positions in case you're a developer who wants to do similar work but are being held back by such attitudes in your organisation.
Broadly, they seem to fall into the following categories.
(something else, usually images) are the problem, not JavaScript
Performance is complicated. Uncompressed images is a classic gotcha that can slow down a site, but a small amount of unoptimised JavaScript can be even worse. Images are downloaded and displayed. JavaScript has to be downloaded and executed, which can block a page from responding until it completes. This means that the power of your device can be as important as the speed of your connection.
I'm not saying don't also fix big images, because they're a problem, but consider more than just the obvious.
The other thing to note is that images are often specific to a page, whereas JavaScript libraries are often included on all pages. If you can make all of your pages slightly faster, isn't that a win?
jQuery is cached so all of this was for nothing
A lot of people reasonably pointed out that jQuery from a CDN should be cached, so it shouldn't make much difference to performance from the second page onwards. That's an excellent point.
Unfortunately, something like half of the visits to GOV.UK are to a single page, which means those users don't get that benefit. The other problem is that a shared browser cache is no longer permitted since Chrome v86 and Firefox v85, which is an entirely sensible thing to do yet unfortunately removes the caching benefit of a CDN.
It's not worth the effort of removing small dependencies like this
Dependencies are added for a reason - to make code easier to write, or to do something that's not worth the effort of reinventing. But over time those reasons might change, or other factors might come into play - such as the effort of maintaining that dependency, reaching the end of support, or the discovery of security vulnerabilities.
Just because something was useful a year ago doesn't mean it's useful now.
No one has broadband slow enough to notice the difference
If you've never experienced slow internet then great, but there are genuinely people in this world who don't have that, either because they can't afford it or because it isn't available where they live.
Internet speed is also context specific - if you're on a train, in a forest, stuck in a lift, up a mountain, or anywhere else with poor signal, your phone's connection to the web can be much slower than normal. Why frustrate your users when you could be helping them?
Final thoughts
When it comes to web performance, anything you can do to make your site faster is probably a good thing. If your site is quicker than a competitor it can make a real difference to your business (and your Google ranking, apparently).
Performance is also a multi-headed beast - you can't fix it by looking at just one thing. Fixed the big problem? Great, but if you haven't looked at all the small ones then they can still add up to a slow site.
That said, you need to weigh the effort required against the potential benefits. When you do, you should also consider the life span of your site. If the site is huge and complicated and only needs to last a year it might not be worth removing a small dependency, but if it needs to last longer, then that should be a factor in your decision.
In the meantime, I'm sure there are other things we could do on GOV.UK to make it even faster, and I'm looking forward to figuring them out.