You will probably need jQuery
gist.github.com
gist.github.com
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.
I don't understand how the presence of jQuery on a page forces you to think that way (or any specific way).
Bashing DOM nodes together to do a task is merely one manifestation of this. Multi-thousand line functions, code that makes thousands of queries to a DB and manually performs some enormous task that could have been more easily done in three slightly more complicated ones, code that just flings open a socket every time it needs to do something on the network and just starts stuffing bytes at a remote service... it's all manifestations of this.
I don't have a good word for this. I wish I did. Probably something buried on C2 somewhere if I poke around hard enough.
I suppose that's what I was getting at originally. There's absolutely nothing that removing or adding jQuery will do to impact the larger problem of treating client-side development as software engineering instead of incoherent scripting. None of the advice on the originally posted site would change those organizational/logical problems.
These are the things that get cleared up by code reviews, break sprints, bug hunts, periodic refactoring… in many cases, YANGTNI applies. That's not an excuse for long-term sloppy code, but it's an excuse for developing good practice when making changes to an existing codebase.
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.
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.
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.
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.
Moreover, nobody at apple is going to ever get fired for breaking the way your code works in mobile safari.
Breaking the way Jquery works, however, is probably a legitimately fireable offense.
* You're loading the unminified version.
* You're factoring the network request time into the benchmark. I was interested in pure parse time. Which was 27ms according to Chrome Developer Tools: http://i.imgur.com/hgFiGTu.png (the score on the page was 110ms).
I'm curious what people who complain about "parse time" consider to be an acceptable score.
Edit: Ah, I didn't realize you were discarding the network time. I was fixated on the number spat out by the page.
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.
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!
http://www.amazon.com/Pinzon-Egyptian-Cotton-725-Gram-6-Piec...
For your tears.
Kinda surprised with the downvotes considering the poor intentionally provocative OP.
How is a list of irrefutable facts a "poor intentionally provocative [original post]"?
Show me how smart you are!
Not because 32k is too much data, but because it's just not in line with how I envision dependencies anymore.
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.
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.
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.
Or in the div?
document.querySelectorAll('div').forEach