76

Context: I am astounded by the number of front end developers that hack at HTML, Javascript and CSS all day long and that ignore tools like jQuery ( or other equivalent helper frameworks ) and refuse to use them. I am not talking about JavaScript gurus, I am talking about in the trenches every day Joe production developers. I get a lot of arguments that are more like excuses or personal opinions that I don't think have any technical merit, I want to make sure I am not missing something.

Question: What are some empirical technical reasons not to use jQuery?

I am not looking for religious or dogmatic arguments or subjective opinions "like some other framework is better", consider jQuery the straw man for all comparable frameworks in the question.

  • 34
    I really think jQuery is making some people dumber, seriously, they think jQuery is a programming language and javascript is a framework... Soon they will ask how to add two numbers using jQuery. –  Feb 25 '11 at 17:12
  • 47
    How do you add 2 numbers using jQuery? – Prisoner ZERO Dec 05 '11 at 23:46
  • 1
    I totally admit that, using jQuery is better than vanilla JS, but i think, every web developer should know and understand what actually jQuery does before using it, and how to implement what he want without jQuery. I think many programmers don't know pure JavaScript syntax unlike jQuery and thus they make common mistakes. – shjeff Feb 07 '17 at 13:25

10 Answers10

131

Update 2015:

In this answer from 2011 I'm talking about libraries like jQuery, YUI or Prototype. Today in 2015 that reasoning is still applicable to frameworks like Angular, React or Ember. In those 4 years the technology progressed tremendously and even though I see considerably less prejudice against React or Angular than I saw against jQuery or YUI, the same kind of thinking - though to a lesser extent - is still present today.

Update 2016:

I highly recommend an article published few days ago:

  • Why jQuery? by Michael S. Mikowski, author of the Single Page Web Applications book

That article is basically a very detailed answer to this very question. Had it been available when I was writing the answer below - I would have definitely quoted it.

Original answer:

I'll answer about jQuery but those are the same arguments that I've heard against using YUI, Prototype, Dojo, Ext and few others. Main arguments that I've heard:

  1. file size, which in fact is 84.6 KB in case of jQuery 3.2.1 - probably smaller than the logo on an average website and can be served from Google's CDN which is likely to be already in the cache of most of your visitors. As using jQuery always means smaller file size of your own JavaScript files, it can actually mean smaller download, even if not already in the browser cache.

  2. speed - writing pure JavaScript may be faster, but writing portable JavaScript seems to be impossible for most of the people. A website that is faster but doesn't work on every popular browser is useless in the real world. Besides jQuery uses some pretty heavy optimizations to actually be pretty damn fast and keeps getting even faster with every release, so it's actually not so easy to write faster code by hand for anything other than trivial examples.(*)

  3. "intellectual property" - a company is scared using someone else's code - while in fact jQuery is open source and free software that is used everywhere from your grandma's blog to Amazon, from Twitter to Bank of America, from Google to Microsoft - if they can use it then any company can use it.

  4. I can't remember hearing any other argument being used seriously.

(*) Here's a trivial example: getElementById('someid') vs. jQuery('#someid')

Is using getElementById faster? Yes. And of course everyone always checks the parentNode to catch when Blackberry 4.6 returns nodes that are no longer in the document, right? jQuery does. And everyone handles the case where IE and Opera return items by name instead of ID, right? jQuery does. If you don't do it then your code is not portable and you introduce subtle bugs that can be very difficult to find. And getElementById is the most trivial example that one could possibly find - don't even get me started on events and AJAX and the DOM...

Update:

There is actually a fourth result of asking why someone doesn't want to use jQuery. I forgot to put it on this list because it is not really an answer but rather the lack of any answer. The comment I got yesterday reminded me about it. This is hardly a "technical reason" to be added to the list but may be interesting nonetheless and may actually be the most common reaction.

What I personally suspect to be the main underlying reason to all of those reactions, though, is what I believe to be the biggest obstacle to progress in computer science: "I don't want to use it because I never did, therefore it must not be that important."

It was once the reaction to optimizing assemblers, compilers, structured programming, higher level languages, garbage collection, object oriented programming, closures or pretty much everything that we now take for granted — and today it's AJAX libraries. Maybe some day no one will remember that we once used to manually interact with the raw DOM API on the application level like now no one remembers that we once used to write programs using raw, unadorned, inscrutable hexadecimal numbers.

