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.
Gov.uk drops jQuery from their front end
451–458 of 458 posts
Re: Gov.uk drops jQuery from their front end
#452When 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…
Re: Gov.uk drops jQuery from their front end
#453Earlier 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…
Re: Gov.uk drops jQuery from their front end
#454Re: Gov.uk drops jQuery from their front end
#455Earlier 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…
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
#456Earlier 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…
Re: Gov.uk drops jQuery from their front end
#457Earlier 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.
Re: Gov.uk drops jQuery from their front end
#458Earlier 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.
It seems this only pertains specifically to overwriting the __proto__ of an existing object (the is the prototype of other things).