When the team that maintains the gov.uk website faced the issue of updating their old and outdated jQuery dependency, they decided instead to get rid of it altogether. Among other benefits, they achieved a not negligible performance improvement and, in the process, created a migration guide for other developers to tap into.

As senior developer Andy Sellick explained, the project was born as a side-project to remove tech debt and legacy code, but it eventually brought benefits in both performance and security alongside with reducing maintenance complexity.

From a developer perspective removing jQuery has been a long but worthwhile process. Rewriting our code has taught us a lot about it and we’ve expanded and improved our tests. In many places we’ve been able to restructure and improve our code, and in some cases remove scripts that were no longer needed.

The task was a large one, with over 200 scripts spread across multiple applications and pages, plus their corresponding tests. On the positive side, each script could be rewritten as an isolated piece of work, which made contributions much easier across the whole organization. This made it possible, for example, for backend developers to get involved in the process and speed it up.

The team also realized the task had not to be an "all or nothing" endeavor to turn out successful. Indeed, where specific applications used jQuery in more complex and larger scripts, the team decided to give them their own jQuery dependency to avoid slowing down progress while still ensuring most of the website would be migrated.

Speaking of the benefits the migration brought, security is a clear winner, since gov.uk was stuck on seriously outdated jQuery 1.12.4. Furthermore, the migration got rid of a major maintenance problem in itself.

The team summarized several performance improvements they got in a second article, addressing thus some of the initial criticism. This seemed to focus mostly on the argument that jQuery has a negligible size in the context of modern network speeds and caching. On the contrary, while jQuery is indeed only 32 Kb in size, head of frontend development Matt Hobbs stressed the fact that JavaScript libraries are render-blocking resources. This means they have a significant impact on the time it takes for a page to fully render in addition to sheer page load times, with an improvement of 17% and 8% respectively. Additionally, the time required for the web pages to become interactive also improved by 17%. The benefits are even greater for visitors using slower devices or experiencing adverse network conditions, as Hobbs detailed in a Twitter thread that is a great example of how to measure web performance.

As mentioned, the gov.uk team also created a specific guide to remove jQuery from an existing JavaScript codebase, including a list of common issues and hints at how to deal with syntactic and standard library differences.