
You will probably need jQuery - vladikoff
https://gist.github.com/rwaldron/8720084#file-reasons-md
======
shtylman
Lots of those are for Sizzle.

jQuery would be great if it broke up all those tiny little and completely
orthogonal things it does into modules so that people could use them as
needed. No one library is going to provide everything for every project but
making everyone require your ajax code when all they wanted was an `offset()`
function is equally backwards thinking. We have much better tooling now to
work with modules and to reuse code.

Arguments about CDN caching are some sort of premature optimization (or I
don't know what really). Most early projects don't need it and other projects
can trivially use many of the free (or super low cost) CDN providers if they
care that much.

My issues with jQuery are not at how awesome it has worked in the past or how
well it has hidden/handled lots of browser quirks; it is that thinking in
terms of "everything is dom manipulation" is the wrong abstraction for doing
organized and maintainable front-end code. The things jQuery does well would
be useful within smaller components or libaries but now we are back to the
original issue of jQuery is one giant blob.

~~~
donatj
Mootools, rest in peace, was completely modular and you'd check the features
you wanted see: [http://mootools.net/core/](http://mootools.net/core/)

~~~
rwaldron
MooTools modified built-in objects in future hostile ways. Do you miss that
too?

~~~
donatj
Fuck the future. JavaScript was formed full and feature complete and these
newfangled "improvements" are nothing but abominations atop its pure and
perfect form.

------
chc
These aren't really what the author claims. The first two are actually the
same thing, which doesn't appear to be jQuery working around a browser bug.

The third is just noting that a jQuery function doesn't work in some contexts.

The fourth and fifth (which, like #1, are two lines from the same comment) are
just documenting a try/catch block because something jQuery is doing might
throw an exception.

The sixth is legitimately working around a browser issue, but it's not
something you'd need to worry about unless you wanted to write that jQuery
function. Like, it doesn't actually cause problems — it's just necessary to
make that jQuery function return the exact value that they want.

The seventh is just an attribute named "support".

So far it looks like this isn't actually a list of reasons you will need
jQuery, but a list of places where the string "support" occurs in the jQuery
source. The fact that so few of them actually have anything to do with the
compatibility of client code kind of undermines the point the author is trying
to make.

~~~
rwaldron
> These aren't really what the author claims.

As the author, I can assure you they are what I claim them to be: Points in
the source code that identify some issue in some browser.

> The first two are actually the same thing,

Whoops! I thought I had removed the first one. Thanks for the bug report. The
second is true, we received bug reports when we used we had issues with "use
strict" in Firefox. I removed the first one anyway.

> The third is just noting that a jQuery function doesn't work in some
> contexts.

Wrong, it's a note about IE reporting the wrong value.

> The fourth and fifth (which, like #1, are two lines from the same comment)
> are just documenting a try/catch block because something jQuery is doing
> might throw an exception.

Because a particular browser has abnormal behaviour.

> The seventh is just an attribute named "support".

I thought removed that. It matched "support:", so you're still wrong.

> So far it looks like this isn't actually a list of reasons you will need
> jQuery

Accept that it does with the exception of two things I thought I had removed.

You owe me an apology.

~~~
chc
To be perfectly honest, I think it's a bit of a reach to suggest that I
"probably need jQuery" because strict mode limitations caused problems within
jQuery once upon a time (like, isn't that basically jQuery fixing a problem it
introduced?), or because jQuery includes a try/catch block for a case that I
will never come across in my entire life. jQuery certainly needs those, but I
don't.

I don't know exactly how many of the issues are real. Since of the ones I
listed only 3 of 5 were real even by your count, I'd be surprised if none of
the others were at all questionable. But even if we accept that they're all
real, hair-on-fire problems with vanilla JavaScript, I still think you're
going too far. At the very least, jQuery is not the only library out there
that handles compatibility issues. Lots of people who use other libraries do
not "need jQuery."

Basically, I think you have made a much broader claim than you have been able
to support so far. I'm absolutely not trying to knock the hard work of the
jQuery team or suggest that jQuery is useless. If you had just said, "jQuery
is still really useful. Here's a few things it does for you that you'd never
think of," I'd have said, "Great post — thanks for reminding everyone."
Instead, you took a very hard line that came off as pretty combative, but your
supporting examples were really shaky. So I disagreed.

~~~
rwaldron
> To be perfectly honest, I think it's a bit of a reach to suggest that I
> "probably need jQuery" because strict mode limitations caused problems
> within jQuery once upon a time (like, isn't that basically jQuery fixing a
> problem it introduced?),

No, the point was that it highlights an issue that exists with some browser.

Also, I didn't name this thread, notice in my gist it doesn't say anything
about needing anything. I was merely presenting facts.

> I'd be surprised if none of the others were at all questionable.

If you'd like to spend the time going through each one of them with me, we can
meet on IRC and work through them all. We might even be productive in
eliminating some unnecessary code if we find issues that no longer exist in a
browser's current and last current release. Let me know?

To your last point, I again, I didn't name or post this thread. Did you read
what I wrote in the gist? I think you can't really argue with this:

"The following links will bring you to line in the jQuery (current master, is
a 2.1.x build with no oldIE-specific code) source above. The line (and
probably adjacent lines) will identify some existing browser issue that jQuery
must account for when providing an API for consistent browser/DOM programming
semantics."

That's all I said. So are we square? Wanna work on these with me? I'm a nice
guy, I promise.

------
h2s
This is a bloody clever counter-argument as well as an excellent example of
the right way to use comments.

------
danheberden
how in the hell am i going to have bandwidth for jQuery _AND_ my 200K of
carousel images?!

~~~
Yver
It's not just about bandwidth, it's also about parsing and executing ~82KB of
JavaScript before doing anything on the page.

~~~
bentlegen
Do you happen to know what the performance impact of parsing and executing
~82KB of JavaScript is? Genuinely curious to know the numbers.

~~~
danheberden
I get about ~7ms in chrome on a mbp and ~200ms on my shitty nexus s.
[http://danheberden.com/tools/howlongtoloadjquery.htm](http://danheberden.com/tools/howlongtoloadjquery.htm)

~~~
nostrademons
74ms for initial load and averaging about 20ms subsequent loads on a MBP with
Chrome. Ubuntu Chrome is similar. 837ms initial load, average about 140 ms
subsequent loads on a Moto X on T-Mobile.

~~~
danheberden
I thought we were taking download time out of this

~~~
nostrademons
The "subsequent load" time should be pretty close to this. I'm getting about
20-30ms of "Evaluate script" time when I run a profile in Chrome's Timeline
tool.

------
TheSisb2
jQuery arose in an era where browser quirks and incompatibilities were
everywhere and, due to the circumstances of developing accessible websites,
enjoyed widespread adoption. Nowadays that the front-end is getting so much
attention, it pains me to see so much jQuery hate. Here are some thoughts I
feel need to be articulated:

Rather than everyone reimplementing their own utility libraries, here we have
one central library already cached by most areas of the internet, being
maintained by some of the brightest developers in JS, and provided free of
charge.

If your site permits, you are probably using the Google CDN hosted version of
jQuery. If not, you should. If you can't, then your users can handle some 80kb
one time load for a tremendous reduction in development time and increased
consistency between browsers (let's be honest, cross-browser testing is a pain
and we avoid it as much as possible).

So many people think that by using jQuery your code must immediately be bad.
Spaghetti code is code with bad structure, jQuery does not enforce any
structure so any bad code that includes jQuery is not the library's fault. I
also believe (I don't have evidence for this) that this thought tends to occur
amongst people who have learned front-end development using jQuery because it
was very accessible, and then moved on to something else, and then looking
back at their old, cruddy code developed negative feelings towards jQuery
itself. jQuery doesn't care how you structure your code; you can use jQuery
(admittedly with some difficulty) with Angular, Backbone, or any other popular
framework. But you can't use Angular with Backbone. Arguments against jQuery
that attack poor code / structure / "prettyness" are completely
misrepresenting jQuery as a library.

In that same vain, jQuery is not slow. How you use jQuery, just like how you
write your vanilla JS, is what determines performance. Some jsperfs show
jQuery being slower than vanilla JS or lodash/underscore, but that's because
jQuery is checking for many more things. You don't have to use jQuery if you
know how to improve critical code, and you really shouldn't. However, it
allows for you to write code quickly, without much complex thought for
validating against edge cases at a very negligible performance reduction.

------
jmduke
It's worth keeping in mind that the size of minified jQuery is 32kb.

~~~
Encosia
I believe that size assumes gzip on top of the minification. Minified alone,
jQuery should come in at just over 90kb.

~~~
bpicolo
gzip isn't rare, it's a standard.

~~~
Encosia
I didn't claim that it was or wasn't.

------
msoad
I love this! People think with document.querySelector and Element.classList
your need for jQuery ends!

The more DOM APIs means even more need for jQuery. Stuff like Node.bind() and
Object.observe() are some samples that need to polyfilled to make it work in
all your modern and badass browser!

~~~
taf2
I think you mean, Function.bind? see: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind)

~~~
rwaldron
No, they mean Node.bind(), it's a Polymer proposal.

------
Bahamut
Nope, don't usually need it. Also that link locked up my mobile browser for a
bit :/

~~~
danheberden
probably because github uses jquery

~~~
Bahamut
No, just the amount of text content downloaded and parsed into the DOM was the
issue.

Kinda surprised with the downvotes considering the poor intentionally
provocative OP.

~~~
rwaldron
"poor intentionally provocative OP"?

How is a list of irrefutable facts a "poor intentionally provocative [original
post]"?

Show me how smart you are!

~~~
Rumudiez
You seem very upset and are surely alone in feeling that way. Please refrain
from posting before you start yelling people who oppose the opinion of the
topic.

------
sfeng
My question is, do you really need a 9116 line library, or do you need a
handful of 100 line libraries?

Not because 32k is too much data, but because it's just not in line with how I
envision dependencies anymore.

~~~
rwaldron
Take only what you need
[https://github.com/jquery/jquery#modules](https://github.com/jquery/jquery#modules)

~~~
sfeng
But they don't exist in isolation. They can't be argued about, reasoned about,
replaced when a better way of looking at the problem is discovered, without
convincing all of the jQuery elite that it's the right move.

It's not about jQuery being too many bytes, it's about the idea that A. for
many things you can just use the browser APIs now, and B. for those handful of
things that need libraries, make them targeted and replaceable.

Beyond all that, if you use a custom build of jQuery, you can't really trust
that any library requiring it will actually work, returning to the original
point: Libraries should try to not depend on jQuery, so you can enjoy your
custom build in peace.

------
dpweb
Writing a library strictly to modern browsers and using conditionally loaded
polyfills is the better choice, than building cross-browser into the library.

The former, over time more people load less code, as they move to the new
browsers.

The latter, code doesn't decrease, but overall the amount of dead code
increases, as people move to the new browsers.

That's the cause of all this criticism of JQ now.. Over time, more of JQ code
becomes dead or unnecessary as these functions are subsumed into the native
browser.

------
scrabble
I only really want jQuery core most of the time, and then only because I'm
supporting IE7, which does not support ECMAscript 5.

It is often simpler to reuse this functionality that people have worked on
optimizing across a large number of browsers than it is to spend the time to
reimplement that functionality myself. I can better spend that time getting a
new feature working.

------
WalterSear
That's a hilarious rebuttal.

------
tks2103
just search for all the comments by rwaldron and have a good time

------
nlp
Ugh, I'm using jQuery with a CDN and my HTML5 animations still won't work on
my Nokia 3310. Am I missing something? So frustrated.

~~~
nlp
I'm so close to using flash right now. Anyone?

~~~
nlp
Do I put jQuery before the div? Or after the div?

Or in the div?

~~~
roryokane
I don’t fully understand your problem from what you’ve described, but I think
you’d be more likely to get help on Stack Overflow
([http://stackoverflow.com/tour](http://stackoverflow.com/tour)). Post your
question from the following page, editing the details as necessary:
[http://stackoverflow.com/questions/ask?title=HTML5%20animati...](http://stackoverflow.com/questions/ask?title=HTML5%20animations%20not%20working%20on%20a%20Nokia%203310%20when%20using%20jQuery&tags=jquery+css-
animations)

------
buritica
Will I?

~~~
gvickers
Yes

~~~
hoers
Really?

~~~
dllthomas
Maybe.

~~~
angersock
.promise()?

~~~
jbeja
.fail()

------
Fizzadar
pfft I'd rather not offer support for buggy/lagging-behind JS implementations.

~~~
DanBC
Remember how lousy those [Best Viewed in BroswerX] banner buttons were?

~~~
seandougall
What do you mean "were"? Mine still looks great next to the hit counter and
the link to ./guestbook.cgi!

------
korzun
[http://en.wikipedia.org/wiki/List_of_burn_centers_in_the_Uni...](http://en.wikipedia.org/wiki/List_of_burn_centers_in_the_United_States)

~~~
zebra
Dear friend, here we are trying not to be Reddit2, and while your post is
funny, it does bring nothing to the discussion.

------
msoad
I just leave this here:

    
    
        document.querySelectorAll('div').forEach

~~~
danheberden
NodeLists don't have .forEach in their prototype chain kiddo
([].forEach.call(nodeList, hollaback);)

