Live data from Hacker News

The impact of removing jQuery on our web performance

insidegovuk.blog.gov.uk

91–100 of 283 posts

Re: The impact of removing jQuery on our web performance

#91
post #39
post #16

Earlier quoted context omitted.

Yes, this is an example of government design systems, which are becoming popular among developed countries: - The UK: https://design-system.service.gov.uk/ - The US: https://designsystem.digital.gov/ - Canada: https://www.canada.ca/en/government/about/design-system.html - Argentina: https://argob.github.io/poncho/ - Italy: https://designers.italia.it/ - Singapore: https://www.designsystem.tech.gov.sg/ - Estonia: http…

Australia: https://designsystemau.org/ it was the official design system until it got defunded, now I believe it's run by open source

Beautifully simple and incredibly fast to load. Well done Australia (hope the idiots who defunded it got kicked out of power after the last election and this will be fixed).

Re: The impact of removing jQuery on our web performance

#92
post #2

When I did web development, I specifically loaded JS lazily so first you got a pure HTML page with just a few lines of code. Those lines of code are normal (not jQuery) JS that loads the rest of the JS lazily in a progressive enhancement. This means the page can start being rendered before the jQuery code loads. But in fact, jQuery is largely not needed since Internet Explorer lost market share and there's less of a…

> jQuery is largely not needed since Internet Explorer lost market share and there's less of a need to have lots of workarounds for it. As someone who's late to the webdev party I feel that jQuery is pretty awesome (all I ever heard is people poopoo it). The vanilla API for the DOM manipulation is just plainly awful and borderline nonsensical so I'd say jQuery is still very much needed.

If you are mainly using jquery for its DOM manipulation¹ rather than for browser compatibility² or things that didn't exist consistently in older browsers³ then there are much smaller libraries that do that job which may be worth looking into. https://github.com/fabiospampinato/cash or https://github.com/franciscop/umbrella to give a couple of examples. Some explicitly support IE11 so you are not dropping as much support for legacy browsers as you might otherwise.

Though if jQuery works for you and isn't a performance issue, then by all means keep with it. It may not be ideal, but good enough and does the job. Let the naysayers spend their time debating whether you should or not, and just get on with making things!

---

[1] selection engine, chained selections, chained modifications, …

[2] not the issue it once was, if you can abandon IE and old Android browsers from your supported UAs or can deal with any issues that crop up individually

[3] again, if you can afford to drop support for legacy UAs

Re: The impact of removing jQuery on our web performance

#93
post #83
post #4

Has anyone noticed how all UK government websites like https://www.gov.uk/ , https://www.nhs.uk/ , https://tfl.gov.uk/ , https://coronavirus.data.gov.uk/ have the same look-and-feel and the same UX? Are there more such examples of countries that have uniform UX for their government websites?

Related and maybe a little OT, but why does Transport for London have to include a big Google Ads banner at the top of the page?

TFL is a "Statutory Corporation" which is funded both by grants from local government and commercial income, the majority from rail+bus fares but also from activities such as advertising. There is a significant quantity of advertising placements provided by TFL, in the stations, on buses, bus stops, and as it seems on their website.

TFL was almost bankrupted by Covid, I for one will give them a pass on the ugly advertising on their site.

However, looking at [0] and [1], advertising only covers about 1% of their budget. That banner ad will be tiny fragment of that.

0: https://tfl.gov.uk/corporate/about-tfl/how-we-work/how-we-ar...

1: https://www.statista.com/statistics/898278/transport-for-lon...

Re: The impact of removing jQuery on our web performance

#94
post #78

Earlier quoted context omitted.

jQuery is more convenient to use than vanilla JS. Vanilla JS is too verbose. If only jQuery was modular and didn't require to load 300 or 400 Kb of code. Also it is difficult to find non-jQuery library of a good quality. For example, I was looking for a small library to send and receive JSON via HTTP, and ended up writing my own wrapper around XMLHttpRequest (fetch() is a poor choice, it is not supported well in olde…

I'm with you on fetch() requests not being able to be aborted, but I didn't think there were any other reasons to use XMLHttpRequest over fetch in 2022. I've been fetch() only for a few years as this point - what older browsers are you targeting that don't support fetch()?

And even then, there are probably fetch() implementations around xmlhttprequest

Re: The impact of removing jQuery on our web performance

#95

Earlier quoted context omitted.

It's nice, but also gets boring and restrive quiet quickly in Governmental organisations I've worked for.

Perhaps. But user expectations are otherwise. Especially when lack of guardrails too often leads to wacky and wonky experiences.

wacky and wonky experiences inaccessible FTFY

Re: The impact of removing jQuery on our web performance

#96
post #14

> Now I know what you may be thinking, that doesn’t sound like a lot of data, especially compared to images which can be multiple megabytes in size. But when it’s on every page, from a web performance perspective, it equates to a lot of data. Er... the utility of jQuery in 2022 aside, I would say: if it equates to a lot of data when it's on every page (of a single website), you're doing something wrong?! I mean, cach…

I was thinking the same. However from the article it seems the issue is actually less with the downloading, but more with the parsing and execution, which is blocking, and has a material impact for users on slow devices.

Re: The impact of removing jQuery on our web performance

#97
post #33

Earlier quoted context omitted.

Yeah but for what? I have been writing vanilla js for years now and aside from the sometimes slightly more convenient syntax I haven't missed a thing where using jQuery would have helped me over not using it. I don't say anything against loading useful javascript libraries, but too many websites load 1 MB of libraries just to get a result that they could have achieved with a few lines of handcrafted vanilla js. This…

jQuery is more convenient to use than vanilla JS. Vanilla JS is too verbose. If only jQuery was modular and didn't require to load 300 or 400 Kb of code. Also it is difficult to find non-jQuery library of a good quality. For example, I was looking for a small library to send and receive JSON via HTTP, and ended up writing my own wrapper around XMLHttpRequest (fetch() is a poor choice, it is not supported well in olde…

fetch() can definitely be aborted, and what "older browsers" don't support fetch? You must be talking maybe about Internet Explorer 11, the only older browser that is still somewhat used (in Japan and public/old infra) that doesn't support it?

https://caniuse.com/fetch

Re: The impact of removing jQuery on our web performance

#98
post #33

Earlier quoted context omitted.

Yeah but for what? I have been writing vanilla js for years now and aside from the sometimes slightly more convenient syntax I haven't missed a thing where using jQuery would have helped me over not using it. I don't say anything against loading useful javascript libraries, but too many websites load 1 MB of libraries just to get a result that they could have achieved with a few lines of handcrafted vanilla js. This…

jQuery is more convenient to use than vanilla JS. Vanilla JS is too verbose. If only jQuery was modular and didn't require to load 300 or 400 Kb of code. Also it is difficult to find non-jQuery library of a good quality. For example, I was looking for a small library to send and receive JSON via HTTP, and ended up writing my own wrapper around XMLHttpRequest (fetch() is a poor choice, it is not supported well in olde…

fetch() requests cannot be aborted

Does {signal} not work yet? https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API#a...

Post reply on HN