Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

1

jQuery is just a library -- writing native JS that uses jQuery is still writing native JS. That's like asking, "What benefits are there to native C++ development?" when you're talking about "C++ development without Boost".
–
ZachMar 19 '12 at 18:20

The main goal of jQuery and other old libs was to make a facade on top of different browsers with different js interfaces (for example XMLHttpRequest vs ActiveXObject, or addEventListener vs. attachEvent, or css selectors vs xpath selectors vs no selector support, etc...) In recent browsers most of these problems do not exist, because they follow the same standards.
–
inf3rnoSep 19 '14 at 2:46

14 Answers
14

Oh wait, we already did - remember that time we met, some time ago? We talked about cars. In fact, you seemed to be quite the expert on cars. You were able to explain, in detail, all of what's right, wrong, and exciting about the latest Formula 1 race. You knew by heart all of Lamborghini's models, including their price and availability. You even had thoughts of purchasing your own Ferrari 599 GTB Fiorano and were saving up for it (I bet the steak dinner didn't help much).

While explaining the faults of Toyota in a great, excited voice, you suddenly jumped from your chair and screamed into the air, waving your fists about: "Damn it all, I'm a magnificent expert on all things related to cars! I'm going to be a car mechanic!"

And so you went. You had an interview, the Boss Man was just as impressed as I with your knowledge, and you were hired. The first client came in. His clutch was broken. You inspected it and didn't know what to do. As a matter of fact, you had absolutely no idea how to follow the advice the Boss Man gave you. You were fired.

But how could that be!? You know everything about cars! Except for ... everything about cars. You can very well know your dream car has a V12 engine, but you don't know what that actually means.

So you're not a car mechanic, really - you're a car enthusiast. And until you learn how cars work, you will remain an enthusiast.

Now let me ask you. How does $.fn.text work? And what about $.fn? What do they really mean? How does $(something) return a gigantic thingy containing things, and what is that thingy exactly? Can you replicate their functionality, at least a bit, in theory even? Can you cope without jQuery?

Saying that "native JavaScript is hard" is just ... false. First and foremost, because JavaScript as a language has nothing to do with the DOM, which is mainly what jQuery abstracts. Second because once you learn a bit about the DOM, you can already cruise through the most common cross-browser bugs. But just a little secret - everything is hard at first. Long division was a bitch in 5th grade.

As a second analogy for this answer: jQuery is to JavaScript-DOM (not JavaScript the language, just the DOM) like Array.prototype.forEach is to for. It works, for 99% of the cases. And it works well. But for that 1% which isn't covered, you need to know how to use the for loop, if only to be practical. This entire answer is based on the "purer" side of the question, and not even the technical side (the library's size, for example, and several other things as explained in Michael Dorrant's answer). Because I love JavaScript and when people seem to just throw it aside casually saying "pah, those silly javascriptians" and waving fancy white gloves, it gets down to morality.

If you can accept the fact that you'll always be a JavaScript enthusiast, then who am I to stop you? But if you want to be a JavaScript programmer, you first have to have the knowledge to at least choose between using jQuery (or any other library) and not using a library. Learn the DOM. Learn how to use it. Write your own small library or just some collection of helper functions. And once you are knowledgeable of the DOM, and you choose to use jQuery - godspeed. Laziness is awarded for those who worked hard.

@anonymousDownvoter Pray explain. Is it because you're a vegetarian? I can change the steak into tofu-burger, but can't honestly say that there is such a thing as a "great tofu-burger"
–
ZirakJan 29 '12 at 14:19

8

+1 "How does $(something) return a gigantic thingy containing things, and what is this thingy exactly?" Hah!
–
ThinkingStiffJun 29 '12 at 9:58

I wonder how often #2 actually turns out to be true. You save a 92K, potentially cached download, but you end up writing lots more boilerplate JS code.
–
Adam RackisNov 29 '11 at 5:45

4

I don't know about that. You can keep the JS to what you need, rather than including the entire library for a subset of the functionality.
–
Ryan KinalNov 29 '11 at 17:44

3

@Ryan Kinal - Adam Rackis has a good point, and if you use Google's API for loading Jquery you can load it from the same place the user has likely already retrieved it from.
–
Ben DeMottDec 1 '11 at 8:37

I disagree with #4. If the legacy code is horrible and everyone in the team agrees and it's a good idea to add jQuery and use it in future code.
–
ThiefMasterJun 28 '12 at 18:54

jQuery is simply a framework – a set of tools written in JavaScript. By using that set of tools you are still using JavaScript. Some people prefer to write JavaScript using the tools jQuery provides, some choose not to, other choose other sets of tools.

Some reasons you might want to write "pure" JavaScript without jQuery:

Pages load faster without including extra jQuery files

Some frameworks may be incompatible with jQuery

The code being written doesn't do anything that jQuery helps with

The code is being written for others to use, and requiring jQuery as a dependency would make sharing more difficult

jQuery, as any library or framework, adds another layer of bugs. I love it, but I've also lost a day looking for a bug that turned out to be in jQuery core and not my code (a rare occasion, but not that rare).

It helps less experienced Javascript developers write cleaner and more efficient code,

It's mostly cross-platform, which can be life saving when you have to deal with older browsers,

The huge gallery of plugins help me write prototypes in very short times,

The DOM makes sense,

blah blah blah...

BUT it should be never be used as a substitute of Javascript knowledge. If you don't know how to do it in pure Javascript, you may get away with a library initially but in the long run you are going to pay for it.

And of course there are all of us who've been locked in mortal combat with IE6 for quite a few years, and won't easily let go of our old school tricks in favour of a shiny new toy.

You use jQuery plugins? Aren't most of them horribly buggy and full of slow, bad code?
–
RaynosNov 29 '11 at 13:46

@Raynos The huge gallery of plugins help me write prototypes in very short times... Just prototypes, I avoid them on production code when possible. There are some plugins with excellent code of course, but you have to look very hard for them...
–
Yannis Rizos♦Nov 29 '11 at 13:54

prototypes generally means "should have been a throwaway but is now production code". If you use them on throwaway prototypes then it's fine.
–
RaynosNov 29 '11 at 14:01

@Raynos Prototyping is not only about throwaway prototypes. Evolutionary prototyping is a core process of web development... - how's that, for a late response :P
–
Yannis Rizos♦Jan 22 '12 at 17:48

"Evolutionary prototyping" is called "cut huge corners now and hope we gain more from doing so then the cost of all that code debt we are going to get". Which of course is only valid if cutting corners get's you in that magically window of time you need for your business to become a success. It's a loan.
–
RaynosJan 22 '12 at 17:57

In the browser environment you need a cross browser normalization tool. Such a tool comes in two flavours

wraps host objects with new objects which behave the same way across browsers

extend host objects to implement the DOM API.

Generally you can use these utilities in one of three ways

use small functions like addClass or setText throughout your code when and where you need them

write your own cross browser normalization library

use an existing one.

You need some mechanism of normalization otherwise you get zero cross browser support.

As for using an existing one, that's fine. I just wouldn't use jQuery. Personally I'm currently writing my own library (DOM-shim it fixes browsers without exposing a foreign propietory API. It turns your browsers into a single well behaved standardized browser).

Along with the other answers here, especially Michael Durrant's, I would saw speed is a major reason for me occasionally choosing to use raw JavaScript.

Lately I have been working on a lot of animations or other CPU-intensive tasks and some times raw JavaScript is much, much faster than if I go through jQuery.

One example is where I wanted to change the opacity of a position: fixed element in relation to how far down on a page a user has scrolled. The effect was way too slow when I used jQuery for this, causing scrolling to be jerky and the fade effect was ruined. I switched to using straight JavaScript and everything was silky smooth in all but IE <= 8.

I need to preface my answer with some open honesty. I love jQuery. It makes my life massively easier, and makes JavaScript code more declarative, which is the way I believe things should work.

jQuery does many things…

Yes you can add pluginsYes you can extend selectorsYes it simplifies animation

but jQuery doesn't do everything

Have you ever tried working in multiple window contexts with jQuery? jQuery sucks at dealing with different window contexts because it retains the original window and document context from the window in which it was called.

I've written some code here and there to make popouts*, and jQuery can simply get in the way of what I'm trying to accomplish. Adding a new reference to jQuery in the child window can often make things worse by making it more difficult to tell which jQuery context is being used.

* think of Gmail's popout for composing an email in a new window, not spammy advertising

Use it when it makes code simpler

The time to use jQuery is when you can make your code simpler, shorter, more readable, and faster.

The time to not use jQuery is when it wont make your code simpler, shorter, more readable, or faster. If you need to fine-tune load timings, you may not want to use jQuery because of the event overhead.

As you will be aware, jQuery is a general-purpose framework which provides a lot of methods which many of us don't use in our projects. (Some of them I haven't used at all.)

