You Don’t Need jQuery

  • follow us in feedly
Published May 1, 2014 by Brad Knutson
You Don't Need jQuery

I admit, I’ve been a heavy jQuery user for the last handful of years. One of the first things I would do when starting a new project was make sure that the jQuery library was there. I settled on jQuery because honestly, it’s just simpler than vanilla Javascript. I freely admit that I’m not the most talented web developer in the world, and my Javascript programming abilities leave a lot to be desired. At first, Javascript was confusing, the syntax was frustrating, and I just didn’t enjoy using it – so I looked to jQuery for easy answers to the requirements for my projects. jQuery is incredibly easy to learn and understand, which is why it’s so widely used and supported.

But it’s time to end my marriage to jQuery, and here is why you should too.

Last weekend, I attended WordCamp Minnapolis. One of the sessions I attended was Josh Broton’s talk titled You Don’t Need jQuery. The concept of Josh’s talk wasn’t a new concept to me, but the points he made drove home the importance to me of becoming less dependent on the jQuery library.

I’d like to tackle this topic from both a Developer and a Marketer’s point of view.

Why Developers Don’t Need jQuery

First of all, everyone is doing it. Josh pointed out the internet’s ridiculous obsession with jQuery and using jQuery to solve problems – even those that were easily solvable with simple Javascript. I found a good example after about 10 seconds of searching Stack Overflow.

Javascript Stack Overflow Question

This question was posted to Javascript, and the question matter itself suggests the user is looking for a Javascript solution. The most popular answer makes me laugh.

jQuery Stack Overflow Answer

jQuery to the rescue! Notice the more logical second answer that doesn’t have as many up-votes.

By choosing jQuery over vanilla Javascript, you’re using jQuery as a crutch, and it will prevent you from becoming a better programmer. Sorry for the blunt statement, but tough love is the way to go in this situation.

When you “learn” jQuery, all you’re really doing is memorizing a few quick snippets of code and the jQuery syntax. You are not picking up any Object Oriented Programming skills.

jQuery/Javascript Meme

If you are serious about being a front-end developer, then Javascript is a must. jQuery is useful, and perhaps it’s a good place to start, just don’t use it as a crutch.

Another argument I hear is that jQuery makes the flashy transitions and animations for interactive websites easier, and therefore has it’s purpose in the world. If that is your argument, I’ll just leave this here for you…

What If I Told You CSS Could Do That

If you’d like to learn more about CSS transitions and animations, I write about them regularly.

Why Marketers Don’t Need jQuery

Or better yet, Why Marketers Should Hate jQuery.

I was on board with Josh’s talk before he even said a single word. I’ve been moving towards a more vanilla Javascript development foundation for some time now, and didn’t really need any more convincing. Then, all of a sudden, at a WordPress Developers Seminar, Josh gave some sound and startling marketing advice.

jQuery - Milliseconds Matter

“…250 milliseconds can be the difference between a return customer and an abandoned checkout cart…every 100 milliseconds of latency resulted in a 1% loss of sales…lose 20% of their traffic for each additional 100 milliseconds it takes a page to load.”

Those are some startling numbers that should get the attention of every single marketer on the planet.

If you know anything about how the web works, you probably understand that jQuery is a third-party library that needs to be included in a website in order for it to work properly. The most recent version of jQuery has lost a little weight over its predecessors, but it still weighs in at about 82KB of data. If you host jQuery locally (lots of sites do), every single site visitor’s browser will request, download, and parse the script. Computers and browsers these day are lightning fast…but this still does account for a small chunk of time.

jQuery - Low Hanging Fruit

This means that jQuery alone can “…add roughly 150ms to 1 full second of load time…”

Based on the previous slide from Josh’s presentation, this could result in up to a 10% loss in sales, all because you included jQuery on your website! A 10% loss in sales could mean the difference between keeping your job or not.

The point is…jQuery can add page load time, and with all the optimization we do as marketers, this is another way we can improve the usability and function of our websites.

jQuery Can Be Replaced With Vanilla Javascript and CSS3

After all…jQuery is Javascript.

I won’t rehash every single jQuery function and give you the equivalent vanilla Javascript function to perform the same action, as there are plenty of websites and blogs out there that will do just that. The point I wanted to drive home is that since jQuery is Javascript, anything you can do with jQuery can be done with just vanilla Javascript. jQuery is completely and entirely unnecessary.

All you have to do is learn vanilla Javascript, and possibly freshen up on CSS transitions and animations. It might sound like a lot, and it might take some time, but the ROI of such knowledge will surely be worth it.

So what do you think? Is jQuery something you use on a regular basis, or have you strayed away from it? Do you think that a new developer learning how to program should start with jQuery, or perhaps not even bother learning it at all? I’d like to know your feedback in the comments below.

I’d also like to give another quick shout-out to Josh Broton, who’s presentation prompted this post. I also stole some of the images from his slides. I’m confident he will rain hellfire down on me if this isn’t OK with him, but his slides drove the point home so good, I thought my readers would benefit from them. All credit for the images (and some the quotes) goes to Josh! Check out Josh’s website to learn more about him and see other presentations and talks he’s done. I can vouch, he’s a really smart guy.

