
Ask HN: Is jQuery on its way out? - enjoyz
Due to the proliferation of many advanced JS libraries such as React and Angular, do you think jQuery is on its way out? Is becoming good at jQuery a waste of time?
======
interlocutor
The best advertisement for jQuery, ironically, is this site:
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/) Look at
how simple things are in the left column, and how much more code is needed in
the right column.

jQuery has many convenience features such as chaining, for example:
item.addClass('selected').siblings().removeClass('selected'); and you don't
have to check for nulls after each selection.

Many functions such as closest() and remove() have no equivalents in IE11, and
other things such as replaceWith() and before() are not available even in
Edge.

For simple sites it is easy enough to remove jQuery, but for more complex
javascript applications, especially apps that have a lot of interactivity,
removing jQuery will result in more code, or you will end up writing a lot of
utility functions thereby creating your own little clone of jQuery.

~~~
nostrademons
That site is from 2012. It defaults to IE9, and the latest version of IE
listed is IE10, which was EOLed in 2016. replaceWith() and prepend() are
included in Edge 17 (released Apr 2018).

A modern version of youmightnotneedquery with, say, features currently
supported by 90%+ browsershare would be even more concise. The AJAX JSON
request in the first example, for example, is just:

    
    
      fetch('/my/url').then(response => response.json())
    

The Request example is:

    
    
      fetch('/my/url').then(response => ...).catch(error => ...)
    

The fadeIn example is (CSS3, not JS):

    
    
      @keyframes fadeIn {
        from { opacity: 0 }
        to { opacity: 1 }
      }
      #el { animation: fadeIn 1s linear; }
    

(It gets even easier if you're fading in on hover or other user action,
because you can use a CSS transition instead of the animation and then just
use .classList.add()).)

------
FPGAhacker
Feel free to disregard this advice, I don't do anything in javascript.

Whether or not it's worth becoming good at jQuery is essentially determined by
your goals in life, and whether becoming good at jQuery in particular, is in
alignment with those goals and also of high importance.

Any time you spend honing one skill is time _not_ spent honing another. You
want to be sure to spend your time on the _most important_ things. Figuring
out what is important itself becomes a skill to learn.

Pinging HN on whether it's worth learning jQuery is one way to assess
importance. But keep in mind, if the people who answer have different goals
than you, their answer may not be relevant and may actually be bad advice for
your case. This answer included.

Figure out your goals. Find people who have accomplished them. Talk to them
directly about what they did and how they did it. Adapt what makes sense to
your life.

Finally, be careful of learning something just for the sake of learning. It
feels great, but it can actually be procrastination in productivity's
clothing. Make sure you are clear on why you are spending the time learning X
right now, and be clear on why you are _not_ spending time on learning Y right
now.

~~~
exodust
Sure, but one can learn a great deal about Jquery in a short time. It's more
accessible than the frameworks mentioned in OP.

------
montroser
Affirmative. It's not just that there are advanced application frameworks like
React and Angular -- it's also that browsers are more standards compliant, and
standard APIs have evolved in recent years to cover much of the gap that
jQuery once usefully filled.

