Live data from Hacker News

Gov.uk drops jQuery from their front end

web.dev

191–200 of 458 posts

Re: Gov.uk drops jQuery from their front end

#191

We found it to be about 32kb gzip+minified in our builds. I just dropped it from one of our apps, where it wasn't even used except in a legacy logging module. We replaced the ajax call with XHR. The other app we maintain has it as well, again only for the ajax method. While it may be nice, for large production apps we'll take the filesize gains where we can find them.

I believe it's kind of sad that in the days of 2 TB USB sticks that 32kb matter.

Our product is used by all sorts of devices and resources. Many use it on super old hardware in different countries. 32kb isn't much, but when you're analyzing Time To Render metrics, you might be surprised how little is necessary to move the needle.

That said I don't expect a massive impact from this change, but removing unused code is going in the right direction.

Re: Gov.uk drops jQuery from their front end

#192
post #93
post #71

Earlier quoted context omitted.

There is .forEach() on NodeLists, so you can do stuff like this in every browser, no lib, no helper functions needed: document.querySelectorAll('a').forEach(tag => { // operate on tag })

how's browser support for something like "a:has(img[src$='.gif'])" though?

For more advanced queries than standard CSS selectors provide, XPath is also supported by every browser and available via document.evaluate() (which is not eval() by the way)

https://developer.mozilla.org/en-US/docs/Web/XPath/Introduct...

Re: Gov.uk drops jQuery from their front end

#193

When I first started programming I was pretty lucky to get a job at a games company. My first lead was a veteran who had shipped a lot of AAA titles and he loved his war stories. He was personally interested in performance and he would often cite hardware timings for specific cpu instructions. One story he told a couple of times was about some grey beard who was before his time. The grey beard was once a legend in th…

While I agree to some extent, jQuery is so prolific online [0] there will always be jobs for those “grey beards” who know it well. There will always be legacy codebases that make extensive use of jQuery that will never be rewritten and are too important to retire.

jQuery is the new Cobol!

I’m not a “grey beard” but I’m currently doing a freelance project updating the UI on a Perl+jQuery site… As much as we would like to rewrite it from scratch it’s very unlikely to ever happen, it’s going to be maintained as is with small steps towards “modernisation” over time.

0: jQuery is used by between 15-40x more sites than React depending source:

https://www.similartech.com/compare/jquery-vs-react-js

https://w3techs.com/technologies/comparison/js-jquery,js-rea...

Re: Gov.uk drops jQuery from their front end

#194

I still use jQuery for frontend JavaScript when I can. It's so much more efficient than native JavaScript. I can't imagine anyone prefers to write document.getElementById('element').style.display = 'none' rather than $('#element').hide();

I am not against jQuery but if it's just verbosity then it's quite easy to:

const $ = document.querySelectorAll.bind(document)

Then later:

$('#element').whatever

I used to be a big proponent of jQuery especially in the heyday of shims and browser hacks, but in the last few years I find it often gets in the way of what I'm trying to do. Now that the native browser APIs are maturing and relatively consistent, having direct access to the objects and their properties is simply more predictable than having to second-guess a layer of abstraction that does the same job but differently.

I have to remember, what does jQuery's .hide do again? It doesn't just set display to none or visibility hidden. Give it a duration, and it will use the style attribute to manipulate the display, width, height, opacity, padding, margin, etc. Then it leaves some style properties behind. Ugh. Do I really want to do all that stuff? Do I really want to build my UI framework around jQuery so I can avoid annoying transition artefacts?

Not hating on jQuery. Just my own experience. I used to feel liberated when using it because browser APIs were so terrible but now I feel encumbered if it's included as a dependency on a project I'm forced to work with, because it does so much black box magic. If you avoid certain things and stick to what it does well then it's not bad, but then there's no point using it because what it does well is no longer a pain point in browser APIs.

For me the main thing it excelled at was DOM selection and manipulation. Native does that just as well now. The secondary benefit was animation, which these days native CSS can go a long way without excess verbosity, and if you really need a more feature rich animation library I've not come across any better than Greensock for getting the job done, even if it does have a paid tier, though I am sure there are dozens of other libraries equally suited for animation, the point is that is not jQuery's strength either.

Anyway circling back to what you were saying, efficiency-wise, for any complex animations jQuery isn't the best tool for the job. For DOM manipulation native can be just as easy with some sugar. It can do a lot of unexpected and hidden things most people aren't aware are happening, so many bugs and time wasted realising jQuery was messing with style attributes that break an otherwise well designed layout.

I would rather write a few characters more code or a couple of lines more to have direct control over what's actually happening. That seems more efficient to me.

Edit: Ok on reflection I guess I am against jQuery, but I don't hate it. Using it these days just feels like trying to figure out how to get it to do what I want to the underlying APIs, when I could more easily and predictably just be manipulating the APIs directly.

Re: Gov.uk drops jQuery from their front end

#195

This article says makes 2 competing claims A) jquery deals with inconsistent browser implementations, largely in older browsers B) replacing it with modern API calls made the website more usable for all users including those on older machines (and presumably OS’s) I don’t see how to square those.

