Note: the published date is January 7th 2019, but I wrote this up late in 2018.
I’ve been slinging JavaScript for much longer than I’ve been professionally developing with it so the first time I used jQuery for a personal project was likely a decade ago around 2008. The Internet was a much different place then. Mobile web dev was still a new concept. HTML5 was used primarily as a buzzword. If you were hip you had Firefox or Opera as your web browser (Chrome was in its infancy and while I don’t remember using it at that point Wikipedia tells me it was around), but most people stuck with Internet Explorer simply because they didn’t know any better. Internet Explorer was in version 7 (IE7) at the time and if you were to use it today I imagine it would feel very antiquated. That’s the speed technology, particularly software, moves at. While most people shrugged their shoulders and used IE7 simply because that was what they had available to them, developers were troubled by it.
I’m not familiar with where the JavaScript spec was in 2008 (at the time I wasn’t interested in the why of JavaScript so much as the how) but I know it wasn’t widely adhered to, and particularly not by Internet Explorer. Microsoft was incredibly cavalier with their browser at the time and are still facing the repercussions of their choices to this day. Thus, due to differences among the browsers, came the need for a library like jQuery. If it had not been jQuery, it would have been some other library. Anything to make development faster: to write code compatible across all of the major browsers and IE versions and to accomplish tasks in less lines. That’s bold stuff and a concept that’s not exclusive to JavaScript as a language. In lieu of a standard template library for JavaScript, you might say jQuery fulfilled that niche. If you’re writing C++ there’s no good reason to write your own linked list implementation or sort methods – the standard library or even a library like Boostr have sorted that out for you and there’s no reason to reinvent the wheel. So I’m not about to say jQuery was a mistake, but I do think using it on a new project in 2018 (or 2019, 2020, current year) likely is.
If you’re doing any sort of large scale development with JavaScript now you’re likely using one of the big frameworks like Angular, React, or Vue. All of these frameworks offer different ways to think about project structure and DOM management, but the important thing is that they all offer their own mechanisms and methodologies for setting up an interactive web page. Interactivity is the meat and potatoes of why jQuery (and it’s child libraries like jQuery Mobile and jQuery UI) became so popular to begin with. Well, that and simplified AJAX requests, but we’ll come back to that. The point is, if you’re using a development stack that includes React and company, there’s not really a place for jQuery in the mix. There are much better ways to do the kind of things you would do in jQuery built into these frameworks.
If you’re not doing large scale development, then you may be tempted to include jQuery. I’d ask you why. I recently did a code review for a junior developer, and this is essentially the code that they had written:
<script type="text/javascript" src="jquery3.1.0.js"></script>
function hideButton() {
$(‘#submit-form’’).hide();
}
That code is troubling for a number of reasons, not least of which is how simple it would be to write without jQuery.
function hideButton() {
document.getElementById(‘submit-form’).style.display = 'none’;
}
The code runs faster and more efficiently, doesn’t import a local library, works in all current browsers, and should be completely understandable to anyone familiar with the DOM. If you always use jQuery and swipe code from Stack Overflow, you’ll never become familiar with the DOM. Maybe you’ll use methods like children() or parent(), and write query selectors like $(‘#myButton’), but all of those are available to you in vanilla JS.
My feelings about jQuery probably would not be as strong if it was a more modularized library. As is, it’s fairly monolithic, encompassing DOM manipulation and traversal, AJAX requests, animations, event handling, browser polyfills, and some various other utilities. Its prevalence over the years has spawned thousands of other JavaScript libraries that rely on it as a dependency. I shudder when I see a simple widget, like a sortable table, that has a small footprint of a few kilobytes on its own, depend on jQuery which, when minified, is 80 kb.
So this is yet blog promoting vanilla JS. There’s never been a better time to learn JavaScript. Now there are a ton of programmers who actually understand how JavaScript should be written, browser support is much better, and even if you can’t take advantage of ES6 and ES7 features in all the browsers you are developing for there are plenty of great transpilers like Babel to transpile code for you.