
The history and legacy of jQuery - blast
https://blog.logrocket.com/the-history-and-legacy-of-jquery/
======
CM30
There's another reason to use jQuery not included in the article, albeit one
which has lost a bit of relevance in the last few days:

jQuery plugins/extensions/libraries/whatever.

An awful lot of libraries for things like carousels and masonry type grid
systems and other such things are built with jQuery as a dependency, so anyone
wanting to use them (especially to avoid rolling out their own version) is
stuck relying on it.

Fortunately, a lot of these things have either moved to working as standalone
vanilla JS type deals, or to NPM modules instead.

Unfortunately, the latter is argubaly causing the same dependency hell issue,
since many devs will now basically throw in a full JavaScript framework and a
bunch of task builders and managers like webpack just to be able to include
said modules more easily and save on development time/costs.

~~~
doctorpangloss
There’s a difference in quality between these jQuery and NPM (and react
component) things.

jQuery plug-ins often have a certain polish to them that works great on
desktop browsers and rarely mobile, since it’s from an era where the talented
plugin (i.e. component) authors didn’t have mobile browsers as a target.
Whereas react-component feels like it’s authored for Chrome targets (iOS
safari compatibility by accident) since front end devs kind of live in that
DevTools universe nowadays. The npm package community in general is hard to
generalize.

As far as frameworks facilitate people who care about really fine interactions
I’m all for it. It wildly enriched the ecosystem.

Like someone had to figure out all the little interactions that Google and
Apple industrialize (i.e. clone) into their UI frameworks. We just don’t ever
hear about the original authors because they don’t have multi-million dollar
developer relations budgets. So while you’re right that there’s a dependency
hell or whatever high brow engineering problem, we see that with the privilege
that someone at Google is getting paid $250,000 a year to industrialize/copy
the good idea.

~~~
EB66
> There’s a difference in quality between these jQuery and NPM (and react
> component) things.

Yep, you're exactly right, the plugins are from a different era and have less
utility today.

That said, jQuery itself still has immense utility. It's expressiveness and
simplicity are second to none.

The author points to youmightnotneedjquery.com as an example of why jQuery is
superfluous today, but if you look at the examples a bit more closely, you'll
notice problems. I spent all of five minutes glancing through the YMNNJ
example list and noticed their `replaceWith` doesn't provide the functionality
that jQuery offers -- it doesn't take into account event handlers bound to DOM
elements. Also, their `extend` does a shallow merge, not a deep merge.
Furthermore, the YMNNJ examples are often much more verbose and less
expressive than the jQuery examples.

I don't particularly understand the rush to rip jQuery out of everything. It
seems like a lot of people are doing it just because it's the trending thing
to do. There are some things that jQuery does very well -- even in today's
world where modern web dev is dominated by SPA components.

jQuery and SPAs don't have to be mutually exclusive. At my work, we've been
building SPAs with jQuery long before Angular, React or Vue even existed.
Within the past few years we built our own JavaScript SPA framework whose
components can be written with vanilla JS or jQuery. Most of us prefer to use
jQuery for our components because the syntax is often more expressive and
concise than vanilla JS. We open sourced the framework at
[https://github.com/elliotnb/nimbly](https://github.com/elliotnb/nimbly) and
it's state management utility at [https://github.com/elliotnb/observable-
slim](https://github.com/elliotnb/observable-slim)

Our framework core uses jQuery to update DOM nodes with `replaceWith`, merge
deeply nested objects with `extend`, among other things. Aside from the
eliminating the extra 69KB footprint from adding jQuery slim min, we don't see
any reason to rush to rip jQuery out of the framework core. On the contrary,
using jQuery helped us get the framework built faster and helped us keep the
code expressive and easy-to-follow.

Long live jQuery :)

~~~
wolco
I started a project a few weeks ago and decide to use jQuery because someone
on the team didn't know vue and I felt it wasn't worth the effort to convince
them to try it. Use jQuery I'm finding the expressiveness and simple approach
amazing.

The reasons for switching years ago may not apply as much. jQuery was slower
for large amounts of dom changes but browsers have gotten better so this isn't
as much of a concern for a normal website. I didn't get that messy feeling I
would get when pages got too complex like thry would in 2007.. perhaps because
I'm breaking things up differently. That might be because my understanding of
javascript has increased since. Maybe jQuery was never the biggest problem
with bloated frontends maybe I was.

~~~
EB66
Yeah, for smaller sites plain old manual DOM manipulations can work just fine.
You're writing productive code right from the get go. No need to learn the
nuances of a JS framework.

