What are the advantages of using Javascript-only versus using JQuery-only?

I have limited experience with JavaScript and JQuery coding. I've added bits and snippets of each to HTML pages but I've mostly coded server-side stuff in other languages. I've noticed that while you can theoretically do the same things using either of the two approaches (and of course you can even mix 'em up in the same project) there seems to be a tendency to always start using JQuery from the very beginning no-matter what the project demands are. 

So I'm simply wondering, are there any punctual benefits to not use JQuery-only but instead to just use plain old JavaScript?

I know this looks like a non-question because it can be said about it that "there's no definite answer" or "it can be debated for ever", but I'm actually hoping for punctual answers such as "You can do this in one approach and you cannot do it with the other".



As per scrwtp's comment, I'm not referring just to the DOM Handling part. My question is rather: JQuery is a library. For Javascript. What I find strange about this library as opposed to other libraries for other languages is that in JQyery's case it seems to be designed to be able to use it exclusively and not need to touch Javascript directly. This is as opposed to let's say Hibernate and SQL, where even though the library (or rather framework in this case, but I think the analogy still applies) takes the handle on A LOT of aspects, you still get to use SQL when using it, at least for some fringe cases. However in JQuery & Javascript case, you could do anything you do with Javascript using only JQuery (or at least that's how it seems to me).



As per Stargazer712's comment: yes, I agree with you, the question here is, as you put it "just a matter of how you will be using JavaScript". That's what I was actually thriving to ask, but I've made some bad formulations. Here's another analogy: Spring Expression Language. It's a Java library. You can't use it without Java, it's based on Java, and down through it all you still get to use Java. But in practice what you can do is add this library to a Java project, and then write all your code using Spring EL's expression language which effectively makes your code not resemble Java at all, and it's even paradigm shifting (for example you no longer have strong type enforcement when using this). While I do understand that JQuery is just a JS library, to me it seems that in practice it has the same effect as Spring EL has with Java, i.e you can only use it's APIs through out a project and avoid JavaScript's APIs. And I was wondering if that's a good thing to do, what might be the pitfalls etc. 

(and yes, after reading everyone's answers I do understand that :

a. my question is somewhat non-sensical up to a point

b. even if the question were completly accurate, the answer to it would be pretty much "no you can't just use JQuery-only all the time)

First off - it's impossible to use jQuery only, all jQuery does is add a $ object to your global scope, with a bunch of methods in it. Even more manipulative libraries like prototype aren't an alternative to javascript, they're a toolbelt to solve common problems.

The main advantages to adding jQuery to your toolbelt would be:


browser compatibility - doing something like .attr() is much easier than the native alternatives, and won't break across browsers.
simplification of usually complicated operations - if you'd like to see a well written cross browser compatible version of an XHR method, take a look at the source for $.ajax - for this method alone it's almost worth the overhead of jQ.
DOM selection - simple things like binding events & selecting DOM elements can be complicated and differ per-browser. Without a lot of knowledge, they can also be easily written poorly and slow down your page.
Access to future features - things like .indexOf and .bind are native javascript, but not yet supported by many browsers. However, using the jQuery versions of these methods will allow you to support them cross browser.


Javascript is no longer just a client side language, and because jQuery is so DOM dependent, it is a terrible candidate to move to the server. I highly recommend putting some time into understanding why you are using jQuery (asking this question is a great first step!), and evaluating when it is necessary. jQuery can be dangerous, a few of the main dangers are:


code quality - jQuery has a huge community and a low learning curve. This is a perfect storm for lots of poorly written open source plugins.
inefficiency - jQuery is easy to write inefficiently. For instance, using jQuery's each instead of for loops is unnecessary and could have a performance impact in some cases. Lots of good info about this stuff at JSPerf
bloat - jQuery is a huge library. Much of the time, you'll use a small subset of it's features, and grab the whole library. There are some great alternatives that will give you subsets of the features, like zepto.js, and underscore.js - depending on your situation, you can save some bytes by choosing the right library for your needs.


Ultimately, jQuery is an incredibly useful and helpful library, when used properly. However, it is not an alternative to javascript. It is a library, just like zepto.js, YUI, Dojo, MooTools, and Prototype - one of which may be a much better choice for your current project.

Javascript is a misunderstood language, and is only recently being regarded as something more than a scripting language by most people. I really recommend reading up on it more, here's a few good places to start:

Edit 07/2014 - I noticed this post is still getting attention, so I added a bunch of links. These are in no particular order, but should be helpful.


Ben Alman's blog - lots of good best practices here. I don't agree with all of them, but I learn new things from his blog all the time.
Code Academy - basic javascript and jQuery training. Sometimes going back to basics helps.
Javascript Garden - a post regarding the more tricky or misunderstood features of javascript. Please read this from time to time, until everything makes sense.
Bocoup - these are training classes. If you're near one, go to it. Many of the best JS speakers and teachers teach these.
Paul Irish's blog - not strictly JS, but plenty of best practices are written about here. Him and Ben's twitter feeds are both great to follow.
Javascript: The Good Parts - often referred to as 'The Javascript Bible', this book by Douglas Crockford is an amazing place to start understanding javascript.
Isaac Schlueter's Blog - Isaac is the creator of npm, and works on the node core. He writes a lot about the javascript community rather than about code conventions, but if you're really getting in to js it's a great read.
Douglas Crockford's Javascript - If Brendan Eich is the father of javascript, Douglas is javascript's outspoken uncle. He is the author of the JSON spec, the javascript bible, and lots of amazing posts on javascript's quirks and meteoric rise.
Brendan Eich's Blog - Brendan is the creator of javascript - he writes about all sorts of silly stuff on his blog, and while he has his faults as a person, his javascript posts are valuable.
James Halliday's (@substack) Blog - Substack is arguably the most important node.js developer in the community - with around 400 (and growing every day) npm modules and a guiding philosophy of tiny, unix-like modules, everything he writes is worth reading.
Max Ogden's Blog Max Ogden is another prolific node.js author, and is excellent at writing blog posts that teach you something. He's also the author (with others I believe) of javascript for cats.
Javascript for Cats - This is a short tutorial that takes you through the basics of javascript from the perspective of a cat. If you're a beginner, read through this. It's fun, and teaches in an hour what many books take weeks to communicate.
Nicholas Zakas' Blog Nicholas is the author of a few fantastic javascript books: Object Oriented Programming in Javascript, Maintainable Javascript, Professional Javascript for Web Developers, and High Performance Javascript. He focuses mainly on the client, but has a ton of best practices and performance tips.
Guillermo Rauch's Blog - Guillermo is another prolific node.js dev, mostly famous for Socket.io and Mongoose. His blog (and his new book, Smashing Node.js are both great resources.


I'm sure there's lots more great resources I'm not thinking of or don't know about, other answerers should feel free to add to that list.
