DEV Community

Santosh Viswanatham
Santosh Viswanatham

Posted on • Originally published at Medium on

Why and How we moved away from jQuery in our Web Application

Photo by Greg Rakozy on Unsplash

I got into working on a half a decade old web application and recently we started revamping our codebase to improve the performance of our App. We were trying out a few things to make things simple and removing jQuery as a dependency was one of that.

There are a ton of articles out there to help you choose if you should use jquery or not so I’m not going to talk about that(attached a few articles at the end of this article). I will instead mention the reason why we personally decided to move away from jQuery and how we updated a few of the jQuery snippets to Vanilla JS snippets in our codebase.

Why did we decide to move away from jQuery?

  • Firstly, we included jQuery for developer convenience and a lot has changed in the JS ecosystem in the past few years and honestly, we realized we could conveniently do almost everything in JavaScript now.
  • We don’t have to load a ~87kb file/code anymore in our project
  • Basic statements like selectors, event handlers, setters/getters can be written with vanilla JS. So instead of my library internally calling these basic methods, I can call them myself.
  • There is less scope to run into cross-browser compatability issues now, which was another main reason to use jQuery in the first place for many developers. So this benefit doesn’t apply anymore.
  • CSS3 Animations have far better performance than jQuery effects as CSS3 Animations run on a different thread than JavaScript in a web application. Try this out — https://greensock.com/js/speed.html to compare the performance

These reasons have strongly convinced us that we could unplug jQuery from our codebase and so we did it.

Below are a few jQuery methods that we have commonly used in our codebase. jQuery team is kind enough to list out the JavaScript alternatives to their jQuery methods in their documentation itself, so it wasn’t much of a challenge to move away from jQuery. I have also provided the alternative JavaScript code we used for every statement.

Note: These code-snippets are specific to our page design and code structure. They might differ depending on your codebase.

Selectors

We were extensively using class and id selectors to get DOM element references.

// jQuery
let searchBox = $(“.search-box”);
searchBox.on("keydown", () =>{
  // do something
});

// JavaScript
// we wanted the event listener only to the first text box anyway
let searchBox = document.getElementsByClassName("search-box")[0];
searchBox.addEventListener("keydown", () => {
  // do something
}):
Enter fullscreen mode Exit fullscreen mode

Event Handlers

The .on we were using to attach events to any DOM Element is moved instead to .addEventListener. The code example in the above section is How we did it.

Effects

The .hide and .show methods we used to render after asynchronously getting data are with display: none and display: block. Well, there is a tradeoff that was acceptable to us, that is animation. we could use CSS animation for that but initially, we decided to hide/show using display style property as we could live without animation for now. Our default display property was block for the container so this worked perfectly for us.

// jQuery
$("#results").hide(500); // to hide
$("#results").show(500); // to show

// JavaScript
document.getElementById("results").style.display = "none" // to hide
document.getElementById("results").style.display = "block" // to show
Enter fullscreen mode Exit fullscreen mode

Getting and setting attributes

// jQuery
$("#result-link").attr("href");
$("#result-link").attr("href", "https://www.google.com");

// JavaScript
document.getElementById("result-link").getAttribute("href");
document.getElementById("result-link").setAttribute("href", "https://www.google.com");
Enter fullscreen mode Exit fullscreen mode

Get/Set class names and styles

// jQuery
$( "#results" ).hasClass( "show" ); 
$( "#results" ).addClass( "show" );
$( "#results" ).removeClass( "show" );
$( "#results" ).css({top: 0})


// JavaScript
document.getElementById("results").classList.includes("show");
document.getElementById("results").classList.add("show");
document.getElementById("results").classList.remove("show");
document.getElementById("results").style.top = 0;
Enter fullscreen mode Exit fullscreen mode

.ready()

The JavaScript version of .ready function is adding handler DOMContentLoaded to the DOM element. There is an in-depth answer on StackOverflow but this is our initial workaround.

// jQuery
$(document).ready(function() {
  // Handler for .ready() called
});

// JavaScript
document.addEventListener("DOMContentLoaded", function() {
  // Handler for DOMContentLoaded
});
Enter fullscreen mode Exit fullscreen mode

Although jQuery syntax looks simple and short, we live in a world with minifiers that will make sure no extra bytes will be delivered to the client machine using JavaScript.

IMHO, Newbie Web Developers should take a look at jQuery at least once in their amateur phase. It personally helped me to gain conceptual knowledge of many in JavaScript and easily relate to them, eg: Event binding/unbinding, DOM parsing, etc. If you are using any of the modern frameworks like Angular, React, or Vue, then the developer convenience and cross-browser compatibility are already there so there is less scope that you will include jQuery in your application.

Few articles you could read if you want to decide between To use or not to use jQuery

Hope this was helpful. Thank you for reading!

Top comments (2)

Collapse
 
pantsstatuszero profile image
High Voltage Turkey

I'd added document.querySelector(".example") to your list. Gives you more jquery like querying.

w3schools.com/jsref/met_document_q...

Collapse
 
devcer profile image
Santosh Viswanatham

Yes. You are right. Also, If you want to select only the first element then getElementById have far better performance than the class selector or query selector. -> jsbench.me/jckff66u9z/1