Pretty much everything is on Github: it’s a requirement to be open unless you have an extremely good reason to be closed.[1] The only closed source project I ever worked with there was fraud detection for identity verification.
Yes, and I'm saying that that is impossible because it's reasonable for all their work to be publicly available and not reasonable for little of their work to be publicly available. Why should the publicly funded work not be made publicly available?
I'd say it's quite reasonable that it's publicly available, and even that it's unreasonable that other governments' works aren't as much publicly available.
For anyone thinking that this is an insignificant saving of "only" 32kb, it's really important to remember that many of the site's users will be amongst the poorest in society. Many of them will be accessing it using the oldest, slowest devices; things far slower than the average HN reader's last few phones. Anything that can be done make the site work better for them is worth the effort.
If you load www.gov.uk, you'll see it's loading several fonts (each of which is roughly equal to the size of jquery), google analytics, several javascript bundles, and other crap. It is far from simple effective HTML as described by the link.
jQuery is probably the least of their problems. And ironically, the blog with the jquery article on it loads jquery! I realize it's not part of the same site.
I guess that the main benefit is not the saved 32kbytes, but rather the CPU cycles that are saved by not using jquery...
"jQuery is probably the least of their problems" : they also explicitly said that removing it was a low-priority background task, yet I like that mindset where they care about people having low-bandwidth or low-end devices "removing jQuery means that 32Kb of JavaScript has been removed from the majority of pages on GOV.UK. GOV.UK is already quite fast to load and for many users this will make no noticeable difference. However, the change for users on a low bandwidth connection or lower specification device will be much more noticeable, resulting in significantly improved page download speed and performance"
Yes but how much the js-code parts grew because longer scripts length in vanilla javascript? And how much added for another ajax library?
I don't see that using vanilla js instead of jquery gives enough advantage compared to that i have a much more pain writing that frontend code with vanilla.
And specially replacing ajax or get (fetching json) with error handling (no server at all, server error, data not found -cases) is just awful with axios for example.
You don't need 32kb of code to use Fetch with error handling — especially since modern JS is not only faster but more concise than the style you would have written with jQuery in its heyday. I've gotten tons of use out of jQuery but it's been 15 years and browsers have gotten a lot better.
Speaking as someone from the US, The BBC nature and science documentaries are I think the best in the world (in English at least), especially anything that David Attenborough gets involved with.
My suspicion is that the US actually has national natural history and science collections/museums that are on par with the UK these days, but we lack something like the BBC to "market" them for lack of a better word.
This article is an excellent “how to” recipe for going about this sort of refactoring, from the importance of training and of getting the backend folks on side, to clever use of attrition (no more jquery in new, then start removing it from old), and identifying sites that still needed it and accommodating them.
Seems like a well managed project.
(Yes, yes, this could be a very glossed over account that ignores frictions and factions along the way, but I quite enjoy taking it at face value.)
1. Didn't read the article (they dropped 13% of the entire page weight). The websites are already well below of "today’s average"
2. Don't understand the impact of having a page that loads instantly at the government level. These websites are not for fun, they must work well for everyone.
> the change for users on a low bandwidth connection or lower specification device will be much more noticeable, resulting in significantly improved page download speed and performance.
My point is that a phone browser that noticeably slows down for 32k is probably fairly useless. Why not get poor people better phones instead of spending money optimizing for crap?
Practically speaking, if their phone can't handle 32K of jQuery, it probably can't handle Google or any other search engine they'd be using to find the site in the first place.
They do not "presume" anything. They state clearly that the old version of the library was causing performance problems. They also state that 32k is noticeable on slow connections, which it absolutely is. In fact, on unstable connections, it can mean the difference between the site loading and not loading. Reliability is critical for government services. They also mention that the work improved the codebase and the developers' experience with it, which is a criminally underrated means of improving efficiency and therefore reducing cost.
All in all, this sounds like fantastic work relative to what we normally expect from government end user software. We should encourage this kind of thing, not jump to the hand-wavy "my tax dollars!" complaint, which approaches meaninglessness in its commonality.
They do presume this is a problem when they don't quantify it. At the end of the article it is made clear there is no quantification going on:
> We’ll provide more detail about exactly what that means in the next blog post.
The whole premise of the article is conjecture until we see the performance numbers presented. The claim is that removing a one-time load 32kB library is useful to page load times and user experience for low end users. It has ZERO specifications or performance numbers cited.
Besides which, the net effect of more data on a page is that it takes a little longer to load the page. For someone who has a slow phone, they are conditioned to this through use of other sites (or even clicking on the housing link at the top of the UK Gov site and waiting for a 360kB image to load). What is the advantage of speeding it up for them for a single site they may or may not use?
Will we also take it upon ourselves to justify anything that makes them click on the wrong link and have to wait to go back? Unlikely.
It’s not the loading that’s a major problem, it’s the runtime parse cost on low-end Android devices. Everyone has to use government services, so you don’t get to ignore cheap devices.
(Also, luckily the UK government spent zero dollars on fixing this.)
It's an accessibility problem. GOV.uk is the official government website that contains key information that must be made available to every UK resident. If shaving off 32K of JavaScript makes the website easier to load for people with extremely bad hardware, then it's worth it.
gov.uk is an absolute delight to use exactly because of this kind of focus on the details and valuing of simplicity. I can’t think of another website that is more useable, and that is super important for a site that needs to work for a very diverse user base who have no choice but to use it.
I think you’d also be surprised how little this is likely to have cost compared to benefit to the tens of millions of users of these systems. GDS run a tight ship.
For a government entity, an unreasonably large amount of their work is on GitHub. Examples:
Front end design system: https://github.com/alphagov/govuk-frontend
Project board: https://github.com/orgs/alphagov/projects/4
Requests for comment: https://github.com/alphagov/govuk-rfcs
Gov.uk infrastructure as code (WIP): https://github.com/alphagov/govuk-infrastructure
“The GDS way”: How they work, tech stack, processes, etc https://github.com/alphagov/gds-way
“Terraform modules for on-boarding with Cyber Security services eg define the IAM SecurityAudit role”: https://github.com/alphagov/cyber-security-shared-terraform-...
Full GitHub org with >1,500 repos: https://github.com/alphagov