Everyone here seems to be talking about how great jQuery was for DOM interaction and that's true. But the other thing that was life changing about it was how easy it was to make ajax requests!
But the other thing that was life changing about it was how easy it was to make ajax requests! What's the "modern" alternative to jQuery in that regard? I don't do much JS development, but if I needed to make an AJAX request today, my first instinct would probably still be to use jQuery.
Gov.uk drops jQuery from their front end
331–340 of 458 posts
Re: Gov.uk drops jQuery from their front end
#332Earlier quoted context omitted.
This is a fair criticism of how I chose to tell the story. The line you quoted was supposed to refer to the character introduced in the second paragraph and not to a generic stereotype of aged man. I can see how my choice of wording created an implication that people who have grey beards are old and that it is this oldness that contributes to their unwillingness to learn. The familiar cliche of "you can't teach an ol…
I'm curious: what's replaced Query? I guess it's not a single library, but a set of frameworks...
Plain JavaScript replaced it. jQuery provided useful things at its time, indeed, but JS has been somewhat improved at least and learned the tricks, even improved upon them. JS is still somewhat ugly, but I will give it at least that much. Now one does not really need jQuery any longer for most things, which were done with it. I personally find plain JS API and fetch to be cleaner than jQuery stuff even. People still use jQuery it out of habbit or, because it would be a lot of work to get rid of it everywhere.
Re: Gov.uk drops jQuery from their front end
#333Earlier quoted context omitted.
> is it terribly worse than some other way? Yeah, it's fragile and will easily lead to bugs when someone changes the markup without realizing it's going to break some crazy selector in another part of the code. It would make a lot more sense to just add a class to the element you're trying to select.
it's a conditional select, you're saying just add code to add/remove a class to the target - of course, but that defeats the point of wanting a conditional selector in the first place
The point of selecting an element is to do something with it. How does selecting it by class defeat the point?
Look, if you need this for some one off thing and you've determined it's the best way to do it in this special case, it's not hard to create a function that will find the element you want.
It's not a good argument for using jQuery IMO, because if you're doing this regularly there's probably a better way to do it.
But coming soon™ you will be able to do even this with `document.querySelector`.
Edit: I didn't pay close attention to your second example. I was speaking mostly related to the a:has example before. Your second example seems to be something that would be desired more in CSS than JS, and I don't think it's unreasonable to do that in CSS. If you need to do it in JS you can workaround browser limitations just fine by writing more than one line of code to do the selection and test the condition.
Re: Gov.uk drops jQuery from their front end
#334Earlier quoted context omitted.
I think it's just for brevity, rather than because a helper is needed . OP listed the entire source code of their module in their comment.
Brevity is cool, but that's kind of like naming all your variables one letter chars for brevity. This is something every web dev will instantly know what it does: document.querySelectorAll('#rabbit .green').forEach(tag => { }) Whereas this is something nobody knows what the fuck it is because it's completely non-standard. for (const rabbit of dqsA('#rabbits .green')) { } And get what, 10 characters less in one row? B…
for/of vs .forEach isn't the issue here. Frankly I almost always use for/of because it's implemented for all iterators and I prefer being outside of a function (e.g. I can use await).
All they did was alias `dqsA`. If anything, it's the fn name that could be better.
Re: Gov.uk drops jQuery from their front end
#335Earlier quoted context omitted.
what do you mean by "wasteful"?
Creating an array, populating it with however many elements just to be able to call some methods and destroying it immediately afterwards. And doing it all over the app, just because it's syntactically convenient. (all while you already have an iterable collection in the form of NodeList)
It is a bit weird to consume an iterator into an array when a NodeList is already iterable.
Not sure why it caught on.
Re: Gov.uk drops jQuery from their front end
#336Earlier quoted context omitted.
You can extend HtmlElementCollection prototype with any methods you like. (it's NodeList, btw, what's returned from querySelectorAll)
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.
Re: Gov.uk drops jQuery from their front end
#337When 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…
Your examples (while beautiful) are fairly different from each other.
The assembly tricks got obsoleted because they're not needed anymore - we simply don't program in that hardware anymore.
jQuery still works fine to this day. It's just that engineers don't like it anymore. The same will happen to React in a few years.
I wouldn't hire a jQuery developer for working in a cushy company with their millions and their React codebases - React knowledge is actually one of the things we test for (and, unexplainably, one of the few exceptions we'll allow to avoid knowing about algorithms and time complexity).
If I had to build something with my money on the line, I'd definitely pick the jQuery veteran.
Re: Gov.uk drops jQuery from their front end
#338AFAIK (I'm not a front-end dev but tried some) vanilla JavaScript has much of the things jQuery provided built-in nowadays yet they look much longer. Now as JavaScript accumulated a lot of legacy stuff only kept for compatibility + also numerous verbally/syntactically sub-elegant APIs IMHO it is time to design a language which would simply be "better JavaScript" - clean, modern and elegant yet have no fundamental dif…
> design a language which would simply be "better JavaScript" - clean, modern and elegant yet have no fundamental differences JS' problem is that it is fundamentally not "clean, modern and elegant". It was designed in a couple of days. And all the greatness that's added to it nowadays is done in a much better design process than at it's inception, yet some choices made at it's inception can never be reversed. I've wr…
AFAIK Elm can not be considered "a better JavaScript" because it not only is fundamentally different, it also is not fully self-sufficient - in many cases you have to resort to JavaScript pieces while engineering an Elm app.
Re: Gov.uk drops jQuery from their front end
#339Earlier quoted context omitted.
It was just a reference to the person in the story, not an allusion to "because he was old he didn't try to update his knowledge/continue learning".
So why describe him as a "greybeard" then? It are you claiming to have met many younger and/or female 'greybeards'? If your answer is that 'it's just part of the story'. Well that's precisely the complaint.
It's 2022. Men can get pregnant and women can have a beard.
Greybeards is an inclusive term and it's a well known term.
Re: Gov.uk drops jQuery from their front end
#340Earlier quoted context omitted.
> But to me, they are like the old grey beard who didn't update his knowledge as the times changed. Maybe it's just me but with all the rampant age discrimination nowadays in tech, I really don't like to see the continued propagation of this stereotype. All sorts of people of all ages are unwilling or unable to update their knowledge of new tech, there is no reason to link this characteristic to someones advanced age…
This is a fair criticism of how I chose to tell the story. The line you quoted was supposed to refer to the character introduced in the second paragraph and not to a generic stereotype of aged man. I can see how my choice of wording created an implication that people who have grey beards are old and that it is this oldness that contributes to their unwillingness to learn. The familiar cliche of "you can't teach an ol…
IMHO this analogy doesn't really click, on multiple levels. Any old timer who uses jQuery surely is also aware of querySelectorAll and friends. There's even an entire website dedicated to catering to exactly that transition[0]. I don't think anyone defending jQuery is doing so out of a sense of hubris towards outdated knowledge, but rather because it ironically is more lightweight than a lot of the modern SPA craze, while still being more ergonomic than vanilla JS.
To try to shoehorn this back into the compiler analogy, modern frameworks would be like the advanced, complex and opaque compiler, and the grey beard is the guy that understands how stuff like HTML streaming and font download prioritization and hidden classes affect performance, whereas the team lead is analogous to the run-of-the-mill bootcamp grad that knows how to use the framework-du-jour but is way out of their depth if venturing outside the comfort of the framework and into the depths of those advanced topics.
And I think the gov.uk use case here might actually be an outlier in the sense that it actually considers performance of an already tight codebase, whereas a lot of jQuery deprecation efforts bring with them heavier alternatives in the name of maintainability or developer productivity or hiring or whatever. To be clear, many of these concerns are quite valid, but it seems a bit disingenuous to create a false dichotomy between understanding of low level concerns vs concerns about SDLC management. They aren't mutually exclusive.