There are two main reasons for not using jQuery or any other well-established frameworks.

1. The project is not big or complex enough to use such a framework:
In this case, the coder takes an informed decision based on his experience and knowledge in JavaScript. This will help him to reduce the page weight and also more control on the code.

2. The coder develops his own framework
I have seen a project in my company which has its own JavaScript framework. The reason what they quote is that if they are using jQuery and there is any bug to fix in it, they have to wait till the next version. Moreover, if there is a feature to be added, they need to ask the jQuery team for it or add a plugin even though making it a plugin won't be a good idea (they gave the example of having used a .live similar thing in their framework even before it was officially added to JQuery). Having your own framework gives you more control to the code. The disadvantage is that you need to reinvent the wheel regarding browser compatibility issues, etc. Moreover, if the development process is not good, your framework will bloat and will only increase the time to maintain it.

I think people hedge against using some libraries are due to dependency on that infrastructure/library solution to perform some task.

But let's be careful to remember languages come and go like libraries in the long run.

So maybe it's temporal scope. Maybe people are hesitant to invest in a library that just might not be there - or have have as much momentum behind it in the long run.

Myself? I have no objection to using JQuery in particular. I also look at say Box2d.js or three.js and would much rather embrace them even if short term shelf life than miss out on what fruits they have to offer.

