Monday, 18 March 2013

Advantages of using pure JavaScript over JQuery


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".
==EDIT==
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).
==EDIT 2==
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)
up vote13down voteaccepted
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 atJSPerf
  • 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.jsYUIDojoMooTools, 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:
  • Ben Alman's blog - lots of good best practices here. I don't agree with all of the, but I learn new things from his blog all the time.
  • Code Academy - basic javascript training. No jQuery here. Sometimes going back to basics helps.
  • Javascript Garden - a post regarding the more tricky or misunderstood features of javascript. Pleaseread 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.
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.
shareimprove this answer
1 
+1 for the remark on JS no longer being a client-side language only and how JQuery fits with in all this. – Shivan Dragon Sep 27 '12 at 7:49
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.
shareimprove this answer
Agreed, especially about the bandwidth part. JQuery 1.8.2 has 92Kb in the minimized/obfuscated version. Agreed also that these are however not very strong reasons not to use JQuery. Thanks! – Shivan DragonSep 26 '12 at 11:11
1 
@ShivanDragon: You forgot gzip. That makes it much smaller. – ThiefMaster Sep 26 '12 at 11:41
@ThiefMaster: it's true, thanks for pointing it out. – Shivan Dragon Sep 26 '12 at 11:43
5 
If you use jQuery from CDNs (like Google one), chances are that users would have it preloaded from visiting other sites. Hence the impact on your average (albeit not maximum) response time would be smaller. – XionSep 26 '12 at 14:52
As far as I know there are really only two advantages of using vanilla javascript versus a library such asJQueryMooTools, 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 theAMD 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 quicklyhop 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. :^)
shareimprove this answer
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 usedocument.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.
shareimprove this answer
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.
shareimprove this answer
1 
pure vanilla js is the way to go! – marko Sep 27 '12 at 11:59
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.
shareimprove this answer
+1, I agree with you making games is a good reason to ditch JQuery in favour of vanilla JS, due to performance reasons. This is pretty much true for most languages when it comes to making a game with them. For example the Google guys recommend in their Android docs not only to ditch libraries when making games (in Java, for Android) but to furthermore ditch some of the good coding practices in favor of speed. – Shivan Dragon Sep 27 '12 at 7:47
My only advise, dont use jquery for every single little thing.
I saw a lot of people using jQuery for just a simple things. It's like using Photoshop for resizing images.
shareimprove this answer
Sir, I don't find your question nonsensical at all. After four years of jQuery Development and loving jQuery and JavaScript Micro frameworks, I have come to the following conclusion. "The only thing better then a JavaScript Framework, is JavaScript without a Framework."
shareimprove this answer

1 comment:

Angular Tutorial (Update to Angular 7)

As Angular 7 has just been released a few days ago. This tutorial is updated to show you how to create an Angular 7 project and the new fe...