Hacker News Reader

Comment by rob74 | Hacker News Reader

> 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, caching content between different domains is not a thing anymore, but on the same domain jQuery should only be loaded once?

View on HN

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 is not just about performance, but every piece of code you add increases the attack surface and the number of moving parts that can fail. Not that every webpage has to be minimalist and barebones, but there are tradeoffs to be made and too many people just import the whole world, their neighbour and their dog without a second thought.

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 older browsers and it has no advantages, and fetch() requests cannot be aborted) because there was no good library for this. Other libraries either do not support all necessary browsers or are overengineered and too large.

>If only jQuery was modular and didn't require to load 300 or 400 Kb of code.

JQuery's own site says the library is 30 to 40 Kb, not 300 or 400. The minified JS file I downloaded of the latest version is 87 Kb, so I assume the rest would be taken care of with zip headers.

Are people routinely serving the uncompressed version of the library?

Agree. Plus one can use a cdn to increase the chances of the library being already downloaded.

Won’t work

Browser caches are partitioned by origin so if a.com and b.com both use jquery from c.com then two copies of jquery will be cached one with a key of a.com/c.com and another with b.com/c.com

Have browsers always done this?

I thought and heard that using a JS library from CDN is beneficial when users already have that same cached JS library from visiting other sites. But you're saying that's not a thing? So what's the benefit of using a CDN for jquery then?

No, they have not always done this. But the supposed caching benefits of CDNs have always been overstated.

Safari has done it for a long time, Chrome and the others more recently.

Even back in 2012 people were raising the question of whether shared caching of libraries from the public JS CDNs was effective — due to too many different versions in use, and content being evicted from the browser cache sooner than most expected

Ok thanks for explaining. I wasn't aware of the changes. I don't mind at all, it just means I'll avoid using CDN hosted JS libraries from now on.

Browsers have started doing this because it’s a security issue. If a some libs load fast, the app can fingerprint or guess which website you were on before.

It seems that you are right, the 300Kb number is about an uncompressed version. Still it is very large and includes lot of code I don't need.

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

Internet Explorer and older browsers support is important too. You must support browsers released within last 10 years and fetch is too new and experimental for this. I don't want to use something just because it is new and has no clear advantages over older technology.

Microsoft dropped support for IE in June 2022. https://caniuse.com/fetch shows that fetch() is now at 96.99% support for global users.

If you still need to support old IE you can use a library like https://github.com/github/fetch

fetch doesn't support upload progress

https://javascript.info/fetch-progress

> Please note: there’s currently no way for fetch to track upload progress. For that purpose, please use XMLHttpRequest, we’ll cover it later.

coming soon (2020) https://ilikekillnerds.com/2020/09/file-upload-progress-with...

This is outdated, all modern browsers support fetch cancellation, look up `init.signal`. it wasn't available from the start, but at this point it's supported everywhere.

"Fetch cancellation" is where the browser tells itself "Stop trying to make 'fetch' happen," right?

> Browsers have started to add experimental support for the AbortController and AbortSignal interfaces (aka The Abort API), which allow operations like Fetch and XHR to be aborted if they have not already completed. See the interface pages for more details.

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API#a...

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

I work on a site that gets a small percentage (less than 0.1%) views from iOS 10 devices, which doesn’t support fetch. This still amounts to a few dozen views.

Since the gov.uk page is talking about 2G users, I'd imagine that "old browsers" here means "whatever Nokia shipped over a decade ago"

2G users can include “users on the latest iPhone or Samsung who are in Scotland”. Try https://www.o2.co.uk/coveragechecker and look at Kinlochewe for an example.

From that page, it appears that older versions of Android Chrome don't support fetch at all.

I've seen stats that indicate that 5% of the U.S. population (to say nothing of other parts of the world) are still on Android Oreo (version 8), which wouldn't surprise me since older phones are basically locked in time.

Unlike on iOS, I don't think the browser version is tied to the operating system anymore? Besides the AOSP browser that no one uses

No, you're correct, but you're missing the point; what version of Chrome is on Android 8? Because it's definitely not Chrome 104, which apparently is the earliest version that supports Fetch, according to CanIUse.

fetch() requests cannot be aborted

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

> If only jQuery was modular and didn't require to load 300 or 400 Kb of code.

It is? You can use grunt to make your own version, excluding the parts you don't need.

That's why I wrote "the utility of jQuery in 2022 aside" at the beginning. Of course, if you don't need it anymore, you don't have to think twice about removing it, but their statement is overinflating the cost of having jQuery (or any other dependency) on your site.

jQuery was actual worth it about 15 years or so ago when browsers were far less compatible and Javascript compliant than they are now. The juice isn't worth the squeeze now, though.

The article goes on to explain that they are optimising for extremely low spec devices used by financially and socially disadvantaged users. The majority of their users load pages in less than 1s (likely due to caching and connection). Some users take 25s or more to load a page. It is for these edge cases they were testing.

If they're concerned about financially and socially disadvantaged users perhaps the place to start helping those people would be on the universal credit login page which currently delivers 100+ kb of javascript for a couple of form fields.

They're testing against a hypothetical user on a 2G cellular connection. I can't see many situations where that would happen. Being poor doesn't mean you can't afford 3G because every data plan in the UK includes 4G as a mimimum. Often 5G is included too. You have to be extremely rural to drop down to 2G and rural people are often better off. Poorer people tend to be in urban areas that have better digital infrastructure.

I think it is a great mindset to try to be as inclusive as possible. It might actually improves everyone’s experience.

You're conflating having a 5G connection with a 5G connection running fast. Now, I live in the US, so maybe the UK has much better infrastructure, but cell phone internet service can be slow anywhere. I've had that 5G link with full bars in the middle of a city and could barely pull anything. The difference with me having money to spend is I can easily do any number of things about it, such has have a different internet service at home, or pay to stay get something in an internet cafe while 'working from home'.

Sounds like you live in a big city? In the rest of the UK, there are many many places, even in large towns of 100k+ people, where the mobile signal is absolutely terrible. Whether it's 4G or not doesn't matter if the signal is too weak to sustain a reasonable speed.

They're testing against actual RUM data collected from the site and linked in the article.

The article is talking more about the execution time to read, parse, and execute the library -- that isn't cached at all.

Seems like the writer hasn't heard about the trick of putting js at the bottom of the page, or the async html5 tag. Looks like the had jquery in the head section on every page. That's not really jquery or javascript's fault.

The writers are Matt Hobbs and Andy Sellick, respectively Head of Frontend Development and Senior Frontend Developers at GDS. They may have considered alternative options.

Here's a previous article explaining why they did what they did:

https://insidegovuk.blog.gov.uk/2022/08/11/how-and-why-we-re...

That article doesn't address the point raised: their placement of jquery in the head of page was likely the cause of the performance issues more than the presence of jquery.

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.

Loaded from the Internet once.

So it's cached, but the browser still needs to access and load the file! :)

Maybe they have a bundle per page and it's in each one: https://www.npmjs.com/package/jquery

Reply on news.ycombinator.com