Advantages of using pure JavaScript over JQuery

Question

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)

Answer 1

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.

Answer 2

There are advantages, but it's debatable whether they really outweigh the drawbacks.

The main one is that you save bandwidth and gain faster responses. jQuery adds another ~30kb to your response. On some networks (and in some countries), that could mean a few more milliseconds. On the other hand, though, you can set up caching for it rather easily using your web server (or as Xion said, use it from Google's site so it won't impact your own, and still be cached).

The second thing is that you might only need some very simple functionality, and only downloading and setting jQuery up could take more time than simply implementing what you need.

And lastly, you might want to roll your own framework, which is mostly a bad idea, but some people have their reasons.

If however you discard jQuery simply because you're intimidated by the learning curve, then you should reconsider. Especially as it as rather gentle.

Answer 3

As far as I know there are really only two advantages of using vanilla javascript versus a library such as JQuery, MooTools, etc.

• Libraries have a payload that eats bandwidth. But as people already have pointed out in the other answers you can limit this with gzipping and caching. If you only want a subset of jQuery you can do with SizzleJS and with MooTools you have the option of selecting the feature sets that you want in the same way as what Modernizr does.
• Libraries are big and takes some time to learn. Then again, this is a one-time investment for developers... and it looks nice on your resumé to know javascript libraries.
• (BONUS) Libraries are not a silver bullet so if you like to reinvent the wheel then this is definitely way to go.

It is worth pointing out why you want to use a javascript library, for which there are plenty:

• You don't need to write your own framework to support your development. If you're curious how things work you can check out the code since it is open source.
• The libraries solves browser compatibility. Both DOM and javascript have some differences between browsers. Trust me, this is a huge time sink if you have to hack fixes yourself.
• It is de facto internet standard to use javascript libraries, most of them are well documented by now and most web developers (who know javascript) know how to use them.
• You don't really give up javascript when using a library. You still need to know Javascript with it's types, objects, how closures work, etc.
• Most libraries are modularized and it doesn't take a long time to write plugins or use require and the AMD pattern.
• CSS selecting elements from the DOM is a huge help.
• (BONUS) You can use them with CoffeeScript as well.

I used to work at a web shop that was adamant on using vanilla javascript because jQuery was big and scary. This decision, mostly influenced by a lone "javascript developer", was the source of many browser bugs and slow development and trying to get into his codebase was a hair-pulling experience. Writing your own framework might seem like a good idea, but if you want to hire new developers then they can't quickly hop in and help out. Then there is also the issue of the bus factor to consider.

As I said I used to work there... there were greener pastures elsewhere. :^)

Answer 4

I happen to mix the use of both quite a bit. The biggest reason for this is that for some applications (think chrome extensions) you don't need cross browser support. Which means that I can take advantage of new advances like css3 which with things like transitions can simplify your code a ton over the use of jquery.

Also I am often doing something custom. By all means like the others said you shouldn't re-invent the wheel. But when your asked to do some crazy functionality I often find its much easier to write it myself then to try and hack some jquery plugin that's close but not a perfect match.

I have also worked with developers that work with nothing but jquery. And I have to say that they compromised on functionality far more often then not if they couldn't find a jquery plugin that did what they wanted.

At some point in web development you will be asked to do something not pre-packaged in a library. So at that point you better make sure you understand how the base language really functions.

So TLDC: Use both, you are at a disadvantage using just vanilla and you are at a disadvantage if you don't know vanilla inside and out and insist on always using jquery.

Answer 5

The only thing I can think of that you can't do without JQuery would be to use JQuery plugins; even then, you could write your own JS library that would provide just what the plugin needs.

Think about it like this: JQuery is an open-source Javascript library written in Javascript; you can look at the source, and thereby learn how to do anything that it does.

You can't use JQuery without using plain old Javascript. You probably won't use document.getElementById, but you'll still define functions and variables in the standard Javascript ways; you might even write a standard for loop.

The main benefit to using JQuery is pretty much the same as any other 3rd party library in any language: you won't have to write as much code to implement the logic specific to your application.

Don't let the size scare you away. The CDN version is a ~33k download which will be cached by the user's browser after the first page hit.

Answer 6

If you're worried about performance, you should try to use vanilla js whenever possible. frameworks not only add bandwidth overhead but also processing overhead. And jQuery comes with browser compatibility for pretty old browsers, too.

if you're working on mobile apps or games (or both combined) you need performance and ressource efficieny first.

jQuery and plugins might speed up your development, but especially if you rely on 3rd party jquery Plugins you should know what they are doing inside. Lots of them are bad examples of code quality and efficiency.

jQuery can be 2 to 10 times slower than native JavaScript. And it can easily encourage developers to not properly design their interface and rely on jQuery selectors too much which are much slower than native.