Mike bottom line is there is risk in the shelf life of a library you choose, and I think some in the javascript community may have experienced loss due to a library or project coming to an end, and may have just said - never again.

When I pick up brand new technology, a lot of times, I would start with lower-level constructs before going to higher-level ones. I'm primarily a C++/C# developer, but a while ago when I first started playing around with HTML/CSS/JavaScript, I chose not to use any framework because I wanted to first get understanding of the technology (that is, the JavaScript language itself) that those frameworks are built on top of.

Having said that, I've since discovered jQuery and would never want to go back to coding by hand what jQuery can do for you in 1-2 lines of code.

I don't know how common this is, but to me it seems that there are a lot of people who when they see the next framework/technology/language, their first response is, "not another API for me to learn!" They don't care how easy jQuery is, but they simply see it as standing in the way between them and delivering work using their "true and tried" methods. This is the same category of people who refuse to use the Boost library or any of STL and continue to use malloc for just about everything. You asked why they pick pure JavaScript over jQuery and in reality they never made the pick because most of the time they refused to evaluate jQuery in the first place and are perfectly happy with their current pace of development, no matter how slow it is.

People pick pure JavaScript over jQuery because jQuery is a horrible abstraction layer that isn't neccessary.
–
RaynosJan 28 '12 at 22:28

Of course it is, it hides away differences between browsers and that's a big thing by itself
–
KosJan 28 '12 at 22:57

@Raynos: I'm not really a web technology expert and barely an amateur at that, so I can't really defend jQuery. But from what little I've seen it's been very good to me. jQuery adds another tool your toolbox. You can use it as much or as little as you want. It never stopped you from writing pure Javascript when needed. At the same time, there are things it can accomplish with few lines of code that will take you days to write, so if it works, use those 2 lines. If it doesn't, roll your own. To say the whole thing is horrible is like buying a screwdriver and then complaining that it is a...
–
DXMJan 28 '12 at 23:31

... horrible tool to hammer nails with because the handle doesn't have enough weight
–
DXMJan 28 '12 at 23:31

1

You don't need jQuery. Browsers have this API called the DOM that allows you to do everything you want. Cross browser problems can be solved using polyfills. jQuery is a mediocre library and a mediocre solution to legacy browser support.
–
RaynosJan 29 '12 at 0:23

jQuery is a library written in and for JavaScript. The idea is it makes all the difficult / tedious JavaScript things simple, thus speeding up development time and making your scripts much more likely to work cross-browser.

JavaScript is a language whereas jQuery is a library written using
JavaScript.

Here are reasons that makes JavaScript preferable to use rather than jQuery:

It loads the whole jQuery script library every time with the page. It is drawback for
peed/ fast query processing website.

Sometimes jQuery framework collapse/conflict with others frameworks.

If you are writing simple code for just selecting an element and show alter then native JavaScript is much better.

If operations are small and performed within few line of code of JavaScript then it is not good to use jQuery.

Due to these reasons, I like to use JavaScript to avoid the jQuery framework. It is much better to learn JavaScript rather depending on such a library...

Even if you want to extend them, you need to write code in JavaScript. Which is also a big talk. Developers get dependent on these libraries, so to have control on projects, JavaScript is better than using frameworks.

I would say the main issue is that more and more people (the vast majority?) do not know how to code in JavaScript anymore. If jQuery can't do something, they can't do it.

It's getting to the point that plain javascript examples are becoming hard to come by. Nothing against jQuery; it's a great framework. I got a lot of good ideas from it, but people should learn JavaScript first and then learn a framework. I personally find my own framework more flexible and better suits my needs, and yes I do reinvent the wheel sometimes but the total control and having control over bug fixes is a huge benifit provided your willing to put the work into learning JavaScript.

Not only that. Knowing vanilla JavaScript makes it a lot more fun to play around and experiment with the newer features instead of waiting for a framework-based implementation. Also, I don't blame jQuery for this as it's mainly a DOM library, but it can be a pain to scale with large projects. Other frameworks do a better job at this; Prototype comes to mind.

In short, it's a great framework, but not the be-all end-all people make it out to be.

I think people use jQuery because it's simpler, easier, and more powerful, and because it helps them forget about IE. Besides, for customized functionalities people do use javascript.
Try referring the DOC for more details