Community
  • 1
  • 1
rsp
  • 107,747
  • 29
  • 201
  • 177
  • 3
    Too many people in the enterprise do not understand Open Source licencing. They know that the GPL is infectious and must be avoided in all software which might find its way into a product. Many of them then play it safe by banning all use of open source anywhere in the business in fear of GPL infection. – Michael Dillon Feb 24 '11 at 06:00
  • 23
    That's why I always say that Microsoft uses jQuery and that's the last company on Earth that would risk using anything that would threaten their precious intellectual property. – rsp Feb 24 '11 at 06:10
  • 6
    This is a very high quality answer and time you took to write it up is appreciated! –  Dec 06 '11 at 17:10
  • 6
    You forgot the actual main reason which is performance. jQuery is very slow compared to native JS at DOM manipulation -- this is a well-known fact. It isn't noticeable in small applications, but it does add obvious jankiness to interactions in large web apps. Also, you're wrong about filesize. Rarely will I write so much native JS that it outnumbers the amount of code in all of jQuery's library plus my application. You're being biased. jQuery is useful in building most websites and web app prototypes but there is a case for not using it: Also, there's no DOM in nodeJS. – Benny Schmidt May 31 '14 at 14:13
  • 2
    Before easy to understand hexadecimal numbers there were [plugboards](http://en.wikipedia.org/wiki/Plugboard). As of July 2010 there is still at least one production [IBM 402](http://ibm-1401.info/402.html) – Elliott Frisch May 28 '15 at 02:23
24

jQuery expresses everything in a DOM-centric paradigm which can be misleading and doesn't require any need to express things in an application pattern.

Many developers wind up programming themselves into a corner with this DOM-centric pattern and eventually realize they haven't created anything extensible or reusable.

Rebecca Murphey has a great write-up of her own switch to Dojo from jQuery - the blog post is more about why not jQuery versus why Dojo.

philwinkle
  • 7,036
  • 3
  • 27
  • 46
  • 3
    Interesting point about the DOM centric paradigm, but my question includes not wanting to use **anything**, Dojo included. –  Feb 24 '11 at 03:19
  • On that note, if you have the time you might find Rebecca's jsconfeu presentation worthwhile (and perhaps more relevant to your current interests): http://jsconfeu.blip.tv/file/4308069/ – Ken Franqueiro Feb 24 '11 at 03:26
  • 1
    I included the reference to her blog post because she talks about why *not* jQuery vs. why she chose Dojo. The main points being the reasons I detailed above. Personally, I believe that not using a framework these days stems from ignorance, pride, or both. – philwinkle Feb 24 '11 at 03:31
  • thanks for the additional link, it looks like an well thought out piece, I will definitely read it –  Feb 24 '11 at 04:15
18

One reason not to use a framework - and this is an extreme edge case - is when writing embeddable code for another website, such as a banner. Arbitrarily inserting some complicated library or another will be polluting the namespace and potentially breaking someone else's site. Not that I wouldn't put it past some advertisers to try anyway, the pond-sucking scum, but I digress...

I disapprove of adding a framework when one is already present and equally capable. I see it all too often and it's my pet hate, I see it as unwarranted bloat. That is another question entirely.

Other than that I cannot think of a justified reason not to.

clockworkgeek
  • 37,650
  • 9
  • 89
  • 127
  • 1
    this is a good answer that no one else has thought of –  Feb 27 '11 at 18:49
  • 1
    This. Only just encountered a page I had to do some maintenance on where JQuery 1.4.4 was loaded as a JS tag, and JQuery 1.3.x loaded using Google's CDN and an alternative namespace (so the $()-method became something like $jq()). – cthulhu Feb 28 '11 at 11:45
  • http://stackoverflow.com/questions/693174/is-it-possible-to-use-jquery-to-manipulate-xul-elements => not only when embedding code in another website, but in other engines that support javascript. – ribamar Dec 29 '15 at 16:40
11

filesize - but really, beyond that, it's an absolute god-send for cross-platform javascript and browser differences. You would have to have some very good reasons not to want it in your toolkit (or be a fundamentalist developer idiot).

jpea
  • 3,114
  • 3
  • 26
  • 26
  • 1
    yes, those very good reasons is what I am looking for ... –  Feb 24 '11 at 03:14
  • 13
    If I may add some balance to your *"fundamentalist developer idiot"* comment, consider the fact that there are plenty of *fundamentalist jQuery idiots* too. Those are the ones who *highly recommend* using jQuery in absolutely every situation, including when you only need 5 lines of javascript. – user113716 Feb 24 '11 at 03:42
  • I can't upvote this. Compressed jQuery is 29kb -- *a good bit smaller than most images* -- and if served from a CDN (see http://docs.jquery.com/Downloading_jQuery) then it is very well cache-able. –  Feb 24 '11 at 09:25
  • 2
    Nothing like a good, very subjective opinion to fire up the comments :) - for those folks who are only using jQuery for the ease of selectors, they could also try the selector engine it's using, Sizzle - much smaller - http://sizzlejs.com/ – jpea Feb 24 '11 at 14:13
  • @jpea: Are you referring to my comment? – user113716 Feb 24 '11 at 14:20
  • slightly, but in a humorous way - I re-read my initial answer and realized it was probably more slanted in its wording than it could have been. Probably was the few pints before I made the comment... – jpea Feb 24 '11 at 14:32
  • Sorry, even more clarity, I was referring to my initial comment stating "fundamentalist developer idiots", and not your reply. – jpea Feb 24 '11 at 14:33
  • 1
    @jpea: Pints will do that. ;o) Great point on using Sizzle. – user113716 Feb 24 '11 at 14:34
7
  • They can't justify the filesize (even though it is probably less than script which doesn't utilise the abstractions provided).
  • They don't want to rely on third party tools.
  • Their business does not want to run any libraries (for whatever reasons).
  • Their business does not want to run any JavaScript code not written by their employees.
alex
  • 479,566
  • 201
  • 878
  • 984
  • Some of those points remind me of how I thought of these frameworks 5 years ago when they were still young. At the time I didn't know nearly enough to have any appreciation for just how much stuff they save coders from having to deal with regularly, and I naturally thought, "why not just do what I need to, myself?" I'm wondering, what do you think are the chances that some companies out there *still* think like this 5 years later? For the most part unless filesize or IP is *really* a concern, I'd say they're doing themselves a grave disservice. – Ken Franqueiro Feb 24 '11 at 03:30
  • 2
    @Ken Franqueiro I've seen it here on Stack Overflow. Someone asked about doing something without jQuery, and then someone else asked *why not use jQuery?*, to which the asker replied *our company can not use any third party libraries*. Maybe they work for NASA, and the new space exploration machines use JavaScript (hey, it *is* everywhere :P) – alex Feb 24 '11 at 04:54
  • 2
    time for someone to find a new job! –  Feb 24 '11 at 05:47
6
  • Learning: To actually code everything, and learn more. (Rather than using pre-coded stuff)
  • Size: jQuery has TONS of features you might not need, why make the user download so much code if it's not going to be used?
  • Alternatives: at this point, there are dozens of more powerful, well structured web frameworks out there.
  • Flexibility: Although jQuery is really flexible, you might need something it doesn't provide.
JCOC611
  • 19,111
  • 14
  • 69
  • 90
  • 1
    "To actually code everything, and learn more." - This works for students, but if you're the guy that has to do the JS for Massive Inc's new website, you have to be able to take responsibility over your choice of using barebones JS, your own framework that invariably tries to emulate some of the existing frameworks, and have the insight and experience to prevent and fix browser compatibility bugs JQuery and similar libraries already have. See rsp's answer for a good example on that. – cthulhu Feb 28 '11 at 11:43
4

By all means, I like jQuery, but there are some reasons not to use jQuery:

  1. Download size/bandwidth: jQuery 1.5 is now over 200K uncompressed, for some the size of the library is too much to justify the benefit.
  2. Performance: Writing native JS will always be faster than abstracting it behind a library.
  3. Added complexity: Many people will download the entire jQuery library when really they only need a few neat features from it.
  4. Application Dependencies: Introducing dependencies always has its hang ups. If there is a bug in jQuery, you can debug and edit the file, but upgrading later introduces problems. You could leave the bug, but now you are dependent on jQuery's time table for a fix, not your own.