~~~
montroser
I made a diagram of the way I think about it here:
[https://plectica.com/m/ADUNN80H4](https://plectica.com/m/ADUNN80H4)

When you map it out like this, the answer seems obvious that the place to
invest your time is in learning the standards.

~~~
exodust
Jquery selectors are still more powerful, even if vanilla is faster.

There's more options, more possibilities. The selectors are a core part of
Jquery's strength. As soon as your project requires a bit more complexity in
selector needs, that's when Jquery steps up and helps out. That's what I've
found anyway.

------
jawns
Not a perfect analogy, but PHP was on its way out for a while and probably
would have gone all the way out -- if it had not been for one very high-
profile company that essentially made it usable at scale. And the reason it
did so was because even though PHP had little cachet, it was easy to hire PHP
devs.

Similarly, there are now a lot of things you can achieve with vanilla JS (or
even vanilla CSS) that you used to only be able to achieve with jQuery, and
frameworks like React and Angular are viewed more favorably. But lots of devs
of a certain age know jQuery, even if they don't currently use it, and there
is something to be said for familiarity. Honestly, if I needed to whip
something up in a day, I would probably use jQuery rather than a heavier
framework.

~~~
gjmacd
I would argue that Facebook's work had little impact on the "scalability" of
PHP. I don't see people adopting HipHop (HHVM) in huge numbers. The problem
with PHP was it's standards body wasn't doing a good job of keeping the
language consistent and it lacked a package manager where Ruby, Python and
Node all had solid standards bodies and it was driven by having package
management.

With Composer that changed and it appears now they are doing a much better job
of standards and changes to the language.

With that said, it's not a concurrent system. It's blocking and that's a
problem for modern Web languages.

I do think PHP growth is on the way down... but slowly.

~~~
no1youknowz
Actually HHVM had a huge impact. Having competition is always a good thing. It
forced the devs to go into overdrive and improve the product.

What came out of it was PHP 7 and the gap closed significantly. There were
even rumblings about a PHP JIT complier. So I would say the impact was a good
one.

As for PHP growth, what's there to replace it? Golang, Exlir, Node, Crystal,
Ruby, Python? They all have their own pros and cons.

With laravel being a great framework and much easier for developers to use
rather than symfony. I would say the future of PHP has never looked better.

------
rocky1138
Becoming good at jquery is a waste of time, yes, unless you have inherited a
legacy project built in it.

Jquery's strength was in its polyfills for older browsers for selecting
elements and the like. Since it's introduction, browsers have pretty much
replaced all of jquery's functionality intrinsically.

~~~
exodust
If learning a bit of Jquery (which is not hard) helps you get something from
concept to client's screen faster, then it has its place.

> _browsers have pretty much..._

No, there's a bunch of selectors and methods that are much easier to work
with, read and write using Jquery, IMHO.

------
m0llusk
It is quick and easy to access and work with the DOM using jQuery. Both React
and Angular are heavyweight libraries that require a lot of bondage and
discipline to work as intended. React is from and linked to Facebook and
Angular is from and linked to Google. Both of these social media ad companies
are broadly considered to be corrupt and potentially best broken up by force
of law. There is not particular corporate agenda or threat of breakup hanging
over jQuery.

This idea of software tools being on the way out is a slippery one. Perl and
PHP are both broadly considered to be somewhere between slipping and no longer
relevant, yet a close look shows there are still many commercial sites and
actively developed frameworks built using those tools. Popularity and recent
trends alone are not necessarily a robust guide to utility or futures.

~~~
ncallaway
> It is quick and easy to access and work with the DOM using jQuery

I think the actual medium-term risk to jQuery is not the heavyweight
alternatives that you identified. It's that browsers are much better and
providing standard and consistent API support for many necessary DOM
interactions.

When I need a lightweight solution, I find myself using MDN documentation more
often than jQuery documentation. For me, jQuery was much more about providing
a single API that was usable across a wide array of browsers. That's less
necessary today than it was a decade ago.

All that being said, I don't think jQuery will die out anytime soon. It still
has a niche that it can usefully fill for a long time, and still has a _ton_
of existing dependencies that rely on it.

------
cannedslime
Yes its on its way out. I don't think learning it is a waste of time if you
touch legacy stuff. jQuery still does some things better than DOM, but if all
you need is XHR and css selectors, you don't need it anymore.

Popular component frameworks such as bootstrap still uses jQuery.

~~~
camhart
[https://github.com/twbs/bootstrap/pull/23586](https://github.com/twbs/bootstrap/pull/23586)

V5 won't.

~~~
cannedslime
Good news :)

------
DanHulton
Honestly, yeah. Whereas in the past I would reach for jQuery for low-effort
"spicing up" of a webpage with javascript, now I reach for Vue. It's very easy
to just include Vue in the header, plop down a bit of markup, a bit of JS, and
you're on your way, plus it offers a bridge from there into a more full-
featured Vue application. It's almost as lightweight as jQuery, and it's not
work you have to "undo" later if you wanted to work towards a SPA or more-
advanced functionality.

------
citrusx
There will always be a use for jQuery. Just not _every_ use. If you're looking
to make simple, imperative changes to the DOM in a web page, and not worry
about what browser it's happening on, it's still the go-to choice.

Yes, you can use the native API for some of what jQuery does. but, don't let
anyone here fool you - the full API of jQuery has not been completely replaced
by the "vanilla" API. And, jQuery's API is still much better designed.

Now, if you're building something Very Large, you don't want to lean on jQuery
alone. If you're using a framework whose footprint includes what jQuery does
(anything with a virtual DOM and automatic updates, for example), then there's
no point in also using jQuery.

There's room for all of the tools. Use the right one for the right job. Do
enough front end development, and you'll know which one to pull out when you
need it.

------
luhn
I think jQuery is still a relevant tool for building dynamic
websites—animations, carousels, pop-ins, etc.

However, for building SPAs, jQuery has been eclipsed by Angular and React. And
thank god for that, jQuery was always an ill-suited tool for the job. Even bad
Angular applications are better than good jQuery applications, in my
experience.

~~~
Theodores
> I think jQuery is still a relevant tool for building dynamic
> websites—animations, carousels, pop-ins, etc.

I think that vanilla and CSS3 is a better option. Ten years ago there weren't
the options. Now all browsers are up to speed and standards compliant there is
not the need. It takes less time to learn how to do something properly the
vanilla than it does to hack older jQuery code into shape for one's own use
case.

If I do something the vanilla way I feel as if I have learned something. When
copying and pasting some jQuery module I don't get that feeling.

~~~
rejschaap
You could take some time to understand jQuery it is not that big or
complicated. It might be on its way out, but it will be around long enough to
be worth the effort in my opinion.

------
tmm84
If catering to older browsers, developers that aren't familiar with JS
build/release tools or the latest fad/buzz then jQuery is still viable. jQuery
used to be the easiest way of getting things done but now it is more of a
tool. I loved jQuery but I have seen it abused so bad that it has become a
design smell if the page/service gets too big. If you are doing simple things
then jQuery will be ok but if it is a really complex page/site then using
something like Vue or React may be appropriate just for ease of diagnosing
problems/reasoning.

------
sehugg
GitHub has a good post on removing jQuery:
[https://github.blog/2018-09-06-removing-jquery-from-
github-f...](https://github.blog/2018-09-06-removing-jquery-from-github-
frontend/)

I still include it because I'm lazy, and it largely plays well with
TypeScript.

------
stunt
Becoming good at jQuery is reasonably quick and easy. If you have a use case
for it, Yes! Why not? (ex: legacy stuff)

Is it a valuable skill? Well, probably not! But not because of React or
Angular, only because being good at jQuery is easy. Which makes it a less
valuable skill and that is why I said if you have a use case for it.

Not to mention, a big part of jQuery success was the short learning curve.
While simplicity is its strong point, it is also what makes it less valuable
as a skill.

Unlike back-end technologies, front-end technologies have a shorter lifespan.
Because of all the design evolutions, redesigning, and front-end optimizations
and refactoring which is more accessible and less resource hungry for many
businesses. So keep that in mind that probably you are not going to use jQuery
in any customer-facing new project.

------
jtokoph
I think it’s worth learning FROM jQuery.

[https://youtube.com/watch?v=i_qE1iAmjFg](https://youtube.com/watch?v=i_qE1iAmjFg)

[https://youtube.com/watch?v=ARnp9Y8xgR4](https://youtube.com/watch?v=ARnp9Y8xgR4)

------
networkimprov
I use Vue[1], luxon[2], markdown-it[3], Vue Form Generator[4], and a localhost
"backend" written in Go. (No browser-local storage, thank goodness.)

I started this project one year ago; Jquery never crossed my mind for it.

[1] [https://vuejs.org/v2/api/](https://vuejs.org/v2/api/)

[2] [https://github.com/moment/luxon](https://github.com/moment/luxon)

[3] [https://github.com/markdown-it/markdown-it](https://github.com/markdown-
it/markdown-it)

[4] [https://github.com/vue-generators/vue-form-
generator](https://github.com/vue-generators/vue-form-generator)

------
m33k44
I recently made a decision on the following front-end stack:

\- Bootstrap 3.x

\- jQuery

\- KnockoutJS

because of the following reasons:

\- The devices that will be accessing the web app may have older browsers,
both desktop and mobile.

\- My users will be in geography where network connection is sometimes slow.

\- These libraries have been in the wild for very long time and time tested
with lot of support available on public forums.

\- Very easy to get started.

\- As I am not primarily a front-end web developer, I am not in a position to
handle various quirks of different browsers; if libraries such as bootstrap,
jquery and knockoutjs handle that for me for older devices and browsers then
it is useful.

If I had an option to go for a more modern stack, then I would have gone with
svelte.technology, unpolyjs and bootstrap.

------
drinchev
Well my litmus test regarding outdated way of doing stuff is the answer of the
question "If I start a new project today, would I use 'x'?". Answer "no" means
the technology is fading even for simple use cases.

Example, 'x' and 'No'-answer :

\- jQuery / prototypejs / etc...

\- Backbone

\- CoffeeScript

\- Perl, SVN, Java Applets :D

On the other hand you still have 'Yes'-es for some old tech-stack, since it is
still acceptable to do a task with old technology. Example, 'x' and
'Yes'-answer :

\- Form + POST requests / No javascript

\- Pure CSS ( no SCSS, etc... )

\- Handlebars, instead of React / Vue / you name it

------
exodust
Only you can decide what tools are best for your projects. Jquery is
javascript. It's a clever tool that often results in better, clearer, readable
syntax.

Creative devs or "mid level" front-enders like myself enjoy its clean syntax
and reliable operation. I am VERY thankful for Jquery in how it helped me
understand and execute more difficult concepts, and complex interfaces, and
gave me opportunity to make better things beyond my vanilla abilities.

------
oblib
I still use jQuery and won't be ditching it anytime soon.

End users don't know or care if an app uses it or React/Angular/Vue.

I've built SPAs with it and don't see why that's a problem for others who've
mentioned it, but that's because I don't know what specific problems they ran
into. I've not run into any.

But, I also use CouchDB as a backend, almost all my app code is JS running in
the browser, and I don't use Node.js at all. I still do my server side work in
Perl. So I'm not building apps like most are right now.

React/Angular/Vue, etc, might work better for some apps, and/or apps with a
zillion users hitting the server a zillion times, but my apps don't have
either of those issues to deal with. They barely touch my web server or the
CouchDB. All the heavy lifting is done in the user's web browser.

The only real downside to that design approach, if we choose to call it that,
is that we don't track every click a user makes, but as a user I really like
knowing that.

The best thing about going with jQuery is I didn't really have to learn how to
use it. I do that on a need to know basis and generally go to Stackoverflow
where I almost always find the best way along with a few other ways to do
something.

I'll offer that using a "much smaller, lighter weight library" offers a kind
of a false sense of gain. You can use Service Workers to cache jQuery on the
client side, or a CDN to deliver it, so it's not really costing you much (or
any) bandwidth to deliver it to users, and modern web browsers are not choking
on the size of it. I test my apps on a old Raspberry Pi running their latest
OS and Chrome and they're plenty fast (very fast).

Here's the thing. I spent about two months looking for the "Best" way to build
apps. Most of that time was going over frameworks at TodoMVC.com. When I was
finished I didn't have any better idea of what was best than when I'd started,
but I did have a clue about what I'd have invest to get up to speed with them,
and in most cases it was lot.

So, I decided to instead explore what was the easiest way, and not just for me
really, though I don't expect anyone should agree, but just generally speaking
I tried to consider that.

I use the Apache web server and CouchDB, PouchDB.js, jQuery, and Bootstrap.
It's a pretty amazing feature set those tools provide, and how easy they are
to use together.

Almost no one I know does it this way.

~~~
kbenson
Most my work is generally in Mojolicious (with or without an Nginx instance
proxying and providing SSL support, but I've found with Nginx easier), jQuery
and Bootstrap. A while back I bit he bullet and learned a bit of Vue... and I
have to say, it's pretty nice, even if I just use it as a way to build the
page.

The main thing it provides is a sane toolset for what I was already slowly
moving towards, which was templates in script tags (grabbed through jQuery),
and my own home rolled templating in JS (it's just a few lines for something
minimal). I get some JS from the server (or serve it on the page), and use a
JS class to build the representation for display, but this allowed me to
easily build the initial page and also get updated without a complete page
reload and reliably update the page.

Vue is basically the same thing, but taken a few generations farther. You have
a data structure, you define how to build the HTML from the data structure,
and Vue tracks the data so if you change one five levels deep in the data
structure, the page just updates accordingly (and it only updates the things
that change, so half entered forms/text boxes don't lose all their state.

It's nice to just have to serve JSON, or a minimal HTML page with some JSON
data in a script tag. No mixing Perl templating, and HTML, and JS anymore. At
least for a select few new things I've deployed. It's not like I can just
replace everything. I also forego the whole NPM and deployment stuff, and just
include Vue with a script tag, and write my components either on the page, or
in a JS file (or set of files) I can load, depending on whether the components
have any use outside the page I'm writing them for. Dead simple.

If you haven't tried it Vue (and you very wel may well know everything I just
mentioned about it already), I suggest you do one of the quick online
tutorials to get an idea. It's actually a pretty cool idea (and since it's
hard to get away from using JS anyway, you at least get to cleanly separate
the front-end from the back-end).

------
gridlockd
> Due to the proliferation of many advanced JS libraries such as React and
> Angular, do you think jQuery is on its way out?

Absolutely.

> Is becoming good at jQuery a waste of time?

Unless you are going to be maintaining legacy code, yes.

------
Someone1234
I'd argue Lodash/Underscore.js is a direct comparable to jQuery rather than
React/Angular.

jQuery is likely diminishing but its death has been somewhat overstated.
There's at least two areas that hurt jQuery:

\- IE11 is disappearing for consumers (less so in corporations/governments)

\- ECMAScript 6 now offers enough conveniences so jQuery isn't as "mandatory"
as perhaps it once did.

We still use jQuery with AngularJS, but we also need to support business users
so our IE11 share is significantly higher than most consumer sites.

------
ilovecaching
Well hopefully Javascript will be on it's way out thanks to WebAssembly. Any
tool that fills a critical gap in a worldwide ecosystem should be admired, but
at the end of the day every tool should eventually be replaced as we evolve
the craft.

jQuery filled a niche when browsers were less standardized and the DOM was
harder to work with. It also came about at a time when people were just
starting to play with the idea of web apps, and people could get away with
less structured approaches to web design.

------
flashgordon
Actually I still feel jQuery is still an amazing lib (and philosophy)
precisely because it is not an all or nothing tool. I recently (as a non
webdev) found myself overwhelmed with react/vue. I simply chose to go jQuery
with decent modularization of components and got the job done. Now yes my
"modularization" will asymptomatically look more and more like React as I
consider the more and more usecases that React supports, but the learning
curve is pretty for me.

------
neals
I think for creating a messy Proof of concept, or creating a simple tool with
minimum UI and complexity, I will always be grabbing JQuery. It's just so
simple and I've got all of it memorized for so long...

Which makes me curious, actually, how basic can you get with Vue and React? I
only know the large "boilerplate" versions with Redux and bells and whistles.
Anybody prototyping on React/Vue/Angular?

~~~
gridlockd
React itself can easily be used as a drop-in much like jQuery, but then you
will be using plain Javascript syntax, which is a bit less readable than JSX.

If you're planning to use JSX, you'll need a JSX transpiler and before you
know it you're down the Webpack/Babel rabbithole and you get a node_modules
folder containing a zillion packages written by a thousand people, of which -
statistically speaking - at least a handful will be clinically insane.

But yeah, in principle you can do it (and I have done it).

------
vatotemking
Angular and React is not what competes with jQuery. Its VueJS. Why? Because
unlike React and Angular, you can use Vue in small dosages, ala jQuery. You
dont need to write the entire HTML part as JS or JSX. Just insert Vue in parts
you want to make "dynamic".

My current setup is to use Vue for interactivity and frontend axios for ajax.
Works pretty well. No compiling/transpiling needed.

------
valeriobo
Yes, we deprecated it many years ago, only used for select2 and datetime
picker. People should learn the browser nowdays, not jquery

------
bluejay2387
There is also the option of using a much smaller, lighter weight library to
handle ajax (where the standard based approach still has some limitations) and
using standards for everything else.

jQuery was an amazing step forward but it's almost always better to use
standards based options and those are now available for much of jQuery's
functionality.

------
no1youknowz
You forgot to mention Vue. ;)

I would say it's done. ES6 javascript replaces a lot of its functionality as
well.

I switched from jQuery to Vue/ES6 (last March) and would never contemplate
switching back. The difference is like night and day.

The next stage I'm thinking about is moving over to TypeScript for more
productivity and safer development.

~~~
gridlockd
> The next stage I'm thinking about is moving over to TypeScript for more
> productivity and safer development.

Check this out if you haven't already:

[https://github.com/Microsoft/TypeScript/wiki/Type-
Checking-J...](https://github.com/Microsoft/TypeScript/wiki/Type-Checking-
JavaScript-Files)

Even if without any annotations, type inferencing can catch some bugs for you.

------
therealmarv
Sometimes you want some simple "glue" for very simple dynamic web pages /
effects (e.g. Jekyll homepages). In my experience JQuery is the best for that
followed by Vue.js by adding a one liner and then you can start using it.

------
darepublic
I would say everything jquery does is now supplanted by a better alternative.
So unless you need libraries that depend on it I would not include it in any
new project.

------
samgranieri
If you work on legacy stuff, you'll need to be able to at least modify jQuery.
Newer stuff and greenfield projects won't use it.

------
jorshman
Jquery still strikes me as being much faster to get up and running than react.
Is the issue it’s speed compared to vanilla js?

~~~
isostatic
jquery is something you can throw in quickly onto a page and have a few useful
helper functions.

Not everyone is building web applications, sometimes we just want a simple
tool to do a single job.

------
_davebennett
I recently used jQuery to parse an XML file. Easier than vanilla JS

