Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The impact of removing jQuery on our web performance

insidegovuk.blog.gov.uk

Post reply on HN
Print view View original

261–270 of 283 posts

Re: The impact of removing jQuery on our web performance

#261

Post by eastbound »

exodust wrote: post #209
youngtaff wrote: post #151

Earlier quoted context omitted.

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?

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.

Re: The impact of removing jQuery on our web performance

#262

Post by tofuahdude »

eastbound wrote: post #259
tofuahdude wrote: post #249

Earlier quoted context omitted.

React's core functionality is to manage the relationship between state and the dom. jQuery lets you imperatively manipulate the dom. They're different use cases; calling one useful and the other not isn't a very accurate representation.

No, React’s strength is to componentize your webapp, allowing several teams to work on objects that can be reused by each other.

Sure, it does that too, but that is not its runtime purpose.

Many, many approaches solve organizing your code; React is in the middle of a large pack here.

Re: The impact of removing jQuery on our web performance

#263

Post by fleddr »

phyzome wrote: post #224
fleddr wrote: post #154

The team at gov.uk is doing an excellent job regarding web performance, credit where credit is due. In many ways role model behavior. Still, the results are such a stretch as to not have that much meaning. They have to descent all the way to 2G to see any meaningful difference, and I'm assuming they are cold visits (typical in lab-based testing). For those exceptional users, this creates a difference from very poor (…

Governments have an obligation to serve all of their citizens, even those on 2G or similarly slow connections. They can't just say "eh, well, we don't want them as customers anyhow".

Where did I say otherwise?

Re: The impact of removing jQuery on our web performance

#264

Post by gunapologist99 »

derkades wrote: post #253
gunapologist99 wrote: post #228

Earlier quoted context omitted.

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.

Re: The impact of removing jQuery on our web performance

#265

Post by joshstrange »

6510 wrote: post #256
peterangular wrote: post #252

Earlier quoted context omitted.

Ah yea you're right - I misspoke. Vanilla JS feels verbose, and jQuery feels more terse in regards to general syntax. --- document.querySelector('#sel').addEventListener('click', (e) => {}) Feels way more verbose than the following: $('#sel').on('click', (e) => {}) My bad - apparently the coffee hadn't sunk in yet ha.

OT note: sel.onclick=e=>{} works just fine. https://jsfiddle.net/39h5ynga/

But only if you (and any libs you use) only plan on adding 1 click handler to an element. That's why I always opt for the addEventListener/on style vs setting the onclick/ondblclick/etc handlers.

Re: The impact of removing jQuery on our web performance

#266

Post by throwaway0asd »

randombits0 wrote: post #254
throwaway0asd wrote: post #227

Earlier quoted context omitted.

> Performance matters, a lot. Developers really don't care. They will claim otherwise with great conviction, but its all posturing and bullshit. If developers did care they would measure everything and challenge popular assumptions. Instead most developers want to randomly guess at what works and instead talk about tools. That's why most pages will never come close to being vaguely fast. 9 seconds is still really slo…

The folks who pay developers get what they pay for. Management sets priorities, not developers.

I don’t buy that at all. There is a world of difference between poor performance due to low prioritization and lying about it.

Re: The impact of removing jQuery on our web performance

#267

Post by jiggywiggy »

neysofu wrote: post #47
jiggywiggy wrote: post #43

Earlier quoted context omitted.

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

> Boring I feel like that's a great quality. As for restrictive, that's a valid concern.

Wait till you work with the team, and they decide to make all highlighted colors like a an extreme warning sign because "accesiblity" and 10 other dramatic choices and they prefer to be dominant debaters "I decide and you listen to me because you are not part of the team" instead of any reason.

Re: The impact of removing jQuery on our web performance

#268

Post by mmcnl »

ctrlmeta wrote: 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?

Yes, The Netherlands.

Government: https://www.rijksoverheid.nl/

Tax service: https://www.belastingdienst.nl

Corona dashboard: https://coronadashboard.rijksoverheid.nl/

Student loans: https://duo.nl/particulier/

Re: The impact of removing jQuery on our web performance

#269

Post by strokirk »

peterangular wrote: post #252
zerocrates wrote: post #246

Earlier quoted context omitted.

> Vanilla JS is terse comparative to jQuery short-hand syntax, especially for simple event bindings. You mean "verbose" here, probably?

Ah yea you're right - I misspoke. Vanilla JS feels verbose, and jQuery feels more terse in regards to general syntax. --- document.querySelector('#sel').addEventListener('click', (e) => {}) Feels way more verbose than the following: $('#sel').on('click', (e) => {}) My bad - apparently the coffee hadn't sunk in yet ha.

It's even more verbose in a lot of common cases, actually. (Although the ? operator has made things better).

---

1. document.querySelectorAll(".sel").forEach((e) => e.addEventListener("click", (e) => {}))

$('.sel').on('click', (e) => {})

2. document.querySelector(".sel")?.addEventListener("click", (e) => {})

$('.sel').on('click', (e) => {})

3. const e = document.createElement("div") e.className = "cls" e.setAttribute("title", "Title") e.textContent = ""

const e = $('').addClass("cls").attr("title", "Title").text("")

Re: The impact of removing jQuery on our web performance

#270

Post by nobleach »

fleddr wrote: post #258
nobleach wrote: post #245

Earlier quoted context omitted.

Has anyone been able to reproduce this "Google Research" that is so often quoted? They have numbers related to conversion too. I know I'm sounding doubtful but bringing response time down a second or so isn't a magic potion for more money pouring in the door. Not that anyone should ignore performance. It's irresponsible to ignore perf. I just know from experience, when buying something on Black Friday at Amazon, if t…

The Google Research that is often quoted might have been well intended, but is grossly overstated and misused. The thing with bounce rate is that you don't know WHY the user bounced nor did you know their intent. Typically analytics aren't even loaded yet. Sure enough I believe there to be a correlation forming as you dramatically increase page response time, but you still cannot attribute a high bounce rate to perfo…

At the time that those metrics were being thrown around, Google was knee-deep in pushing AMP. They visited us at Overstock several times to cajole us into using it with cries of, "will you please consider your users in less fortunate countries on less than stellar networks". That's fair I guess. We reduced our bundle size to 185k. They still tried to convince us to use AMP. We travelled out to Sunnyvale for a hackathon at the Googleplex, they were pushing AMP all over the place. AirBnB were the only folks willing to stand up and flat out say, "because AMP is terrible". (side story - I realize)
Post reply on HN