I don't know if i need jQuery or not But your page is seriously a great "Cheat Sheet" for all jQuery Learners out there ! Thanks
You might not need jQuery
101–110 of 360 posts
Re: You might not need jQuery
#102No, please no. If size is an issue for some reason or you want to have no dependencies you can use something like http://zeptojs.com/ and just embed everything in one minified file. If you do things right only the functions you are actually using will get placed in there as well. Do not reinvent the wheel to solve problems that can't be solved in much cleaner and nicer ways. Managing dependencies can be annoying, but…
I believe the point is that many libraries use about 1% of jQuery. That hardly justifies pulling in the entire thing.
A personal anecdote: I recently un-jQueried a little piece of code and ended up with only a couple lines of extra code.
Certain parts of jQuery are heavenly and well worth it, but really basic usage doesn't actually save that much. $("#something") instead of document.getElementById("something") is not really buying you much in the way of cross platform-ness or thoroughly debugged code and is hardly reinventing the wheel.
Re: You might not need jQuery
#103Greenspun's Tenth, updated for 2014: "Any sufficiently complicated website contains an ad-hoc, informally-specified bug-ridden slow implementation of half of jQuery" I understand the visceral opposition, but once you start writing a fallback to support some browser (something to support IE or FF or Safari or Chrome ...) you might as well use the battle-tested solution (and write your own thing if you find performance…
git fork jquery git branch "fix-performance-issue-at- " git commit ... git push
I think you need a git checkout there. ;)
Re: You might not need jQuery
#104"You might not need Ruby on Rails. Use C to rewrite tons of shit you need." Use jQuery please. Rewriting jQuery methods with vanilla js usually turns out to be a hack job that is buggy and ugly. Just use jQuery.
Rewriting jQuery methods? If you can do it natively, and succinctly, why would you load a library abstraction to begin with?
Re: You might not need jQuery
#105Earlier quoted context omitted.
Fantastic point. Abstractions can be dangerous because they often aren't developed right. But that isn't the case here. When something like jQuery comes along, hiding so many gory details, and has been tested to death both in development and in production use all over the world, we are all better off because we remove so much failure surface area from our code.
The question is, how many of those gory details still exist in modern browsers? There's not much to test if you're just calling el.classList.add().
More to test than you thought. That just broke more than 20% of the Android installed base, since Android 2.3 doesn't work with classList.
Re: You might not need jQuery
#106No, please no. If size is an issue for some reason or you want to have no dependencies you can use something like http://zeptojs.com/ and just embed everything in one minified file. If you do things right only the functions you are actually using will get placed in there as well. Do not reinvent the wheel to solve problems that can't be solved in much cleaner and nicer ways. Managing dependencies can be annoying, but…
You don't need an abstraction to do something that's natively implemented on your platform.
Right, because why have "var x = 2+2" when you have perfectly maintainable assembly!
Re: You might not need jQuery
#107I recently did a project that didn't use jQuery in order to keep my code smaller. It was an embedded 3rd-party widget, so keeping the code as small as possible was a key requirement. The code I wrote supports down to IE7, but IE7 wasn't really the biggest issue.
The real problem with not using jQuery is that all of the collective knowledge we have about browser inconsistencies is encapsulated in jQuery. When you run into this, and Google it, you'll find a million StackOverflow answers telling you to use jQuery, and if you get lucky a blog post from 2007 that actually answers your question. The result is that you end up spending time reverse-engineering jQuery to get your thing working.
To be clear, in my case the tradeoff was worth it (the code for my entire widget including the bits of library I had to write is smaller than jQuery), but it's not a tradeoff I would make unless I had a good reason.
Re: You might not need jQuery
#108"You might not need Ruby on Rails. Use C to rewrite tons of shit you need." Use jQuery please. Rewriting jQuery methods with vanilla js usually turns out to be a hack job that is buggy and ugly. Just use jQuery.
This is exactly what we're trying to combat. For modern browsers, in many cases, it's just not true. There are a few utility methods that are tricky to replace, but you really shouldn't be including jQuery only for it's utility methods.
jQuery provides a uniform API that is guaranteed to work on supported browsers. The jQuery team does all the work to back that guarantee. If I rely on raw JS, then I'm one glitchy browser implementation away from being broken.
Even worse: suppose you build a product with the approach you recommend, it's very successful, and then your sales team makes a major sale to a stodgy old bank that still uses IE7. Or maybe you just never make the sale because you don't support the browser they use.
OK, let's say we should all turn away money from IE7 users because it's insecure and old. For OP's strategy to work, we have to assume all browsers we care about will be compatible going forward. I think this is a very unsafe assumption to make. While one small incompatibility would only be a minor annoyance, once you have more than a handful of these, a compatibility layer like jQuery again looks very nice.
And none of this even speaks to the fact that the jQuery implementation in the source article is generally at least as short and readable as the alternative, or that most people are more familiar with the jQuery version.
The only reason I can think of for dumping jQuery is maybe speed optimization, and even in that case, well-implemented jQuery should be no slower than the native speed plus the cost of a function call. If it's slow and you want to optimize something, why not optimize/bug-fix jQuery itself and help everyone, not just your one project?
Re: You might not need jQuery
#109I understand the desire for people to make pages like this (this isn't the first), but the examples are not completely honest with themselves, in my opinion. One of the biggest benefits jQuery introduces is the concept of treating single selections and multiple selections identically. While using jQuery, I can emit a $(".class").hide() call, which will apply to all elements with the matching class. Simple and elegant…
It sounds like you're looking for the querySelector and querySelectorAll methods: https://developer.mozilla.org/en-US/docs/Web/API/Document.qu...
querySelector and querySelectorAll could have been pretty great, but they suffer from some serious problems as they ended up spec'd.
The one I hate most is that qSA returns Yet Another JavaScript Collection That Is A Lot Like An Array But Isn't An Array And Therefore Doesn't Have Any Of The Nice Methods(TM). Yes, you're going to have to iterate over the thing using an index in a loop.
There's others:
http://ejohn.org/blog/thoughts-on-queryselectorall/
I'm really not sure how the standards-makers got this so terribly wrong given that the libraries had already started to solve the problem.
Re: You might not need jQuery
#110I don't understand why so many comments here seem to have skipped over the word "might" and the entire introduction. The point isn't stop using jQuery. The point isn't even don't ever use jQuery for plugins. It's simply that if you're only using a couple features of jQuery, consider eliminating the dependency. Why is there so much backlash to that?