Tangential, but sometimes I see people say that jQuery is dead/failed. While it's not as popular anymore, I think that's actually the perfect evolution for it. jQuery was making up for browser API shortcomings, and now many of those shortcomings have been addressed and been incorporated into browser APIs (not everything, but quite a bit).
> jQuery was making up for browser API shortcomings
While this is true, I can still code circles around frontend developers using vanilla JS.
The decline of jQuery is mostly due to the rise of webapp frameworks like React and Vue. But if you are tasked with adding like, a button to a static webpage, jQuery is still the king.
I never really knew jQuery besides the five things that I googled, so once I had to do more "dynamic" frontend things I just looked into Vanilla JS and it kind of works for me. Not sure if I had WTF-moments besides the normal "this seems to be how things work" stuff, so I think it's easy enough?!?
Only thing I always have to look up is how to make sure my script is executed once everything is done and not before and "ready()" is obviously easier than adding an event listener to "DOMContentLoaded". Yeah, had to look it up for the comment.
Simplifying interaction with the DOM is obviously a huge feature of jQuery. But also the functions are just very nicely laid out with the assumption you are doing web stuff.
$(thing).doThis() is just so perfectly terse and understandable for what it's doing. Not just writing, I find jQuery to be very, very easy to understand and read.
>The decline of jQuery is mostly due to the rise of webapp frameworks like React and Vue.
Partly. Frameworks like Angular/React/Vue are a necessary byproduct of building and maintaining large codebases. But the fall of jQuery was largely a result of a more standards approach in mainstream browsers (said another way: deprecation of IE and not needing to work at maintaining consistent behavior across browsers), as well as adding traditional jQuery-like features to vanilla JS.
There really isn't a big use-case for jQuery anymore, although I will remember it fondly.
>While this is true, I can still code circles around frontend developers using vanilla JS.
My first use of jQuery was in the dark days was building UIs (with things like drag and drop, etc) that had to run on Internet Explorer and Netscape. We'd started with "vanilla" but were ending up with what was effectively two separate codebases. Moving over to jQuery let us eliminate a massive amount of duplicate code and dramatically increased our productivity.
When people have said this to me in the past I would trot out a list of features that were still useful, but there are one or two where I think the defaults are backward. There was a long time between when "jQuery is dead" and parent selectors of any kind existed, and list comprehension is still a huge miss.
I still wonder occasionally if there's a place for a library that works like a strict subset of jQuery, but with different error/empty set handling defaults. Especially with list comprehensions. I found that 9 times out of 10 if I run a selector I'm expecting results, and jQuery will silently eat that error, requiring a bunch of inline error handling in the 'interesting' paths in your code. I'd be much happier with an optional parameter for silent failure or even writing the occasional try/catch.
I really don't get this discourse, jQuery API is much more ergonomic, concise and clearer than the DOM api. Sure you can do it but that doesn't mean you should
I think it's a bit of both. jQuery served the purpose of making web development more sane back in the day by handling all browser quirks. Part of that was the nice syntax.
I personally have tried to drop jQuery, but truthfully, its syntax is just much easier to use. Nowadays, I use Cash https://github.com/fabiospampinato/cash to give me the nice syntax without the bloat. It strikes the perfect balance for me.
> I personally have tried to drop jQuery, but truthfully, its syntax is just much easier to use.
It's not just the syntax, it's also the expression-heavy and chained API which makes it much more flexible. As well as the set-oriented approach, which can lead to performance issues if you're not careful but is generally extremely enjoyable.
The DOM is an extremely procedural, plodding API, you need to name everything because you always need to set attributes and call non-chainable side-effecting APIs, not to mention the fecking NodeList which has to be converted to an array to do basically anything useful (in part because Javascript never really embraced iterators, and instead uses arrays for everything still).
I guess you could mitigate that with an "API adapter", but...
Although writing jQuery is still shorter (And likely will forever be).
Editor (like vscode) nowadays is much more smarter then the era.
A lot of API with long names is no longer a issue to type. You just mark the variable as a element. After that, autocomplete handles the rest for you. Shorten the gap with experience of using jQuery. If developer tools is still as dumb as that era. I would think the transition is impossible.
And there are also more frameworks to enhance experience of style modification or templating. Back to then, there are only some dumb template that do initial rendering. But framework these days also handles update for you. So you don't really need to modify it directly by yourself unless in some edge case.
I did a javascript project targeting web/blackberry and early ios. We used jQuery to smooth out the kinks (or that's what our lead told us). It worked as expected.
Went from disliking it to really liking the syntax. Its pretty clear and easy to use, which is why I still use it. We don't use it extensively becaue we're still on the "submit form, get page back with javascript graph and data tables table, development model. We probably should transition to a framework, but they evolve so quickly ...
Is not the same thing as it is a Element method, not NodeList one, so you will would need to map it instead. Because NodeList doesn't have the .map method you would also need to transform it to a Array first.
So the actually drop-in replacement of `$(foo).closest(bar)` would be something like:
That's not exactly the same, I don't think, because jQuery will give you all the `ul` that are closest to `.sth`, not just the first. You'd have to write a loop over the list returned from `document.getElementsByClassName('sth')` to get the same behaviour (because it doesn't look like the standardised `closest` works on lists.)
are we doing CORS? Adding headers? If it is just a one-off fetch, I'd probably long-hand it. If I intended to be fetching from many endpoints, I'd probably write a tiny little abstraction. I'm not exactly keen on loading a 30kb lib (gzipped) so that I can write (maybe) fewer lines for data fetching. Especially considering jQuery's async requests don't conform to the fetch standard. (They reject on 404s)
Hah. My first "web apps" were CGI scripts back in 1995. I know enough about the DOM to know that it sucks: document.getElementById is too verbose. I can either define my own function as a shortcut, or use a standard approach for the same. jQuery is that standard approach.
I think that the improved vanilla js is now "satisficing" for more people. Their threshold of ergonomic usability has been achieved and they stop looking:
