
You Don't Need JQuery - rnicholus
http://blog.garstasio.com/you-dont-need-jquery/
======
bshimmin
You can basically sum up this entire rather ridiculous site with "Yes, you
don't _need_ jQuery, you can just use the built-in methods, but using jQuery
is generally more pleasant, more consistent, and involves less typing". One
particularly egregious example from the site:

    
    
      $('#foo').removeClass('bold');
    

vs.

    
    
      document.getElementById('foo').className = 
          document.getElementById('foo').className.replace(/^bold$/, '');
    

The author summarises this, helpfully: "As usual, more characters, but still
easy without jQuery."

Of course, if you were doing that remove class operation quite often, rather
than writing all that code out each time, you might wrap it up in a helper
method, and maybe you'd call it, I don't know, "removeClass" or something;
perhaps if you were doing a whole bunch of DOM operations you might create
little helper methods for each one, again to save you some typing. Pretty
quickly you might end up with a little library of helper methods... and, of
course, being a wonderful programmer who never makes mistakes, I'm sure that
little library would be every bit as optimised, reliable, and correct as a
battle-tested library used on hundreds of thousands of web sites.

~~~
oneeyedpigeon
.classlist() [1] is coming [2]. It'll allow you to do:

    
    
        document.getElementById('foo').classList.remove("bold");
    

Sure, it's still more verbose. But a lot of what jQuery does is slowly being
obsoleted by better native javascript apis.

[1] [https://developer.mozilla.org/en-
US/docs/Web/API/Element.cla...](https://developer.mozilla.org/en-
US/docs/Web/API/Element.classList) [2]
[http://caniuse.com/#feat=classlist](http://caniuse.com/#feat=classlist)

~~~
Khao
So when those new native api functions arrive, jQuery will start using them
and gain some performance boost (using native vs. custom js code) while at the
same time remaining backwards compatible (by doing feature detection). No one
wants to write their own feature detection code so this whole page about using
native apis is instead of jQuery is ridiculous.

If the point of that website was to educate people on the apis that jQuery
calls under the hood, it chose a really poor name.

~~~
malandrew
Or you could use the class list polyfill.

~~~
organsnyder
If that's all you need, then that would be fine. However, for most projects
you end up needing many other such polyfills, to the point that you might as
well use one library—jQuery—to provide them all (plus a lot of other
functionality).

------
random28345
Every time I try to build something without jQuery, I regret it.

Not because of selectors, that's (sometimes) easy to do for lots of (basic)
selectors. Not because of DOM manipulation, as long as you're willing to
sacrifice simplicity and readability, you can build iterative loops to modify
a collection of HTML elements.

No, it's the unexpected things that cause me pain. Want to use event handlers
on dynamically generated DOM objects? Write your own event bubbling library.
Want to create custom events/handlers? Ditto. Promises, .serialize(),
.extend(), etc. might all be simple to write your own version, but when you
realize you've reimplemented 50% of jQuery to avoid using jQuery, you feel
like an idiot. [Source: I do this every 3 years]

Life is too short to not use jQuery.

~~~
Pxtl
Yeah, the problem with jQuery is all that _other_ stuff that nobody uses and
backwards compatibility with browsers nobody supports. A "lite" jQuery with
the same familiar API but a stripped-down featureset for higher performance
and smaller size would be nice.

~~~
abritishguy
Just use the CDN copy of jquery and it will be cached in the users browser
already since so many websites already use it.

~~~
LocalPCGuy
Not really, the cache-hit benefit is a myth. Too many CDNs, too many versions
of jQuery in use, cache's too small...

So ..using jQuery via a CDN, depending on which you use you have a 1 in 119,
or 1 in 833 chance of the user having a cached copy.
[http://www.i-technology.net/2013/11/the-myth-of-
cdn.html](http://www.i-technology.net/2013/11/the-myth-of-cdn.html)

more data: [http://www.stevesouders.com/blog/2013/03/18/http-archive-
jqu...](http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/)

There are valid reasons to use a CDN (get the scripts closer to the end user,
offload the data transfer costs to the CDN provider, etc) but it isn't due to
the potential for a cache hit.

~~~
chdir
> you have a 1 in 119, or 1 in 833 chance of the user having a cached copy

That statistics has assumptions on what's the most popular jQuery versions
being used. It would make sense if there was real data to support that.

------
potch
Here's a list of DOM bugs in browsers that jQuery works around:

[https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0Rlh...](https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0RlhdnPx_ePXm7oW02iiT6o/preview?sle=true)

Pretty sure they're not all fixed, and this is just the ignorance du jour.

~~~
psychometry
So many of the author's examples required different bits of code for different
browsers. It's almost like they don't understand why people use jQuery and
just chalk it up to ignorance when using a framework it's almost a necessity
these days.

It's this stupid "you're not a real developer unless you're twiddling bits on
your hard drive with a magnet" mentality that I absolutely despise.

~~~
icantthinkofone
It's a page and a half of mostly IE bugs. You should know your bugs and not
try to cover them up but, more troubling that you don't want to know these
things. Programmers I know want to write code, especially things as
insignificant as these.

------
hcarvalhoalves
Right off the bat, on the first 3 examples, he shows how you need to use
different APIs depending on the IE version.

That alone is enough reason to use jQuery and not having to bother.

~~~
icantthinkofone
You're pointing out an IE problem, not a javascript problem that isn't present
in other browsers.

~~~
squeaky-clean
And your point is? Pointing the blame at a different source doesn't mean the
problem isn't present. If a client needs IE support, what do you do? Write the
code three times? Detect IE and redirect the user to chrome-frame, then cry
when you don't get paid?

I don't care who caused the problem. Just that it wasn't me, I can't fix it,
and I have a deadline to meet and constraints to follow. jQuery is a
lifesaver.

~~~
Zarel
Chrome Frame is no longer supported. :(

------
nathan_f77
I disagree, jQuery is awesome, even for seasoned web developers. Of course you
don't need it, but it makes life a lot easier when working with XHR, events,
selectors, etc.

If you're worried about dependencies, you could just compile your released
library with the Google Closure compile, and strip out everything you don't
use. You could even set up a pipeline to produce two releases: one that has
bits of jQuery embedded, and a smaller one that requires jQuery.

EDIT: Thanks to dmethvin [1], I just learned that you can also build your own
jQuery [2] that only includes the modules you need.

[1]
[https://news.ycombinator.com/item?id=8760352](https://news.ycombinator.com/item?id=8760352)
[2]
[https://github.com/jquery/jquery#modules](https://github.com/jquery/jquery#modules)

~~~
bjourne
It's better to just use one of the jquery versions hosted on the google
developer cdn:
[https://developers.google.com/speed/libraries/devguide](https://developers.google.com/speed/libraries/devguide)
If you link to a popular jquery version, I bet the odds of the user already
having the library cached is approaching 95%+ so your dependency is
essentially free as no requests will be made in that case.

~~~
LocalPCGuy
The odds approach 1.7%.

[http://www.i-technology.net/2013/11/the-myth-of-
cdn.html](http://www.i-technology.net/2013/11/the-myth-of-cdn.html)

more data: [http://www.stevesouders.com/blog/2013/03/18/http-archive-
jqu...](http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/)

------
teknologist
Doing ajax without jQuery is also good fun

    
    
        var xhr = new XMLHttpRequest();
        xhr.onreadystatechange = function() {
            if (xhr.readyState === 4) {
                callback(JSON.parse(xhr.responseText));
            }
        };
        xhr.open('POST', url, true);
        xhr.setRequestHeader('Content-Type', 'application/json');
        xhr.send(JSON.stringify(data));
    

And that's not taking care of errors, edge cases or Internet Explorer _at
all_.

In jQuery:

    
    
        $.post(url, data)

------
dangerlibrary
The AJAX examples fall a little flat. Yes, .ajax is a wrapper, and it was
written because the API for XMLHTTPRequest is needlessly complicated and
verbose.

If you're developing a single page application, you only load jquery once,
then do the rest with AJAX calls for JSON and assets. It's worth the <100 KB
on initial page load, at least for the projects I've worked on.

~~~
jackmaney
Not to mention that if you're loading jQuery via a CDN, there's a good chance
that your end user has it in their cache already.

------
cwbrandsma
Next up: you don't need Underscore/Lodash!

Forget this "you don't need JQuery"...JQuery, the entire library, is basically
an API bug report against the DOM! What browsers need to start doing is get
off their butts and start implementing a real selector implementation like
Sizzle. Reduce JQuery to set of polyfils after that.

As for IE7 support. Sorry that still accounts for too much of my traffic to
ignore.

~~~
mcintyre1994
Are you aware of QuerySelectorAll? I think Sizzle does more but I expect
internally most of it delegates to that when available by now - it should
support all CSS selectors.
[https://developer.mozilla.org/en/docs/Web/API/Document.query...](https://developer.mozilla.org/en/docs/Web/API/Document.querySelectorAll)

------
IkmoIkmo
Who needs an operating system if you can write your own? Then you might as
well write a browser, and develop a web language for it, and then you can
write your own jQuery type library in that language. Because, why not, you
don't NEED to use all these excellent tools already available for which I
provide no reason not to actually use them.

I'm _just_ saying, you don't _need_ them.

------
codingdave
I don't need power steering or an automatic transmission in my car either. And
I don't need a garage door opener or a microwave. I don't need a wifi
router... I can hard-wire my whole home. There are many things in this life
that I do not NEED, but that make life easy. jQuery fits into this same
category.

------
caoglish
You don't need jQuery if you have written better wrapped API library and have
already attracted millions of developer to test your library.

For the eco-system point of view, jQuery have been tested in the widest
markets for many many years. well written document, many online cases, many
supporters, many bug reporters, high cover unit tests,good code quality and so
on.

Using jQuery for project is smart move unless high performance requirement.

------
sebnukem2
You Don't Need JQuery if your time is worthless, and don't mind spending 20x
the amount of time to make your stuff almost work on IE.

------
martin-adams
Articles like this make me thankful that I've done my 10,000 hours of web
development learning the ins and outs of the DOM and it's interactions with
JavaScript (mostly topics covered in Crockford's book). Admittedly, about
9,950 of those hours were making it work in IE6.

jQuery is a framework, like many others. Programming is not about learning
frameworks, it's about learning the language, it's runtime behaviours and of
course software development in general. Frameworks are there to speed up
development time.

~~~
teknologist
after 10,000 hours you're still calling jQuery a framework?

~~~
martin-adams
replace(/framework/ig, 'library')

better?

~~~
teknologist
☺

------
contactmatts
When I first read this post, I thought the link may be to this website:
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/) .

I developed a Cordova application recently, and I only needed jQuery for
Bootstrap. All custom JS was able to be done using the DOM API. However, I was
spoiled since I only had to develop against a recent webkit version (my target
was iOS 7)

~~~
felipesabino
I had the same feeling when started working with angular, were you don't need
jQuery or anything else to manipulate the DOM. It is spoiled, I agree, but it
feels good to be "free" :p

------
corwinstephen
This guy's argument is strikingly similar to that of the one made by those
people who are anti-Apple, despite the fact that working with Apple products
is a commonly pleasant experience, simply for the fact that they're Apple.

Just because a lot of people use something that they're not being forced to
use doesn't necessarily mean that they've been "tricked" into doing so.

~~~
icantthinkofone
Using Apple products is a pleasant experience. Using jQuery is to avoid
learning how to code while purporting that it makes things easier cross
browser. Of course, if that were the real reason, we would also have cQuery
and c++Query and so on but, instead, we just learn how to code.

~~~
recursive
In your c and c++ analogies, what are the inconsistent DOM API
implementations?

~~~
Nullabillity
Well, to be fair, the APIs aren't very consistent between OSes. But then
again, I guess Java is the jQuery of C++. :P

------
johnwards
Tickets to jQuery UK 2015 are on sale now!
[http://jqueryuk.com/2015/](http://jqueryuk.com/2015/)

(Sorry ;))

In all seriousness I'd recommend watching Adam Sontag's keynote from jQuery UK
2014 which covers the "not needing" jQuery stuff
[http://vimeo.com/97723665](http://vimeo.com/97723665)

------
cezary
Another great resource when trimming down jquery use is
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/)

~~~
terminado
...and then, of course, there's:

[http://youmightnotnotneedjquery.com/](http://youmightnotnotneedjquery.com/)

or

[https://gist.github.com/rwaldron/8720084#file-reasons-
md](https://gist.github.com/rwaldron/8720084#file-reasons-md) (discussion:
[https://news.ycombinator.com/item?id=7153630](https://news.ycombinator.com/item?id=7153630))

------
pawelk
Similar resource with many code snippets:
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/) and
related HN thread:
[https://news.ycombinator.com/item?id=7152068](https://news.ycombinator.com/item?id=7152068)

------
bstrom
Lots of blanket statements in this article. He asserts there is a 'proper'
order to learning JavaScript but makes no demonstration of that assertion. For
me, jQuery was a gateway that hid much of the incidental complexity of working
with a byzantine API (the dom). That was incredibly useful. If every beginner
started with trying to understand the DOM, they'd probably be scared off (and
rightly so).

~~~
icantthinkofone
What you call Byzantine, I call normal. Some things are harder to learn than
others but you can't throw your hands up in the air and let someone else
(jQuery) do the simple things for you.

Working with the DOM is what we programmers do. I've never seen so many people
complain so much about programming than those who use jQuery.

~~~
bstrom
The DOM strikes as being composed of layers of incidental complexity that get
in the way of the actual problem you're trying to solve. jQuery, or
abstractions like it, allow us to compose more elegant and semantically
meaningful solutions to problems. If writing boilerplate is interesting for
some reason, be it for performance reasons perhaps, then by all means. I find
it a bit tedious and appreciate tools that allow me to focus on the problems
at hand, rather than obscure browser differences and internal API
implementation inconsistencies.

------
joshstrange
If we've heard this argument once we've heard it a million times. Of course
you don't need jQuery but unless you are writing an internal-only app and plan
on writing everything from the ground up (all your auto-completes, multi-
selects, etc) then you do need jQuery.

I am not a fan of a lot of the code that I've seen written with jQuery but
jQuery itself is not evil anymore than PHP is evil because people do stupid
stuff with it. If you use jQuery correctly it is an invaluable tool that makes
your like 100x easier.

Event handling alone, I want to puke when I see the default way to do this,
way too much typing, way too verbose. If I had to write that multiple times a
day then I would probably create a helper function to abstract it away and I'd
be on my way to building my own jQuery. No thank you, I'll take the one that's
battle-tested and maintained.

I'm getting sick of seeing this argument, if you work in a bubble then sure,
be my guest (I'll be laughing at all the extra typing you will be doing) but
if you plan on deploying your code to the real world? Just use jQuery and save
yourself a headache.

------
whoisthemachine
I also don't need a calculator but I regularly use one to do even simple
arithmetic operations, because it speeds up the operation and guarantees a
certain result with given inputs.

The purpose of an SDK such as jQuery is to help a developer do common tasks
without needing to write his own library. If it's used widely in the industry
then even better. If it's open source, even more betterer.

------
praetorian84
It's something you see a lot of, especially from non-frontend developers that
don't really think twice about downloading an extra 80-90kb of JavaScript. I
do find the support for events in JQuery quite convenient, especially for
projects that still require IE8 support. Although if that's all you're using
it for, there are probably better ways.

------
jrochkind1
The tutorial in how to do things without JQuery is actually hugely useful to
me.

I have been considering a project where for various reasons it would be much
better to avoid JQuery, and I realized that I had no idea how to do some
common things without JQuery. This is a well-organized guide.

It would be even better if he took out the three sentences after every section
that just say, over and over again, "So why would you use JQuery, isn't this
just as good?"

Who cares, sometimes I agree sometimes I don't, and the boilerplate argument
repeated over and over sounds whiny and gets in the way of the actual useful
information OP has to impart.

If you have your own external reasons to consider doing without JQuery (as I
do), then an _honest_ assessment of where you are likely to have the most
trouble would be more useful, than just repeating "Really, you're an idiot if
you think you need JQuery" over and over again.

Still, useful documentation, thanks.

------
serve_yay
I'm getting very tired of people realizing that browsers now ship with
`document.querySelectorAll` and saying that means you don't need jQuery
anymore.

------
bb0wn
The best thing about jQuery is that it abstracts away most of the browser-
specific quirkiness for you. Using jQuery for that feature alone makes it
worth using.

------
andrezsanchez
Imperative DOM manipulation is a pain one way or another. React does a great
job of alleviating this pain by allowing for declarative DOM manipulation, but
it would be great to be able to do this without needing the rest of React.

~~~
grosskur
You might be interested in the virtual-dom and vdom-thunk NPM packages, which
are used in mercury:

[https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)

See also Raynos's "NPM-style Frontend" presentation:

[https://www.youtube.com/watch?v=8w0_Xw7PPFQ](https://www.youtube.com/watch?v=8w0_Xw7PPFQ)

------
keeran
I thought it was a joke site, I scanned the first example and saw the single
jQuery way of doing something followed by n other ways depending on the
browser / IE level.

------
todd3834
You might not need jQuery but I much prefer jQuery's ajax API to using the
XMLHttpRequest

------
olla
Lately everything I build with jQuery I will eventually regret it. The first
most annoying problem is that events triggered in jQuery cannot be seen by
other modules correctly. Even not by another jQuery instance. There is also
the usual size problem, when writing reusable code. For example whenever I
want to reuse some 100 lines of code on another project I will have to add
almost 100kb of jQuery to make it work. Working also on some bigger
everlasting projects, like the wysihtml.com editor, has shown that when you
need to patch some browser misbehaviours, native javascript is the only way to
go. Such patches need to be as close to their error source as possible.

------
atwebb
Still reading through but it mentions, IE7 when, as I've found out recently,
going to a 2.x jQuery release will break IE8 functionality which is still used
within organizations either as the actual browser or through compatibility
mode. I didn't care for the format of the page but do like the author's tone
and points so far.

I think a lot of the issues people have with jQuery is that (as the article
mentions) it's become synonymous with Javascript and abstracts so many things
that many people using it don't understand the underlying framework and
functions. That and why include more resources if you don't really need to.

~~~
jrochkind1
There is a lot of misconceptions here.

There are two parallel tracks of JQuery maintained, with _identical
functionality_, one which supports IE8 and less, one which doesn't.

JQuery team is supporting both. If they don't behave identically, that's a
bug. If you don't need IE8 or less support, you can use the smaller higher-
performance JQuery that doesn't support IE8. If you do need IE8 or before you
use the other variant.

Your code remains identical either way.

JQuery still supports IE8 and less, and has announced no plans to stop.

A lot of people are confused about this, and it's made more confusing by their
mistakes about version labelling.

At present, these two variants are JQuery 1.x (IE8 no problem), and JQuery 2.x
(IE9 and above). There are identical parallel versions of each. 1.11.0 and
2.1.1 have identical functionality. Yes, this is super confusing, so going
forward in the future, they will call the old-browser-compat variant "JQuery
compat", and the no-old-browsers variant "JQuery", and version numbers will be
sync'd.

[http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-
genera...](http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-generations/)

At present, the JQuery team is still committed to maintaining identical
functionality in an old-browser-compat variant, and a newer no-old-browser
variant, sync'd, for the indefinite future. And in fact they recommend the
Compat version "for most web sites, since it provides the best compatibility
for all website visitors."

They could at some point in the future decide to stop doing so -- they have
said they won't do so until usage of older browsers has dropped significantly.

~~~
atwebb
Thanks for the detailed response, that is clearly my mistake. I did an install
from NuGet and went with 2.1.1 making an assumption that the latest build was
the greatest build and not really doing a lot of research. On my end, it was a
browser compatibility mode setting and a meta tag resolved the issue for just
my site and is fine for the usecase.

~~~
jrochkind1
Yep, they've failed at making it clear.

Hopefully the change to calling the variants "JQuery Compatibility" and
"JQuery" will help -- although since they are still saying they recommend
"JQuery Compatibility" for most sites, I think they should have called it
"JQuery" (the compatible one) and "JQuery Future" or "Jquery Non-Compatible"
or whatever.

Anyway, you also could have simply dropped in the equivalent JQuery 1.x
version for old-browser-compat with no changes to your code.

------
bwindels
I don't mind using a library for dom manipulation, or for xhr, or for missing
ES5 function ... My problem with jquery is that it does all of it, in a very
entangled way. This makes it very tempting to mix parts of your application
that really shouldn't know about each other (like dom manipulation (UI) and
XHR (IO)). I prefer to use a dedicated library for all of those things and to
hide the fact that I am using a particular library to the rest of the
application. I've seen standardising on one true huge library throughout an
application gone wrong several times and it's very hard to refactor your way
out of it.

------
grahamel
Everytime I see one of these I think I should do more with
[https://news.ycombinator.com/item?id=7863271](https://news.ycombinator.com/item?id=7863271)

Yes it's useful to know what jQuery is doing underneath but the whole point of
it is that you don't have to worry about that and can concentrate on on the
rest of your build.

Sure, you might not need it and there are other alternatives, both as plain JS
and with other libraries, but it does it's job well and will always be easier
for others to pick up when coming onto a project.

------
alxndr
A couple days after this was posted to HN, the release of jQuery 1.11.2 and
2.1.3 offers an example of why you might want jQuery even if you might not
need it.

[http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-re...](http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-released-
safari-fail-safe-edition/)

> "A bug like this one emphasizes the benefit of using a library like jQuery
> rather than going directly to the DOM APIs."

------
diltonm
>> In fact, this is completely unneccsary with the existence of forEach and
Object.keys() (both available in IE9+).

Oh the eyes of Microsoft shine gracefully upon us, we are so blessed. First,
get a spell checker. Second, abandon jQuery at you peril. Browser makers
should be required to embed jQuery. jQuery makes JavaScript almost bearable to
deal with. That says a lot.

------
lolwhat
Yeah, you don't _need_ anything. You can write all your apps in vanilla JS,
but if you feel like speeding up development...

~~~
walshemj
and slowing down your website

~~~
lolwhat
well that's the trade-off, isn't it? unless my app is speed-heavy, i'm not
gonna spend the extra man-hours needed (that jquery saves me) so that website
runs negligibly faster.

~~~
walshemj
good luck ranking in google and explaining your self to your md when your
major publishing site takes 20 seconds to load I wont mention any names but I
know of two cases of this.

~~~
lolwhat
if it takes 20 seconds to load, you have bigger problems than jquery.

~~~
walshemj
From experience where there is jquery there is normally at least a dozen other
js files cut n pasted at random along with a similar number of css files with
no thought to efficiency - hell most sites I se they can't even optimised the
godamm images using Photoshop properly.

~~~
thedufer
"JQuery is bad because some people who use it do unrelated things wrong"?
Should I stop driving because some other people who use cars happen to cheat
on their taxes?

------
malandrew

        "This is your reminder that the DOM is actually a giant, 
        mutable, global variable in the middle of your program. 
        Act accordingly." –Marco Rogers (@polotek)
    
    

[https://twitter.com/polotek/status/543590973846999040](https://twitter.com/polotek/status/543590973846999040)

------
bbcbasic
There is a case to not use JQuery: When you really don't need it. I.e. you
have one call to JQuery and it can easily be done natively. Then by removing
JQuery you make the page download and load faster.

If you are using just the basic JQuery features you could consider Zepto
instead, so a smaller download but still giving you the abstraction you
desire.

------
elchief
Oh noes! An 83KB download, which is probably already in the browser's cache,
on your site that is 1MB per request.

------
leeoniya
for those interested in a lighter jquery, most features and same api there are
these alternatives:

[https://github.com/kenwheeler/cash](https://github.com/kenwheeler/cash)

[https://github.com/finom/balalaika](https://github.com/finom/balalaika)

~~~
nightwolf
Also Zepto:

[http://zeptojs.com/](http://zeptojs.com/)

------
PSeitz
An if you care for performance, you shouldn't use jquery. It is very slow:

[http://stackoverflow.com/questions/11503534/jquery-vs-
docume...](http://stackoverflow.com/questions/11503534/jquery-vs-document-
queryselectorall/21539115#21539115)

~~~
radio4fan
But if you care about programmer productivity, you use jQuery, then you
profile, then you optimise where required.

The last step isn't usually necessary.

~~~
PSeitz
I would rather choose something else for productivity.

------
ggonweb
Higher level abstractions, are not required if you plan to write your code in
assembly. Lets go for it.

------
mariusmg
You sooooo do need jQuery if your web apps needs to run on as many
browser/versions as possible.

~~~
teknologist
I'd like to see the IE 7/8 versions of these snippets on the site in the OP.
Wouldn't be so concise then, eh?

------
hnriot
I do need JQuery because I want to focus on the application and not nuances of
different js implementations. And I want to use the simple selector
mechanisms. Then there's plugins, I use those too and many assume/require
JQuery.

So no, I disagree. Stupid article.

~~~
iopq
If you spent any time trying to get your website to load in under 1 second,
removing jquery plugins is the first thing you do. Not only do you have to
load the jquery, you need to load the plugins after you already have jquery
which makes it even slower.

------
Morphling
I guess if you are super optimizing your website then getting rid of all the
useless stuff is fine, but at least I don't notice big enough performance
increase to get rid of jQuery even if it's just for the $('selector').

------
collyw
Except, being old school, I remember 7 or 8 years ago, when everyone would
complain about IE compatibility and various quirks between browsers. JQuery
apparently sorted all of that out. And now we should go back to the bad old
ways?

------
dpweb
This and you're good for selectors, but there's no right or wrong answer - use
what works for you and the project.

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

------
pjmlp
Of course you don't need jQuery, if your customers are happy that you target
only _one browser specific version_.

I think the rest of us will rather keep on using it, or similar library.

------
vijayboyapati
[https://plus.google.com/110888393967521869195/posts/4REjUe5a...](https://plus.google.com/110888393967521869195/posts/4REjUe5aXGr)

#humor

------
andy_ppp
Guaranteed stable, well known, monolithic blob or write something yourself
that fits your needs perfectly.

Fear or Love on the web developer scale of needs.

------
ponyous
My Argument is that you don't need jQuery but you definitely need some kind of
library to avoid most common time-consuming tasks.

------
drivingmenuts
No, I don't _need_ jQuery, but memory really isn't that much of an issue
anymore and convenience wins over bandwidth.

------
steve0341
So why reinvent the wheel? Rename title to "Dom manipulation can be done
without Jquery, but use what works for you!"

------
rip747
rule of thumb: if you don't think you need to use jQuery, use jQuery anyways.

------
lfottaviano
Don't be bad, look the positive of this site, it teachs us jquery

------
drikerf
Too bad lot's of libraries like bootstrap depend on it. Btw, published some
time ago [http://youmightnotneedjquery.com](http://youmightnotneedjquery.com)
sums it up well and a good reference for jquery people.

------
jon_kuperman
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/)

------
teknologist
jQuery should be pre-JIT-compiled in browsers. performance problem solved.

------
allenguo
Relevant: [http://vanilla-js.com/](http://vanilla-js.com/).

------
jbeja
You don't need jQuery if you don't care about ie-9 (which I don't)

------
sleek
Swing and a miss

------
hit8run
I started to use Angular instead of jQuery. It comes with jqlite and a lot of
the stuff I would use jQuery for (e.g. form validation) can still be easily
done.

~~~
hit8run
Why do I get a downvote for this? Angular 1.2 weights around 108kb and jQuery
around 1.11 around 96kb and one gets a whole lot of extra functionality with
angular if you use its strenghts correctly.

------
rip747
Actually I think the biggest reason to use jQuery is the plugin ecosystem.
Think about it... if you want to do _anything_ there is a jQuery plugin
already written to do it.

------
lostInComm
This is a bunch of drivel. Anyone who knows their ass from a hole in the
ground knows there are functions that back jQuery. jQuery just wraps in a
nice, easy-to-use solution.

