
Why I'm still using jQuery - UkiahSmith
https://arp242.net/jquery.html
======
sgift
> In my experience server-side generated templates lightly sprinkled with
> “progressive enhancement”-style JavaScript are still the best way to do
> that. Those apps are easier to develop, tend to be faster, tend to have
> fewer bugs, and your laptop’s fan won’t wake the neighbours.

Thanks for that part. Really. A heartfelt thank you. Every time I see another
"hey, I only want to show you text, but for some reason I thought using one of
the modern js frameworks for it is a good idea" pages I feel years older.
Instead of showing me text using html they pack that text in js on the server
(it usually exists in an html compatible form already), then they shove that
JS down the connection, then my browser has to interpret the JS, so it can get
the html, which it then has to interpret too. And then, finally, I see my
text.

And because all of this is so slow we get techniques like "server-side
rendering". The first time I read about server-side rendering I didn't
understand what it was: so, you produce the html on the server. And send it to
the client. Yes ..? What is the new part? Why is this something that people
present as the next savior of the web?

This is some special kind of madness and I wonder when it will stop.

~~~
candu
This is the part that often gets forgotten in these discussions: it shouldn't
be "SPA for everything" vs. "vanilla HTML / CSS / JS for everything"; rather,
we should be using the most appropriate set of tools for the job.

I've worked on simple static sites, for which I typically lean more on vanilla
HTML / CSS with a sprinkling of JS as recommended here. I've also worked on
heavy-lifting applications, for which the limitations of this approach quickly
become evident; in those cases, I use reactive component frameworks like Vue
and React.

But there's also approaches in between! For mid-complexity sites / apps, I've
used vanilla HTML / CSS / JS, with some additional Python / Makefile plumbing
to generate more repetitive parts. I've also used hybrid approaches, where
vanilla HTML / CSS / JS is used for more static parts of the site and Vue is
used for more dynamic parts. You can use Vue in full-on SPA mode with "server-
side rendering"...but you can also just generate HTML server-side as you would
have before, then progressively enhance parts of it with Vue / jQuery /
whatever.

I've also used "unfashionable" frameworks like Spring before, simply because
it met the client's available in-house expertise. As developers, it's
incumbent upon us to step back, assess the task / team / environment at hand,
and pick tools accordingly.

~~~
andrei_says_
AT&T’s website account pages only serve static html. But they are rendered by
js and I have to wait looking at a loader after every click.

Why is that?

Why do so many static websites and blogs use SPA technology for all their
pages?

It can’t be that it’s just to make _me_ mad (although it works). Are people
insane? How does spending 10x the $ and effort for a worse result make sense?

------
JaTochNietDan
I'm heavily inclined to agree with this. In fact, only this weekend I was
working on a very simple one page tool and from the get-go I decided to adopt
this "vanilla" only approach, i.e no JS libraries really at all.

Pretty quickly I found myself wishing I had just used jQuery or at least some
other library to make stuff easier and get things done faster. When I finally
got it completed in the end I wasn't sure why I bothered to struggle and waste
so much time instead of just including jQuery and making things a bunch easier
and less verbose. Sure, there may be other libraries worth using instead but
the point against the "vanilla JS is all you need" argument.

I actually found the cited website in this post
[http://youmightnotneedjquery.com](http://youmightnotneedjquery.com) to be so
strange as examples of why you may not need jQuery that it may be satire. I
was surprised to find out that it was not satire. So I actually forked it and
created [https://youmightneedjquery.com](https://youmightneedjquery.com), on
which I may change some text in the future. It may not load for you yet as the
DNS propagates.

You can find the fork on my Github account here:
[https://github.com/JaTochNietDan/youmightnotneedjquery](https://github.com/JaTochNietDan/youmightnotneedjquery)

I'll make some changes later to show the satirical nature of it.

~~~
indocomsoft
You have some pretty unidiomatic JS in there. For example:

Array.prototype.filter.call(document.querySelectorAll(selector), filterFn);

What's more idiomatic is document.querySelectorAll(selector).filter(filterFn)

The same holds for forEach.

I suggest you look into how javascript prototype based OOP works

~~~
Carpetsmoker
.filter() is not a method on the NodeList though, it only has forEach(), and
even that is quite recent.

This is why people convert it to an array, and one of many reasons the
standard JS API (and the DOM one in particular) are annoying to work with.

~~~
52-6F-62
There are still more idiomatic methods you can use, ie:

    
    
        [...document.querySelectorAll(selector)].filter(filterFn);

~~~
jrandm
That's a significantly newer syntax, so I wouldn't say it's "more idiomatic"
than explicitly referencing the original function on the prototype (which is
idiomatic to JS) and was the way to do it until the spread proposal,
Array.from, and similar additions, what, ~5 years ago?

If anything isn't that code _less_ idiomatic in that it's less specific to JS
and more of a generic operation?

~~~
52-6F-62
In this instance I understood it to be idiomatic as it calls a JS Array
constructor and iterates on the passed parameter to create it. It's been more
common than the call/apply methods for years—at least as far as I've seen. The
use of the array literal is always preferred, AFAIU.

~~~
jrandm
I agree it'll probably become the new idiom in JS, but it probably needs
another few years to begin taking over from the idiom that existed for decades
before (and still works).

If you've seen that more common than call/apply for years then you probably
work almost exclusively on new projects, with people that convert things to
bleeding-edge, or with heavy transpilation: The spread operator as used there
has only existed in regular released browsers/node for 3-4 years. I don't
think it's a stretch to say the vast majority of code out there at this time
won't be doing it that way.

~~~
52-6F-62
Yeah could be. And my client base, as it were, are solely internal to the
company I work for at this time and we have some knowledge and some
cooperation over what versions of browsers people are using when it comes to
web-based software. So support for older systems is largely unnecessary. That
and building node backends the ES version doesn’t affect them anyway.

Definitely colours my work, and knowledge base.

------
pier25
To give you an idea where I come from... I started doing front end in the late
90s, and for the past 5 or so years I've been mostly doing SPAs with Vue,
React, Inferno, and Angular.

I'm done with SPAs and the whole modern front end workflow. If there was a
solid benefit to a SPA it would make sense to endure all the complex
development, ever changing ecosystem, etc, but in the vast majority of cases
there is no benefit. Users don't care about SPAs, some of the most successful
biggest websites are not SPAs (Amazon, Ebay, Wikipedia, etc).

A static site generator like Jekyll with some sprinkled JS offers a much
better experience. When that is not enough a good old server side rendered app
with sprinkled JS is the next step I will consider.

There are some perfectly valid use cases for SPAs but those are rare.

And don't get me started on libraries/frameworks figuring it out as they go
along. jQuery has had a stable API and methodology like forever. React has
made major changes in only 5 years. From createElement, to JSX, to classes, to
stateless components, to hooks, and only god knows what they will come up with
next year.

~~~
noir_lord
Vue gets that part pretty right at least, they work hard not to break things
unnecessarily across versions and never in version (in my experience).

Nothing like jQuery's track record but they don't have the history yet to call
on.

~~~
pier25
Yeah, you can still use the component object notation in Vue 2.

AFAIK they will keep that in Vue 3 too but the team is moving onto a new hook-
like API after cancelling the class based components.

~~~
noir_lord
I was bummed they cancelled the class based approach as it’s one I use and
like but they did it before 3 was released so not the end of the world.

------
beders
I'd like to introduce a new measure: Expected Complexity (EC)

Possible values: \--> Static webpage \--> There's a Form! \--> I can click
things and the URL doesn't change! \--> I spend a few minutes on this site and
click a few things \--> I spent a couple hours on this site and click lots of
things \--> My office hours are spent clicking on things on this site!

How to determine at the start of development what EC value will be reached:
Using a crystal ball (as usual)

Pick your technology according to the value of EC.

There's a good chance that (= :jQuery (choose-tech ["There's a Form!", "I can
click things and the URL doesn't change!", "I spend a few minutes on this site
and click a few things"])

is `true` and that's ok.

------
ehnto
The given example of element.nextSibling is a great example of what jQuery
gets wrong. In jQuery, that's going to be $(el).next();

On first encountering $(el).next(), you need to answer a bunch of questions.
Next what? Why is this a function and not a property of the object? Why not
call it getNextSibling? What the hell is $() doing?

element.nextSibling is very clear. It's the next sibling of the element. It's
idiomatic javascript, and it follows a good naming convention, which is a
skill that is language agnostic.

The author is also conflating their time learning as a pro for jQuery. Had
they learned vanilla javascript first, their point about not knowing which
nextSibling to use would be moot. What they are referring to here is an
idiosyncrasy, and jQuery is jam packed with them. The difference is they have
learned them already.

If you learn jQuery today, you're not learning core JavaScript, and
considering the trajectory of web technologies you'll be doing yourself a
disservice not to use that learning time on actual JavaScript that you could
use in future tools. jQuery isn't a bad choice if you know it already, but if
you are a new developer do yourself a favor and learn the foundation it's
built on first.

~~~
Carpetsmoker
> element.nextSibling is very clear. It's the next sibling of the element.
> It's idiomatic javascript, and it follows a good naming convention, which is
> a skill that is language agnostic.

The only catch here is that it will give you the wrong answer, and that you
should (almost) never use it since it includes whitespace nodes, which you
practically never want. This is why nextElementSibling exists (get the next
sibling that is an element).

As for the naming: this is an old old discussion we will never agree on, but I
think that in the context of a DOM traversal library "next" is pretty clear.

> The author is also conflating their time learning as a pro for jQuery. Had
> they learned vanilla javascript first, their point about not knowing which
> nextSibling to use would be moot.

Your assumptions about my knowledge couldn't be more wrong. I spent years
writing plain JavaScript. I even wrote a jQuery alternative back in the day as
I didn't like various aspects of it (I think I was the only user), before
giving in and "just using jQuery". I _still_ don't like those same aspects,
but it's not bad enough to use something else.

I have also, recently, tried very hard to use plain JS, and this post is the
result.

> if you are a new developer do yourself a favor and learn the foundation it's
> built on first.

This is just a variant of the old "kids these days, they just learn Python
instead of REAL development with C, they don't even know the difference
between the stack and heap!!" Okay, _shrug_. In the meanwhile, those "kids"
are solving real problems, so well... Programming isn't some kind of
intellectual exercise, it's a tool to solve problems.

~~~
ehnto
> The only catch here is that it will give you the wrong answer, and that you
> should (almost) never use it since it includes whitespace nodes

But that's perfect, because it does what it says. If I wanted to get the next
element only I would used the correctly named nextElementSibling. How do you
get the next text node sibling in jQuery?

> Your assumptions about my knowledge couldn't be more wrong.

My apologies. I was reading between the lines and I guess I got it wrong.

> This is just a variant of the old "kids these days...

Not at all, it's advice for the future of the web which will be more plain
javascript based but within frameworks like React and Vue. They're grabbing
more and more of the job market share. I am being pragmatic here, knowing
jQuery won't help you navigate the world the "kids" are busy building right
now with frontend SPA frameworks.

jQuery obviously has it's place, and if you prefer using it then no one can
stop you. I just don't agree that it's better, and I don't believe it's as
useful to know for new developers with the way the industry is changing.

------
zaro
I didn't know about
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/) , but
to me it seems very convincing that I need jQuery :)

~~~
ape4
Small detail, what's with the plus in this code from that site:

    
    
        last = +new Date();

~~~
lewiscollard
It is a trick to coerce it to an integer.

    
    
        >> new Date()
        Date 2019-05-27T12:52:41.932Z
        >> +new Date()
        1558961556913
        >> +"4" // works on anything else :)
        4

~~~
ape4
\+ can concatenate strings. So I guess there is an implied: 0 + in there to
make it in integer mode.

~~~
dentemple
There's no implication involved. It's the unary operator, and it performs the
type conversion exactly as specced.

~~~
ape4
TIL, [https://scotch.io/tutorials/javascript-unary-operators-
simpl...](https://scotch.io/tutorials/javascript-unary-operators-simple-and-
useful#toc-unary-plus-)

------
drikerf
Sure. But as always. It depends. If you're writing a highly interactive app
and your jQuery script starts containing a lot of view state, eventually
you'll go mad and probably duplicate a lot of logic on server and client too.

Seeing your app as a function of a data structure/state is then much simpler.
Although it will require a bit more thought initially. App = f(s).

Again, it depends. If you're writing static sites and sprinkles will stay
sprinkles, jQuery will probably be a solid choice.

~~~
Hendrikto
As always, it comes down to: use an appropriate tool for the job.

Sadly, that‘s not a nice title for your blog post to go viral, so people make
posts like "x is dead, long live y", and "why are you still using x?", or "the
era of x is over", in which they present very narrow viewpoints, and try to
solve every single problem in the world with the hot new fotm framework.

------
JanSt
If JQuery is all you need to get the job done, go for it. It's still fast,
simple and easy to develop.

If you need state management, build a very complex app, etc. ... don't.

~~~
Carpetsmoker
> If you need state management, build a very complex app, etc. ... don't.

I'm not so sure you do for many sites. Take something like Reddit for example;
I don't think the new SPA redesign is any better than the old template-driven
app. In fact, IMHO it's worse in every way. Part of that is just a matter of
design and not technical, but part of it is just "SPA hell": CPU goes to 100%
on load, takes ages to load stuff, etc.

On the other hand, I find something like FastMail's web UI to be quite
pleasant. So it certainly _is_ possible, but I do think it's a lot _harder_ to
get an SPA right than it is to get a classic template-driven app right. It's
also a lot more complex, which results in all sorts of problems.

I don't think jQuery is the "perfect" way to develop stuff; the lack of
structure means things can get messy (we've all seen that), but I'm not
convinced that React is the best answer to that (just because A is imperfect
doesn't mean B is the answer, a common fallacy in these types of discussions).

I'm not quite sure what the best way is, and perhaps it already exists and I'm
unaware of it, but in the meanwhile I prefer to stick with the "KISS"
solution. If I look at the websites I really like using then they're all
classic "progressive enhancement" ones, and not SPAs (in fact, FastMail is the
only exception that I can think of).

Either way, the post was mainly intended as "vanilla JS vs. jQuery", rather
than "classic JS vs. modern SPA" (although they're obviously related
discussions).

~~~
cube00
With the way Reddit tries to shove it's app down your throat while using their
SPA the cynic in me wonders if it's not designed to be as painful as possible
if you persist. The last time I tried, I got THREE separate UI components
prompting me to use the app.

------
geekamongus
As someone who does application security assessments for a living, the biggest
problem with jQuery is the lingering, outdated, vulnerable versions that are
pervasive (1.x and 2.x in particular) in so many applications. I don't care if
you decide to use jQuery or not, just have a plan to maintain it and be able
to update it without breaking everything, should the need arise.

/preaching

~~~
madeofpalk
I'm curious - what are the types of vulnerabilities that lie in the client-
side jQuery?

~~~
provolone
If you allow unchecked data to be stored & retrieved there are some XSS vulns
in older versions. Ideally this would be prevented in a sane environment.

------
edanm
> Pages like You might not need jQuery try to sell the idea that it’s easy to
> ditch jQuery[...]

I wasn't aware of
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/), but
that's an inaccurate summary of what the website tries to do and really does
it a disservice.

It very specifically says, _in the first sentence on the site_ , that you
should use jQuery for regular development - it's specifically talking about
people developing _libraries_ , and encouraging them to not force other people
to load jQuery as an extra dependency, which is a very reasonable position.
And I don't think it's trying to sell how easy plain JS is, as much as just
giving translation code from common jQuery code to plain code, so that if you
want to go that route, it'll be easier to do so!

Here, I'll just quote the first text on the page (emphasis mine):

"jQuery and its cousins are great, _and by all means use them if it makes it
easier to develop your application._

If you're developing a library on the other hand, please take a moment to
consider if you actually need jQuery as a dependency. Maybe you can include a
few lines of utility code, and forgot the requirement. If you're only
targeting more modern browsers, you might not need anything more than what the
browser ships with."

------
Aaron-goshine
Fist let me say this thread has turned out to be possible the most important
thread in regards to modern web development.

Single page Applications (SPA) and frame works that are used to develop such
applications are over used which have led to a whole host of problems in the
software engineering industry, I truly believe that if you are building
software solutions 90% percent of the time you will be building them to solve
business problems, so that should be of paramount importance not necessarily
the latest shines concept and tools, especially unproven tools.

A very high percentage of the developers you will interview will be using
front end frame work such as Reactjs, Anuglar, VueJs ... etc as a substitute
for truly understanding the the native technologies and standards support by
various user agents.

The consequences of this is usually very expensive for business while
resulting in software products that are convoluted, complex and unstable; I
have seen this too many times.

The JavaScript eco system at the moment is littered with these kind problems,
pseudo stars developers who want to re invent the wheel (without first
understanding the existing mechanics), not only is reinventing the wheel
already an idea that has been frowned upon for thousands of years, in the
context of software development most of the times it turns out to be a much
buggier and less efficient solution.

I have encountered SPAs that have been built out to be so complicated and
convoluted to say the least; in order to support server side rendering, hot
module reloading, dynamic DOM refresh, Virtual DOM… etc. speaking as if these
concepts are some holy gifts from the gods, and when you ask the most
fundamental question what are the business values behind all of these
concepts, there are no good answers.

------
sandreas
I'm a bit sceptical about this article... I understand the point... jQuery is
a nice place to get started for beginners and see how things have been done in
the past and I also HATE the boilerplate with most modern JavaScript-
Frameworks, but

> I want to build webpages that are fast

I don't think that jQuery is fast... Especially the fact, that jQuery hooks in
every event handler to control the possibility to remove all Event handlers is
something that is slowing down every app... event if jQuery is hardly used.

> use the simplest feasible code

I don't think that code is simple, when it is ONE single function that takes
nearly every type as argument with different outcome...

And I don't like that developers could use this article as a justification...
especially while modern frameworks like vue.js can also be used without
setting up a webpack project...

But: If you read between the lines, there is something to learn ;)

~~~
LocalPCGuy
> is something that is slowing down every app

If that is slowing down your app, something was done wrong.

This comment reads (and feel free to correct me for a wrong assumption) as
written by someone that really hasn't used jQuery in a serious production
capacity.

------
cdubzzz
The thing that really got me to start thinking twice about jQuery, much more
than the youmightnotneed... website, was this performance test for selectors —

[https://jsperf.com/getelementbyid-vs-
queryselector/25](https://jsperf.com/getelementbyid-vs-queryselector/25)

~~~
Carpetsmoker
You can build jQuery without the SizzleJS engine and then it'll just use
document.querySelectorAll. You can, of course, also still use
document.getElementById('foo'), so if you have a specific performance issue
you can opt-out for that one function.

------
Raphmedia
I've been doing front-end for years and still use jQuery for almost 90% of my
projects. It's not because I'm resistant to change, I've done my share of SPA
style projects.

Simply said, jQuery is still the best plug-n-play solution for most small
projects.

The numbers are not against jQuery. There's no real gains to skipping it. At
27.77 KB (Minified and Zopflinated file size) it's not as if it's weighting
down your pages. On the rare occasions I actually come across something done
faster in raw JavaScript (often because jQuery has some heavier polyfills), I
simply use the raw JavaScript in my jQuery project.

------
thrower123
If it's not broke, don't change it. I could write more, but I'd just be
echoing the post's points.

I think the biggest win would be avoiding all the insane complexity of a
modern npm/webpack JS development experience.

------
Existenceblinks
Javascript libraries ecosystem in post jquery era is also inefficient.

More duplicated efforts on making reusable uis because they
(React/Vue/Svelte/Elm/Ember etc) don't mean to integrate well with each other.
Mostly they live their own world. Nothing integrates well with server
rendering approach because most of them are based on virtual dom or compiler,
vm that takes over the whole ui containers.

When you change a frontend language/lib/framework, your design system also
need to change. All of your branded ui components need to be reinvented
although some people just wrap libs such as Sortablejs, Select2 with their
favorite js thing.

I've experiment Phoenix LiveView with a bunch of mentioned js
lib/framework/language (above), nothing really integrates well for production
uses. Vanilla js is still best bet for working with server-side rendered html
(Unpolyjs or Stimulusjs is nice, but it only serves small purposes)

I hope there would be more js that works with good old html that you are
already rendering.

------
degobah
> Pages like "You might not need jQuery" try to sell the idea that it’s easy
> to ditch jQuery. ... good reasons to not use jQuery: if you’re writing code
> that you want to be re-used by others...

Literally the first thing youmightnotneedjquery.com says is:

> jQuery and its cousins are great, and by all means use them if it makes it
> easier to develop your application.

> If you're developing a library on the other hand, please take a moment to
> consider if you actually need jQuery as a dependency.

------
Asmod4n
When you are done designing your Webpage, disable JavaScript, disable CSS (if
your browser supports that) and check that you are still able to grasp what
you want to present your visitors.

If you then don't find the relevant information in the first second,
congratulations, you just made a page which is useless to people with old
Screen-readers.

I may be old fashioned in this regard, but i only see JS as a Add-on to the
text you want to get out and only use it to add functionality which would be
impossible with html and css alone. e.G. to give a hint when there are new
articles to read, or when a article has changed.

Comment sections for example don't require JS at all, but you can use JS to
make it needless to reload the page after you send that HTML Form.

~~~
macspoofing
>When you are done designing your Webpage

What do you mean by 'webpage'? Because SPAs are really applications that are
served over http(s) and executed by the browser.

>I may be old fashioned in this regard, but i only see JS as a Add-on

You are. People want to build applications served over the web instead of
installed locally. In those cases JS is not an add-on. In fact, the DOM is an
add-on as it is nothing more than a layout manager and UI component set.

Sounds like you just want webpages to be nothing more than a medium for
publishing text content in which case CSS and HTML is all you need ... but
that ship has sailed in early 2000s.

------
settsu
I’d be curious to see how many people have a cached copy of jQuery from one of
the popular CDNs and what the overall real world effects are of that.

(That got me thinking of another potentially interesting analysis/discussion
about the distribution of jQuery versions being used…)

------
zackbloom
I'm one of the original creators of You Might Not Need jQuery. Most of the
examples still date back to 2014, with modern JS they get much simpler and
shorter (the fetch API and async/await help tremendously in the first example
cited).

~~~
degobah
Thanks for your work. OP maybe didn't read the first two paragraphs of YMNNJ,
which clearly states:

> jQuery and its cousins are great, and by all means use them if it makes it
> easier to develop your application.

> If you're developing a library on the other hand, please take a moment to
> consider if you actually need jQuery as a dependency.

------
Chazprime
I’m pretty much in agreement with this, to a point. jQuery is a reliable and
fast way to make a age do just about anything, except maintaining state.

The __KISS __principle is practically unheard of in web development lately - I
see teams using more “hip” technologies like React or Angular for simple
sites, but then the complexity of the app increases considerably for not that
much in the way of gains. Sometimes simpler really is better

------
cptrp2101
I think, as with anything else, it's important we understand the tools we are
using. I started with jQuery and the problem was (like many others) I learned
it before I actually learned javascript. I've since backtracked and dug into
vanilla JS so I can have a better understanding of what my code does.

Since then, I haven't found a situation where I miss jQuery. However, I don't
damn anyone who uses it (beyond jokey arguments with the wordpress dev on my
team).

It seems like this opinion won't fit in well here, but at this point I find
vanilla more than enough for anything where Vue or React will be overkill.
However, I'm obviously biased as a front-end app dev and am open to seeing
what other people have to say.

I'm not sure what to think about the server side vs. client side comments in
the article since that fall outside my area of knowledge.

~~~
h1d
You will soon come back to using jQuery again thinking what the point of just
saving 30KB by letting your code become longer.

~~~
Bahamut
Doubtful - 30 kB minified & gzipped is a lot of code, and the fact that jQuery
doesn't help with your code organization/keeping code DRY much is a huge
negative.

------
fareesh
Is there a plan (or is it possible) for jQuery to look at going with some kind
of modular approach where you can just import the stuff that you / your
plugins want?

I know there are libraries that claim to have 100% parity with jQuery's
selector library. Are there any ones that are making this claim reliably?

~~~
lioeters
Zepto comes to mind:
[https://zeptojs.com/#modules](https://zeptojs.com/#modules)

------
nickjj
I still use jquery too and it doesn't have to be a tangled mess of insanity
nowadays.

Webpack + ES6 modules + jquery is a reasonable option IMO if you like the idea
of server rendered templates with sprinkles of Javascript.

Plus, with the way things are heading with certain web frameworks (like
Phoenix), you can do really interesting things like push the diffs of your
server rendered templates over a websocket channel without having to write any
user land Javascript yourself, and on the initial page load it just gets
served without Javascript using the same templates. It's like the best of both
worlds (super fast feeling apps, SEO just works and you don't have to
duplicate templates and logic on both the client and server).

------
dsenkus
convenience is the primary reason I still sometimes use jQuery. Sure dropping
one more dependency always seems rewarding, but jQuery is just a tool which
when used properly saves a lot of time.

------
masswerk
Something seldom considered while discussing the use of libraries and
frameworks: green computing.

Mind that you're multiplying any overhead thousandfold or even millionfold
when transferring the overhead to each client connecting to the service
(including several instances of network infrastructure). So,"how much effort
it can be to use vanilla JS", – it may be well worth the extra effort, once,
on a single side of the communication chain.

~~~
h1d
Your assumption that everyone can write more efficient code than jQuery isn't
making sense.

~~~
masswerk
It's certainly a matter of balance: if you need just a simple functionality or
a single effect, loading (and compiling) the entirety of jQuery may not be the
wisest. Similarly, I've seen d3.js loaded just to get a canvas element by 4
lines of code, where a single vanilla line would have done.

(Edit: Notably, my argument was about the effort involved.)

------
DoctorPenguin
I would argue that the comfort of using jQuery comes at the cost of speed and
obfuscation. I stopped using jQuery about 2 years ago and for the most part
had no problems whatsoever even when I was forced to support IE9. Also I found
that searching
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/) helps a
lot when deciding how to implement certain features.

------
drinchev
Hardest part to get rid of jQuery was the $.ajax function. Happily now, we can
all use the fetch API with some extra polyfills, but pretty much that's it.

`el.insertAdjacentElement`, really? Yeah if you carry jQuery thinking with
you, you will probably want to translate the code literally and find
substitute for everything. No... You can just use to recreate the part of the
DOM that needs to be updated and replace it. It's faster to write and easier
to read.

Anyway most of the arguments are not considering, vanilla JS + webpack / babel
es6 + npm packages. In a world where side-effects are not well accepted
anymore using jQuery is nightmare to maintain.

What's this fuzz about btw, I thought this argument was over?

------
losvedir
I've seen a few apps that began as vanilla JS or jQuery updated to use react
as the requirements grew and the "simple" JS started crumbling under its own
weight. So I'm sympathetic to the idea of just starting with a framework from
the get-go.

That's why I'm excited to see how Phoenix's LiveView turns out. It gives the
"server side rendered, sprinkling of JS" approach more room to go in. It won't
replace something like Google Maps, but there's a whole class of applications
that would previously be on the border of the decision between react and
server side that can be pushed into server side.

------
jesusthatsgreat
If it works for you and is easily maintained by whoever is looking after it,
great.

In my experience, sooner or later you're gonna want modern functionality /
user experience and you're in for a world of pain trying to hack it together
with jQuery.

These days I'd only use jQuery for sites where I'm the sole developer and the
project won't change much over time. Or for legacy projects where the cost of
moving everything to an SPA wouldn't be worth it.

If you're not the only developer on a project and the project is liable to
morph over time, jQuery will be a costly mistake.

------
viach
Idk in regards of how better the code can be structured with React or Vue, but
opening apps based in these frameworks makes similar effect to starting Monero
miner locally.

------
thrownaway954
It's a mature library that takes the pain out of cross browser compatibility
(yes... you read that right, cross browser compatibility is still a thing in
2019) and the verboseness of using native JS (yes... you read THAT right,
using native JS is verbose), so why wouldn't you want to use it?

Oh and on more thing... If you're not using jQuery but instead using native JS
with polyfills... YOU ARE A MORON AND DOING IT WRONG and should just you
jQuery.

~~~
macspoofing
>yes... you read that right, cross browser compatibility is still a thing in
2019

When it comes to manipulating the DOM, I'm not sure it actually is anymore -
especially if you can cut out IE11 (and IE11 isn't too bad).

What would be an example of cross-browser compatibility that JQuery takes care
of that would be a pain to do with DOM apis.

------
gchamonlive
I have had my share of grief with jquery, but I'm not quite sure it was
jquerys fault or the tools built around it. Many a time I had to reimplement
stuff like radio button exclusion when a pop-up would render an HTML string as
is.

Did anyone have problems like that? What are the jquery limitations I should
be aware of?

I am asking because I am mainly backend and infrastructure developer and feel
like I have little experience with frontend tools

------
pizza_r0b
_one line of trivial jQuery code gets replaced with 10 lines of vanilla JS
code!_

Actually those 10 lines are replaced by the entire JQuery library.

------
droptablemain
This is all fine and dandy; use what works for you. However, as many of us
have learned when trying to aggressively optimize performance, execution time
is generally much longer for jQuery than with vanilla JS. So if you're after
high PageSpeed scores, for example, jQuery is the damn devil (or at least one
of them).

------
jb3689
I like the progressive enhancement approach using a small amount of JS, and
I'm fine with jQuery. The thing is that I don't _use_ very much of jQuery.
Rather than pull in all of jQuery you could just define your own `get` and
`post` to abstract the XHR verbosity. No need to pull in a giant library to do
that

------
RyanShook
Great reminder that old does not equal bad!

------
javinpaul
You are not alone mate, I am also using jQuery in 2019 :-) It's one of my
favorite JavaScript libraries.

------
sedatk
jQuery is an idiomatic DSL but far from intuitive (does “after” imply a DOM
modifying action or just a selector?). So I find it okay that browsers have a
verbose API as it makes it clearer. Bare DOM API is nowhere close to jQuery in
terms of practicality though.

------
umanage
This is pretty much the reason I still use jQuery too. Although JavaScript now
offers much of the jQuery functionality as built-ins, the very concise syntax
that jQuery offers is more convenient to use.

------
nkozyra
I think the most compelling reason to keep JavaScript is "it's already there."

I see no reason to yank it out unless you're already doing some front end
refactoring

~~~
sureaboutthis
If you yanked JavaScript out, you wouldn't have jQuery either.

~~~
nkozyra
Slip of the fingers, obviously

------
forgot-my-pw
When you don't have to support Internet Explorer, using ES6 (fetch) is nice
enough. When you need to support IE, it's best to use jQuery.

~~~
hatch_q
It's not. It's better to use fetch polyfill.

------
robm99x
I’m still using jquery and bootstrap for mvp web app using, of all things, PHP
and Slim Framework which surprisingly is not horrible.

------
qwerty456127
el.insertAdjacentElement('afterend', other) seems a way more intuitive than
$(el).after(other). I don't code JavaScript yet the meaning of the first is
intuitively obvious to me while I can only know what the second form does
because you've told me.

------
tempodox
So, what is a good jQuery replacement nowadays, for just XHR and a bit of CSS
manipulation?

------
unfunco
> Pages like You might not need jQuery try to sell the idea that it’s easy to
> ditch jQuery, but the very first example is a good reason to use jQuery: one
> line of trivial jQuery code gets replaced with 10 lines of vanilla JS code!

There's no such thing as one line of jQuery, it's 10K lines before you add
your one line to do that one thing that 10 lines of vanilla JS code can do.

~~~
rlv-dan
True. But it's 9 more lines that _you_ have to write yourself. And some people
prefer being productive rather than figuring out how to do it in plain JS for
the sake of it.