The older browsers which shaped jQuery’s design aren’t in use any more but you’re still paying for the code which now largely duplicates built-in features. For example, if I use querySelectorAll I’m using the browser’s native CSS parser and getting a native NodeList back - all of the work is being done in some of the most optimized C++/Rust code in existence. If I use jQuery, there’s a lot of code which has to parse that selector, build data structures, etc. and some of that is working around limitations which haven’t been an issue since IE6 was released. It’s not as bad as a full virtual DOM, there are a lot of smart optimizations there but it’s still running a lot more non-native code & memory which inevitably adds up on a large project. On older devices with less RAM and memory, this is a lot more noticeable - especially if those are Android devices which started at half the equivalent iOS performance when they were new.

The other problem you get is common to a lot of frameworks: it’s good that you can get a lot done but that means you can get s lot further without learning how it works underneath and by then you don’t want to revisit all of that code. This is especially easy to miss when your developers all use fast systems - React 3+ orders of magnitude slower isn’t noticeable on your $5k MacBook Pro but it might be when your grandfather tries to use that site on his 2011 PC, and by then you probably don’t want to do a messy refactoring on a large codebase.

Re: Gov.uk drops jQuery from their front end

#196

Earlier quoted context omitted.

The problem is that most of the "abstractions" provided by jQuery are no longer abstractions and can frequently be replaced with simple alternatives that are directly provided by browser APIs that have extremely wide support. https://youmightnotneedjquery.com/ is a handy illustration of this.

I fail to see how replacing 1 line of jQuery with 10 lines of plain js is simple. Sure, you don't use those 10 lines all over the place, you write a function ... but then aren't you just recreating jQuery?

Yes, and if you continue long enough you end up with one of the many jQuery alternatives, like mine:

https://umbrellajs.com/

Re: Gov.uk drops jQuery from their front end

#197
What's more convenient

$.getJSON('/my/url', function(data) {

});

or

var request = new XMLHttpRequest(); request.open('GET', '/my/url', true);

request.onload = function() { if (this.status >= 200 && this.status

  }
};

request.onerror = function() { // There was a connection error of some sort };

request.send();

?

Re: Gov.uk drops jQuery from their front end

#198
post #119
post #93

Earlier quoted context omitted.

how's browser support for something like "a:has(img[src$='.gif'])" though?

You probably shouldn't be making that query, unless you're doing something specific like web scraping and don't have control over the content of the site.

That's always been the blessing and curse with JQuery. It allows you to easily filter objects but it doesn't encourage efficiency.

A lot of people don't have control over the content of their site in enterprise situations. If you're stuck using an old framework or CMS you could be beholden to someone else. And at the same time there's a lot of devs who dgaf and just ship what works.

Re: Gov.uk drops jQuery from their front end

#199

What's more convenient $.getJSON('/my/url', function(data) { }); or var request = new XMLHttpRequest(); request.open('GET', '/my/url', true); request.onload = function() { if (this.status >= 200 && this.status } }; request.onerror = function() { // There was a connection error of some sort }; request.send(); ?

Why not use fetch?

Re: Gov.uk drops jQuery from their front end

#200

Earlier quoted context omitted.

I believe it's kind of sad that in the days of 2 TB USB sticks that 32kb matter.

Our product is used by all sorts of devices and resources. Many use it on super old hardware in different countries. 32kb isn't much, but when you're analyzing Time To Render metrics, you might be surprised how little is necessary to move the needle. That said I don't expect a massive impact from this change, but removing unused code is going in the right direction.

Removing large chunks of unused code feels refreshing, that is true.
Post reply on HN