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

271–280 of 283 posts

Re: The impact of removing jQuery on our web performance

#271

Post by partiallypro »

croes wrote: post #69
magnio wrote: 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…

I'm afraid there won't be anything like that in Germany any time soon.

It exists but I think it's undeniable that Germany is behind in many digital aspects, even in advertising. I think part of that is cultural (credit card acceptance and advertising being good examples) and another part existing bureaucracy.

Re: The impact of removing jQuery on our web performance

#272

Post by randombits0 »

throwaway0asd wrote: post #266
randombits0 wrote: post #254

Earlier quoted context omitted.

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.

“I don’t buy that at all.”

That’s my point.

Re: The impact of removing jQuery on our web performance

#273

Post by exodust »

awestroke wrote: post #234
exodust wrote: post #223

Earlier quoted context omitted.

There's a JS library called New Stuff? For me, I use Jquery because it works. Light and low impact. Syntax is good for readability.

jQuery has its own syntax?

https://www.w3schools.com/jquery/jquery_syntax.asp

Re: The impact of removing jQuery on our web performance

#274

Post by exodust »

youngtaff wrote: post #257
exodust wrote: post #209

Earlier quoted context omitted.

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?

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.

Re: The impact of removing jQuery on our web performance

#275

Post by awestroke »

exodust wrote: post #273
awestroke wrote: post #234

Earlier quoted context omitted.

jQuery has its own syntax?

https://www.w3schools.com/jquery/jquery_syntax.asp

That's the API. Syntax is something completely different: https://en.wikipedia.org/wiki/Syntax_%28programming_language...

Re: The impact of removing jQuery on our web performance

#276

Post by awestroke »

zach_garwood wrote: post #216
awestroke wrote: post #172

Earlier quoted context omitted.

Try new stuff every once in a while. You might be surprised

Try old stuff every once in a while. They still work. You might be surprised.

I've worked with a lot of technologies over the years. Some I still consider to be good, others I am happy to leave behind. jQuery is in the latter camp.

I have worked with these technologies professionally:

- Vanilla js targeting ie5+

- jQuery

- MooTools

- Angular

- KnockoutJS

- virtual-dom

- React

- Typescript

I've also tried out a handful more in my spare time, like Vue, Preact, and Elm.

If your list does not include any modern stuff, then your opinion is worth zero to me, because your reference for what's good is horribly outdated. If your list matches or exceeds mine, and you still prefer jQuery, then I'll be bewildered but at least your opinion is interesting.

Re: The impact of removing jQuery on our web performance

#277

Post by branko_d »

nobleach wrote: post #245
GuB-42 wrote: post #188

Earlier quoted context omitted.

12 seconds down to 9 seconds is not negligible. What is negligible is 12 down to 11.999 seconds because you prematurely optimized. And even for "normal" users, shaving milliseconds matter. The general idea is that a UI should respond within 100ms to feel instantaneous. More than 1s and you interrupt the flow of thought. According to Google research, increasing page load time from 1s to 3s increases bounce rate by 32%…

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 IBM researched this in the late ‘70es and reached broadly the same conclusion. They were talking about “productivity” instead of “bounce rate” back then, but the basic biology of attention span and working memory is the same.

He and Richard P. Kelisky, Director of Computing Systems for IBM's Research Division, wrote about their observations in 1979, "...each second of system response degradation leads to a similar degradation added to the user's time for the following [command]. This phenomenon seems to be related to an individual's attention span. The traditional model of a person thinking after each system response appears to be inaccurate. Instead, people seem to have a sequence of actions in mind, contained in a short-term mental memory buffer. Increases in SRT [system response time] seem to disrupt the thought processes, and this may result in having to rethink the sequence of actions to be continued."

“The Economic Value of Rapid Response Time”

https://jlelliotton.blogspot.com/p/the-economic-value-of-rap...

Re: The impact of removing jQuery on our web performance

#278

Post by 7steps2much »

proto_lambda wrote: post #158
quintussss wrote: post #139

Earlier quoted context omitted.

Austria: https://design.austria.info/en/design-system/

Of all the examples in this thread, this is the only one that isn't a plain HTML page, but rather a pile of javascript that takes several seconds to load and shows nothing but an "enable javascript" banner without JS. Despicable, but also absolutely typical. Edit: alright, CZ, UA and RU further down the thread are the same, I just hadn't gotten to those yet. Still, absolutely unacceptable for a government design stan…

This isn't even a government design standard (or government website for that matter). If looking into the impress you will find that it is run by a Verein that's promoting tourism. To quote:

> Promotion of Austria as a holiday destination.

There is a corporate design guide available [0] but from what I can tell it's more of a guide for "everything" not just websites.

[0]: https://www.bundeskanzleramt.gv.at/service/corporate-design....

Re: The impact of removing jQuery on our web performance

#279

Post by exodust »

awestroke wrote: post #275
exodust wrote: post #273

Earlier quoted context omitted.

https://www.w3schools.com/jquery/jquery_syntax.asp

That's the API. Syntax is something completely different: https://en.wikipedia.org/wiki/Syntax_%28programming_language...

We can safely use the word syntax in this context without offending programming languages. You seem overly concerned with latching "syntax" to a tightly controlled definition. Perhaps you should google "jquery syntax" then contact each website informing them of your objections.

Re: The impact of removing jQuery on our web performance

#280

Post by 6510 »

joshstrange wrote: post #265
6510 wrote: post #256

Earlier quoted context omitted.

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.

true but I would hope the libs use the event. (one onclick is still allowed in combination)

This approach seems the funniest: https://jsfiddle.net/eu60Lwv9/

Post reply on HN