jQuery: “A Brief Introduction & Swift Farewell”
As a software engineering intern at Insider Inc. and newcomer to the web development scene in general, I was extremely surprised to see jQuery imports in client-side code on my first day at the company. I had recently finished a coding bootcamp where I learned some vanilla JavaScript, but spent most of my time using React, Redux, and other front-end libraries.
“Why isn’t a progressive company like Insider utilizing a front-end framework?” I asked myself. I had heard horror stories about legacy code bases riddled with jQuery spaghetti. Was it my fate at Insider to work with outdated libraries and spend countless hours debugging problems that hot, new frameworks could easily solve? But such was not the case, as, thankfully, I had just joined a company that values transparency, communication, and improvement.
One way our Product & Tech team promotes communication and improvement is by having open office hours. The particular codebase I was working in has bi-monthly office hours where anyone can ask questions, make suggestions, and showcase new functionality for others to use. I have learned so much in these brief hourly meetings, and I fully recommend them.
In the first office hours I attended, the first item on the agenda was removing jQuery from the code base. I was elated to hear that the engineers with much more experience than I shared my initial thoughts. They discussed ideas around who could spearhead the push, stop the bleeding (refrain from adding new jQuery code), etc. Knowing I would learn a lot about JavaScript in the process, I decided to start researching jQuery and how to replace it.
However, I was still left wondering why we weren’t replacing jQuery with another, newer front-end framework. Another office hours cleared things up. Our application doesn’t require much state management, frameworks can make optimization a lot trickier, and just like jQuery, frameworks and libraries come and go (this is especially true of front-end tooling). So now I had even more reason to buckle down and learn the ins and outs of vanilla JavaScript, which has been around for years and probably will be for many more to come unless/until web assembly takes over.
Initially, I needed to know what jQuery offered. Obviously, those who have used it will know that it offers a lot! Back in the day it helped developers do all kinds of things with relative ease including, but not limited to:
- Element selection
- DOM manipulation
- Events
- AJAX
- Cross-browser compatibility
Sure, you could do all of this stuff with vanilla JS a decade ago, but it was cumbersome and required writing/maintaining a lot of extra code. As with all libraries, jQuery solved a problem and made the development process faster, allowing developers to focus on the important stuff.
Now that I had a good idea of everything jQuery was capable of, I wondered why I saw so many articles warning of its cons. The two things I remembered from that first open office hours discussion were that it wasn’t necessary anymore (loads of advancements within JavaScript, consistent browser API compatibility, etc.) and when using any framework on the front end of a website, all of the code must be sent over the internet to the user’s browser. jQuery has a relatively large footprint of about 28kb after minification and compression.
As a member of the optimization team, the decision to start replacing all of the dollar signs (the alias for jQuery) with the word “document” felt justified. Little did I know that the endeavor would be a bit more involved than a simple search and replace.
I decided to start with files that contained a trivial amount of jQuery. Unfortunately for me, that meant trying to figure out what simply passing a function to jQuery actually did. After lots of hunting on the internet/changing search query terms (for some reason the dollar sign and some parentheses don’t play nice when doing a Google search), I figured out it was shorthand for jQuery’s ready function — similar to the DOMContentLoaded event, but with an extra sprinkle of jQuery magic.
Just adding an event listener with the type DOMContentLoaded opens up the potential for the event to happen before the event listener is added; therefore, the callback is never executed. With jQuery’s ready function, the callback is executed even if the event fires before ready is called.
// potentially never executed if event happens before event listener is added
document.addEventListener(‘DOMContentLoaded’, someFunction);// still executed regardless of when event occurs
$(someFunction);
This is a great example of jQuery’s useful functionality. After reading the documentation and looking for an alternative, I realized I would probably need to write a few utility functions to replace jQuery’s unique behavior. With the advice of some senior engineers, I decided to create a new DOM utility file where I would add my custom domReady function.
export const domReady = callBack => {
if (document.readyState !== 'loading') callBack();
else {
document.addEventListener('DOMContentLoaded', function removeAndCallback() {
document.removeEventListener('DOMContentLoaded', removeAndCallback, false);
callBack();
});
}
};The function is simple. It merely checks the document’s readyState and if it isn’t loading, executes the callback. Otherwise, it just adds a function to the DOMContentLoaded eventListener which removes that same eventListener then fires the callback.
As I continued removing jQuery, I saw a continuous pattern of selecting a group of elements and altering them in some way: changing their visibility, transforming their attributes, or just removing them from the DOM. Here I saw another opportunity to write a useful utility function.
The “allNodes” utility function I would write would take in a list of DOM nodes and then execute some code on each node passed in. My struggle writing this function lay with the decision of whether or not to use a switch statement with common DOM operations (.remove(), style.display = ‘none’, etc.) or to simply accept a callback function to execute on each loop through the provided node list.
After much thought and discussion with those same senior engineers, we decided to combine the two: allowing both string arguments mapped to various DOM manipulations and function arguments. A robust solution!
// allNodes in action
allNodes(document.querySelectorAll(‘.subscribe-btn’), ‘remove’);Now, my DOM utility file contained two functions with many more to come! As I added each function to the file, I had to ask myself how I would document these jQuery replacements and make sure everyone in the company was aware of their existence.
Another fundamental software principle emerged in my mind: documentation is key in assuring consistency, minimizing code duplication, and creating a productive, happy environment for work to be accomplished. Thankfully, Insider is a shining example of an organization that understands the value of documentation. During my short time at Insider I’ve seen the creation of a team of documentation advocates who have been spearheading the movement to improve our documentation efforts as a whole. I’m excited to document these changes and tell others about my efforts.
There is still plenty of jQuery lurking about, but as I continue my quest to make our codebase more consistent, I have made many discoveries. I originally thought most, if not all, of the code replacements would require a trivial change in syntax:
// jQuery
$(“#ad”).addClass(“viewed”);// vanilla JS
document.querySelector(“#ad”).classList.add(“viewed”);
I have come to realize that vanilla JS hasn’t even come close to containing all the functionality jQuery does and it never will. There will always be a need for libraries, helpers, and utilities. So, we as developers must decide where we want to focus our efforts.
When do we want to use the magic others have created, and when do we want to take full ownership of the magic? Either way, as new iterations and implementations replace old or outdated code, documentation is of utmost importance.
Looking for a new job opportunity? Become a part of our team! We are always looking for new Insiders.