The following two tabs change content below.
Founder at Inbounderish
Brad Knutson is a Web Developer in the Twin Cities area of Minnesota. He has experience working with WordPress and Drupal, and also has an interest in SEO and Inbound Marketing.

Keep Up-to-Date

Subscribe

Topics

See a complete list of topics discussed in blog posts here.

Check These Out

Get 2 Weeks Free! Sign Up Today! Premium Managed WordPress Hosting Genesis Framework for WordPress SEO is complex. Tools should be simple. Thesis Theme for WordPress:  Options Galore and a Helpful Support Community

4 thoughts on “You Don’t Need jQuery

  1. Paul

    Many people seem to forget one of the original main reasons javascript frameworks like jQuery were created: cross-browser compatibility. Sure, document.getElementById() is a safe example, but how about getElementsByClassName()? I personally have to make sure code works for IE8 and found out IE8 does not even support that method, but found out you CAN use the alternative querySelectorAll(). This is just one example and I’m sure there are many, many others leading to continuously browsing caniuse.com.

    Here’s a hypothetical. So eventually you write some if else blocks in your javascript code to do conditional calls per web browser. Maybe you go one step further and decide to refactor those blocks into their own functions and create a file that contains all these browser-check functions. What you’ve already started to create is your own home-brew javascript framework. But I can guarantee you the one the guys at jQuery wrote is more feature-rich and cross-browser compatible than anything you could attempt to write.

    Well anyways, I should mention that I’m partially playing devil’s advocate here. I personally try to use vanilla javascript wherever I can, but there are always cases where jQuery just does exactly what you want with a tenth of the code, and the decision to remove jQuery altogether is just too drastic. With technologies like gzip’ing content and asset compilation, these size problems almost become a non-issue. Regardless, I’m glad this article was written as some people DO need a wake-up call when it comes to their reliance on javascript frameworks.

    Reply
    1. Brad Knutson Post author

      Paul,

      You make all valid points. In Josh’s presentation, he did cover specific use cases where jQuery would still be necessary. One of those use cases was supporting older versions of Internet Explorer. It’s a shame that such a significant chunk of users prefer IE8, or even IE7 or 6. At one of my previous jobs (granted, this was 5+ years ago) the company was forced to use IE6 because of a web-based software we used that wasn’t supported in any newer version of IE. In cases like this, I would absolutely go with jQuery, because as you stated, the jQuery folks have spent years developing a cross-browser compatible framework that covers use cases we didn’t even know existed.

      Josh mentioned it in his talk, and I tend to agree with the idea – jQuery covers so many infinitely small use cases of browser/OS configurations, and because of it the library is bloated. Unless you’re running a website that gets hundreds of thousands or millions of hits a day, you’ll probably be fine ignoring those extremely small percentages of users. Josh said something along the lines of “if they are using an old version of Chromium on an outdated version of Linux and my Javascript is broken in your browser, then a lot of the internet is probably broken for you, and you’re used to it.”

      Josh was also kind enough to provide his own framework of sorts of commonly used JS functions to replace what he would have normally used jQuery for. It’s a great resource. https://github.com/joshbroton/you-dont-need-jquery/blob/master/demo/js/not-jquery.js

      Thanks for commenting Paul! I’m always up for different takes!

    2. Josh Broton

      Paul, good thoughts, and mostly on. But a couple of things to consider:

      1. Using jQuery doesn’t mean less code. It means YOU write less code, but in reality, the browser parses and executes 120KB of (unminified and ungzipped) JavaScript before it even gets to your code. TJ Van Toll said that jQuery 2 (the fast and lean one) takes 1100ms to parse and execute in older versions of the Android browser. When most of what people use it for is .addClass, .appendTo, and .ajax, that’s a completely unacceptable performance penalty.

      Also, .getElementByClassName is a bad example. .querySelectorAll uses CSS selectors (just like jQuery), and also works back through IE8. It’s also ~100x faster querying the DOM for elements than jQuery’s, EVEN THOUGH JQUERY USES IT BEHIND THE SCENES.

      2. You should NEVER be querying for the browser. 100% of your client tests should focus on functionality/capabilities. There are dozens of plugins that can change a user agent string in 10 seconds, and extensions/plugins, etc all change a browser’s capabilities.

      Simply if else it…

      var addListener = function(element, event, callback) {
      if(element.attachEvent) {
      element.attachEvent("on" + event, function() {callback.call(this);});
      } else if(element.addEventListener) {
      element.addEventListener(event, callback, false);
      }
      };

      There’s your functionality test and appropriate code inside the if else.

      3. Native/VanillaJS functions that have been introduced in the last couple of years were directly inspired by the syntax of jQuery. That’s why they are so similar.

      $(selector) -> document.querySelectorAll(selector)
      el.addClass(‘newclass’) -> el.classList.add(‘newclass’)
      el.on(‘click’, callback) -> el.addEventListener(‘click’, callback)

      Once you get the hang of it, and if you’re not supporting old browsers, it’s actually quite easy.

      Hope that helps!

Share Your Thoughts

Your email address will not be shown.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">