But if the site or web app gets larger, I would want to use an SPA to
eliminate manual DOM manipulations -- for both performance and maintainability
reasons. jQuery still offers great utility in today's SPA world, but
unfortunately the most popular JS frameworks have gone so far into developing
their own domain specific languages and opaque rendering processes that most
parts of jQuery can't be used with them.

I wish more frameworks allowed components to be written in vanilla JS and had
rendering that returned standard DomNodes.

------
Carpetsmoker
_> For example, the Fetch API can replace jQuery’s Ajax functions_

Except that it won't work for ~6% of your visitors (± a few percentage points,
based on your locality and audience).

Some developers sneer at these kind of numbers and comaplain about old
browsers and whatnot. Yeah, it's annoying. But it's also reality, and as a
professional you'll have to deal with it.

 _> The querySelector and querySelectorAll methods replicate jQuery’s
selection capabilities_

The jQuery selectors have quite a bit of extra useful functionality though.

~~~
tcd
> and as a professional you'll have to deal with it.

Yes, by not supporting those users. If you want to use IE 11 that's fine by
me, doesn't mean I need to go out of my way to ensure it works for them.

~~~
Carpetsmoker
As a person for your hobby project or whatnot? Sure. As a business? Yeah nah,
that's not how it works. Imagine turning away 7% of your customers at the door
of your shop.

~~~
yakshaving_jgt
In some industries it's much more than 7%. Luckily once IE11 is EOL (which
IIRC is in January) I'll be able to block requests from that browser, but only
because I can use the argument "this browser is EOL and using it is a security
risk." Not every business has that luxury.

~~~
mythrwy
[https://gabriellaroche.dev/ie11-death-
countdown/](https://gabriellaroche.dev/ie11-death-countdown/)

I really hope you are right about January and this counter is wrong.

In the meantime I'm not worrying about IE anymore (have luxury of not working
at bigco and can say, "sorry, we don't support that").

~~~
JMTQp8lwXL
I very well might be in a management role before I have to stop worrying about
IE 11 directly. This countdown couldn't come sooner.

------
tambourine_man
I never understood why browser vendors went to the trouble of agreeing on and
creating a native alternative to jQuery.

It’s more verbose and everybody has to relearn something they can already do
in more readable and compact code.

Why haven’t they simply adopted jQuery’s APIs?

That ship has long long sailed, but still, I think we would’ve been in a much
better situation right now.

~~~
charrondev
I appreciate the clearer naming of the built in methods.

\- `document.querySelector` vs `$`. \- `element.addEventListener` vs
`$element.on`

JQuery really has some confusing behaviour too. JQuery sets the target of the
event as `this` inside of the method. Native makes it an event property.

~~~
tambourine_man
I hate the verbosity of it. The “fun” part of jQuery is important to its
success.

~~~
partialrecall
Personally I don't see the problem with code that's verbose _in this manner._
If the right names for things are chosen then the code written with those
names will read like prose, which makes it pleasant for a programmer and
approachable for a self-styled non-programmer. And it's not like it's much
more typing, what with modern completion systems in modern text editors...

One of the reasons I like lisp-like languages more than the rest is because
hyphen-separated-symbols are a lot easier to read than camelCase, which feels
cramped by comparison. (underscore_separated_words is an improvement over
camelCase, but for some reason people seem to shy away from it. In any event I
think hyphen-separated is superior, since hyphens are used to conjoin words in
English prose, while underlines typically aren't.)

~~~
Carpetsmoker
I find long names like this much harder to read because the entire text/code
is so much more dense, and it really adds up quite fast if all
function/variables are dense. It gives a "wall of text" effect.

It reminds me of reading 17th century dense English. I don't see how _query_
or _select_ is any less descriptive than _querySelector_.

I find that names are rarely all that useful anyway, since you can't capture
the full effect of a function in a name in most cases. I once named a method
_mkdir()_ and then someone commented that it was "obscure", so it got renamed
_createDirectory()_ , then someone commented that it was actually creating all
intermediate directories, so it became _createDirectoryTree()_. This still
doesn't really communicate that it won't error if the directory already
exists, so I commented it should really be _createDirectoryTreeOrDoNothing()_.

~~~
partialrecall
I'm not sure what you mean by dense. If two symbols mean the same thing (both
reference the same procedure) but one is longer than the other, then surely
the longer one is less dense, no? In physics, density is a measure of _mass /
volume_, so in programming density would be a measure of _meaning / code
length_

`mkdir` is immediately obvious to someone like you or me that has a background
in dealing with legacy system design (namely, any Linux/Unix/BSD/GNU system
that all derives from early 70s design ethos (or hardware limitations..)) but
to somebody who's not already steeped in this tradition, it's basically a
bizarre incantation.

