Hacker News Reader

Comment by codedokode | Hacker News Reader

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.

View on HN

>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?

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.

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.

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.

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.

fetch() requests cannot be aborted

Does {signal} not work yet? 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.

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()?

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...

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

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

> 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.

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...

Reply on news.ycombinator.com