Eli
  • 17,397
  • 4
  • 36
  • 49
  • 6
    Of course, for production you should always use the minified and gzipped version, which is 29 KB at the time of this writing. Secondly, while it is true that abstractions slow performance, I trust the jQuery developers more than I trust myself in many cases, and similar; in an application I inherited, a homegrown sort (that wasn't anything immediately terrible) was an order of magnitude slower than using the tablesorter jQuery plugin. – Xiong Chiamiov Feb 24 '11 at 03:19
  • Of course. I like jQuery, but for some these are their arguments. – Eli Feb 24 '11 at 03:23
  • 3
    Google providing jQuery via their CDN means if you use that version, it is most likely already in the users local cache. –  Feb 24 '11 at 04:14
3

Because quite often it's just unnecessary. if all I want to do is validate some input, or hilight some field then it's just as easy to write simple javascript / dom code. And jQuery doesn't really help in such simple cases, so the question should be why use it?

Clearly there are many cases where it is very useful, but sometimes people seem to use it for no real reason too.

jcoder
  • 29,554
  • 19
  • 87
  • 130
  • 1
    Actually, even in trivial cases like that, a JS framework would help. Prevent cross-browser bugs with things like getElementById (see rsp's answer), get instant access to pre-built validators using the JQuery validate plugin, etc. Using JQuery would cut down development time, and development time is expensive. Especially if the 'validate some input' grows over time to include site-wide JS stuffs. – cthulhu Feb 28 '11 at 11:47
2

I would prefer to use jquery for dom manipulation or traversing the dom , which is really easy with jquery . Moreover, attaching an event or event delegation are so easy using jquery or other framework otherwise you have to write custom event attachment for IE or non IE browsers etc.

But it has some performance penalty when you use $.each instead of vanilla JS for and array.push()... other issues like if you bind an event and remove that without unbind it will have memory leak....

My conclusion is only use any framework for complex dom manipulation and rest use vanilla JS

paul
  • 1,124
  • 9
  • 27
  • 45
2

Why not use jQuery?

I can't think of a good excuse to use vanilla JavaScript over jQuery (aside from the intimidation factor of learning something new), but some people prefer other JavaScript frameworks (like the excellent MooTools) due to the philosophical differences between them.

Some people simply don't like jQuery's DSL-ish syntax, but they recognize the importance of using a robust JavaScript framework.

Personally, I love jQuery, but I know people who use other frameworks and are no less productive.

ClosureCowboy
  • 20,825
  • 13
  • 57
  • 71
  • yeah, I know this, what about the **other** people that don't recognize the importance of using a robust JavaScript framework, do they have any technically valid reasons? –  Feb 24 '11 at 05:03
  • 1
    @fuzzy: emotional reasons are far more important than technical ones in choosing tools, unless you are one of the few technical architects who has a mandate to find the best way to do things. – Michael Dillon Feb 24 '11 at 06:03
  • @Michael - I am in a position where I don't care about those types of reasons, I care about how productive my people are, just like I don't understand why some people insist on using NotePad on windows to write all their Java code, using a dedicated Java IDE will always be more productive. I care about how productive people are, and I just wanted to make sure I am not missing some valid technical reason to not insist on using something like jQuery. –  Feb 24 '11 at 06:35
  • 1
    @fuzzy lollipop: You understand that javascript libraries are just pre-written javascript code, right? – user113716 Feb 24 '11 at 14:28
  • @fuzzy lollipop: Alright, but then I don't understand your question. You're asking for technical reasons to not use prewritten code, and not subjective reasons. If javascript libraries are just javascript code that was written for you, what technical reason could there be to not use it? Any reason would have to be either subjective or a blatantly obvious reason like *"library xyz is simply broken"*. If you had a particular need, and were wondering which libraries would fulfill it, that's one thing. But obviously there's no technical and objective reason why pre-written code shouldn't be used. – user113716 Feb 24 '11 at 17:16
  • 1
    ...Reasons like filesize are subjective. What one person considers too big could be considered perfectly acceptable to another. See what I'm getting at? – user113716 Feb 24 '11 at 17:17
  • @patrick - security issues, legal issues ( licenses ), idiomatic lock in, etc. I want to have a better idea of why when my developers are giving excuses that are opinions and what may have actual technical merit. I asked the question to crowd source that I am not over looking anything that might be valid. –  Feb 24 '11 at 21:10
  • @Jarrod: Fair enough. I can see the merit in simply looking for considerations that you may have not yet made. If you're hoping to determine the merit of any particular argument that your developers have made, you may be better off making your question more specific. Just my opinion. :o) – user113716 Feb 24 '11 at 23:12