And mkdir is far from the worse of it; once you learn what it means it's easy
to create a mnemonic mapping between _`mkdir`_ and _" m[a]k[e] dir[ectory]"_.
But what about something like `ln`? Obviously that's _" natural logorithm"_,
everybody learns that in highschool. Wait no, it's not that at all. It's _"
[make] l[i]n[k]"_ Frankly, that's crap. Contrast with `make-file-or-directory-
link` from racket. It means the same thing but it's more than 10x as long
(less dense) and there is simply no way you could mistake that for a natural
log function.

~~~
dmitriid
In case of `query` you’d have a uniform API from which all other APIs would
flow. That’s what $ essentially is.

Instead, browser have two incompatible APIs: `querySelector` to retrieve one
item only, and `querySelectorAll` to retrieve multiple items.

On top of that, jQuery always returns an array-like object. `querySelectorAll`
returns a NodeList that is so poorly designed that it didn’t have a `.forEach`
for two years or so, and you’re still better of doing an `Array.from` on it
for the sake of consistency and sanity.

For every thing that jQuery got right, browsers got 10 things wrong. For every
thing that jQuery got wrong, browsers got 100 things wrong. It took browsers
_7 years_ to implement querySelector/querySelectorAll after jQuery showed it’s
possible and useful. And they _still_ got it wrong. 13 years after jQuery
debuted DOM APIs are still a mishmash of extremely poorly designed functions
that are unnecessarily verbose and error prone.

~~~
earthboundkid
This criticism makes no sense. If you always want an Array-like object, just
always use querySelectorAll. If you don't then don't. Why is it bad that the
DOM gives you a choice instead of giving you a pseudo-array that sometimes
acts like an element and sometimes not? The DOM more clearly separates
NodeList from Element than JQuery, and that's good! I agree that not having
forEach by default was a mistake, but it's long since been solved.

~~~
dmitriid
> If you always want an Array-like object, just always use querySelectorAll

`querySelectorAll` doesn’t even return an array-like object. It took w3c
almost two years to add a forEach to it.

It’s also so badly designed that MDN docs has a whole section oh how it
behaves with unexpected results and how, quote “to restore expected behavior”.

So all perceived benefits (like the separation between Element and NodeList)
are badly contrived and trumped by how badly they are designed in comparison
with a 15-year old library whose core API was designed by one person.

------
onion2k
_... and plenty of developers prefer using its API even when native methods
are available._

jQuery is great, and it's still a really useful library in some circumstances
such as supporting _incredibly_ old browsers, but if you're adding 30kb of
weight to a page because you don't want to learn the fetch API then you really
need to rethink how you think about users.

~~~
kroboker
Agreed. I've seen numerous times developers include jquery just to make a
simple request that can be replaced by XMLHttpRequest.

Ref: [http://youmightnotneedjquery.com](http://youmightnotneedjquery.com)

~~~
cm2187
What strikes me with this youmightnotneedjquery is that half of the examples
take many more lines of code than a single jquery instruction.

~~~
archie2
Especially when it comes to browser support...why would I _not_ use JQuery in
those cases?

I still use JQuery to this day, but probably because I don't really rely on JS
in my applications that much. Unless you're building an "app" from the get-go,
it's still my default choice.

------
FreeHugs
I still like to bind $ to querySelector and $$ to querySelectorAll:

    
    
        $  = document.querySelector   .bind(document);
        $$ = document.querySelectorAll.bind(document);

~~~
paulirish
Everyone's got their little snippet but here's my 15-liner that gives you $()
and .on() syntax:

    
    
        $('p').on('click', el => /* ... */)
    

[https://gist.github.com/paulirish/12fb951a8b893a454b32](https://gist.github.com/paulirish/12fb951a8b893a454b32)

------
dmitriid
Counterpoint. “Why I'm still using jQuery in 2019”,
[https://arp242.net/jquery.html](https://arp242.net/jquery.html)

~~~
ausjke
jquery is less verbose than native ES6+ js functions, I'm not a frontend
developer myself, my understanding is react/vue/etc are for SPAs where you
manage lots of states inside the browser locally instead of on the server
side, but majority web-related UI actually does not need that
ecosystem/complexity at all, a bootstrap+jquery can still serve majority of
use cases in my opinion.

I just started working on a dashboard for an embedded network device, and
bootstrap + jquery seems perfectly fine there, and I don't need spend a month
to learn react/vue/webpack/etc and become a js expert before I can do anything
productive.

------
HNLurker2
Nostalgia When jQuery used to be thing everyone used and wanted to learn.

------
amriksohata
I get laughed at by typescript devs for using it, I feel jQuery will stand the
test of time than these frameworks. However wasm will have the last laugh

------
patsplat
babel solves the problem of polyfills in a more elegant manner.

