Live data from Hacker News

Gov.uk drops jQuery from their front end

web.dev

451–458 of 458 posts

Re: Gov.uk drops jQuery from their front end

#451
post #272

Earlier quoted context omitted.

> I think of this story whenever I see jQuery popup on Hacker News. There is always a strong contingent of devs who swear by this library. But to me, they are like the old grey beard who didn't update his knowledge as the times changed. At one time jQuery allowed them to be the hero and "Get Things Done" faster than their competition. But times have changed. Whenever I want to use "vanilla JS" I use jQuery, because I…

Yes as a "greybeard" i noted first that the headline performance gain was 10% & 11% this for a team given far more time and resources to optimize for their goal than most teams or individuals dev. I raised an eyebrow at that However devs seeking employment should always be prepared to play up to what is trending vs what is appropriate.

[deleted]

Re: Gov.uk drops jQuery from their front end

#452
post #241

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…

Amusingly, I always joke that I'm fluent in jQuery, but no absolutely no javascript. As a mostly backend go/python/non-javascript developer that has always held true. It is just a tool in the belt for an engineer. Can you use jQuery in 2022 or later to solve really amazing problems that impact user experience? You sure can! Would you be better off to use a modern javascript variant and stuff like react instead? You a…

[deleted]

Re: Gov.uk drops jQuery from their front end

#453
post #241

Earlier quoted context omitted.

Amusingly, I always joke that I'm fluent in jQuery, but no absolutely no javascript. As a mostly backend go/python/non-javascript developer that has always held true. It is just a tool in the belt for an engineer. Can you use jQuery in 2022 or later to solve really amazing problems that impact user experience? You sure can! Would you be better off to use a modern javascript variant and stuff like react instead? You a…

While I think that’s the right choice, I’d just like to point out that the problem with jQuery today is it was a library built to smooth over and fix differences between browser JavaScript engines (IE, well, IE). Over the past 15 years or so browser JavaScript engines, except at the extreme edges, are roughly comparable. Further, a lot of the features of jQuery have been adopted into standard JavaScript. So, the reas…

[deleted]

Re: Gov.uk drops jQuery from their front end

#454

Earlier quoted context omitted.

It is a bit weird to consume an iterator into an array when a NodeList is already iterable. Not sure why it caught on.

Usually it’s because you want to use an array function like .filter() that isn’t implemented by the iterable itself.

[deleted]

Re: Gov.uk drops jQuery from their front end

#455
post #433

Earlier quoted context omitted.

Alright, we seem to be talking past each other. Maybe that's the sign this is not a productive discussion. I'm not calling jQuery is bloated or difficult to read, nor I am telling anyone they should count bytes. > Is going to be a couple of one-liners? No, because jQuery hides a lot of complexity under it's relatively simple API that take a lot of JavaScript to reproduce. > It's not crazy that to accomplish what jQue…

You might be right about the discussion. But I was thinking about this and I think my point comes down to the basic issue of almost every library or big piece of software. Nobody uses 100% of any big library. Nobody uses 100% of Microsoft Word. Most people use about 20%. But the problem is everyone uses a different 20% so libraries and software have a lot of features. The argument against jQuery is thus an argument a…

> The argument against jQuery is thus an argument against libraries in general.

Then it's a nice thing that I never made any argument against including jQuery or any library in a page or project, nor I'm saying anyone should reimplement it, or even do anything. I'm not talking about those things.

> Would we even by having this discussion

We aren't even having this discussion. Seems like you're having an argument against an imaginary version of me. I'm not saying (or implying) the things you are arguing against.

Re: Gov.uk drops jQuery from their front end

#456
post #455

Earlier quoted context omitted.

You might be right about the discussion. But I was thinking about this and I think my point comes down to the basic issue of almost every library or big piece of software. Nobody uses 100% of any big library. Nobody uses 100% of Microsoft Word. Most people use about 20%. But the problem is everyone uses a different 20% so libraries and software have a lot of features. The argument against jQuery is thus an argument a…

> The argument against jQuery is thus an argument against libraries in general. Then it's a nice thing that I never made any argument against including jQuery or any library in a page or project, nor I'm saying anyone should reimplement it, or even do anything. I'm not talking about those things. > Would we even by having this discussion We aren't even having this discussion. Seems like you're having an argument agai…

Your argument is that is that body is going to re-implement all of jQuery with their own helper functions. I got that. It's just not a very interesting point. Was I using hyperbole -- yes. You got me.

Re: Gov.uk drops jQuery from their front end

#457
post #436

Earlier quoted context omitted.

I'm also one of those guys that will always spread NodeLists (and other iterable-but-not-array type of objects) but it's really only because I find functional style a lot more readable than imperative style for loops. It might be iterable, but if it doesn't have map/filter/reduce and friends, might as well not be for me.

NodeList.prototype.filter = Array.prototype.filter; and you can querySelectorAll('...').filter(el => ...) without any copies. ditto for other mentioned functions. Prototypal nature of Javascript is there for a reason.

In every single project or company I've ever worked on/with, monkey patching was _extremely_ frowned upon (for good reasons). Also, how would you be able to filter without any copies? you'd at least be forced to make one. filter is _not_ supposed to mutate anything. so you'd have to create a new Array and/or NodeList, and put the filtered values back in. Even then, doing all this stuff for what is effectively one single copy that is likely to be insignificant at a performance level is, in my opinion, excessive. I just copy once and make the code clearer.

Re: Gov.uk drops jQuery from their front end

#458

Earlier quoted context omitted.

My understanding is that mutating built in prototypes is very bad. Not just for interop reasons, but because doing so really hinders many optimizations javascript engines perform.

Adding methods to prototypes is effectively free. The only time mutating a builtin prototype has negative consequences is when you replace a builtin function with your own thing. All javascript engines (that I'm aware of) JIT at the method level so there's not really a performance impact modifying a prototype.

Ah, I think this is what I was thinking of: https://developer.mozilla.org/en-US/docs/Web/JavaScript/The_...

It seems this only pertains specifically to overwriting the __proto__ of an existing object (the is the prototype of other things).

Post reply on HN