Season 8 Episode 7 Mar 23, 2022

All Hail jQuery (Or Not)


If you have queries about jQuery, you should probably listen to this episode.


In this episode, we talk about jQuery, Vanilla JS, and when and how you should transition out of an older technology, with Diana Le, senior web developer at topSpot Internet Marketing, Tyler Smith, software engineer at Unearth, and Chris Ferdinandi, JavaScript Educator and creator of Go Make Things.


Ben Halpern

Forem - Co-founder

Ben Halpern is co-founder and webmaster of DEV/Forem.


Chris Ferdinandi

Vanilla JS Pocket Guide - Author

Chris Ferdinandi is the author of the Vanilla JS Pocket Guide series, creator of the Vanilla JS Academy training program, and host of the Vanilla JS Podcast. My developer tips newsletter is read by over 8,500 developers each weekday.

Diana Le

TopSpot Internet Marketing - Senior Web Developer,

Diana Le is a front-end web developer who creates responsive websites using HTML, CSS and JavaScript. She is continuously learning and a huge advocate of documentation to improve team efficiency and code practices.

Tyler Smith

Unearth - Software Engineer

Tyler Smith is a full-stack developer from Bakersfield, California. He is passionate about technology, tinkering, and solving interesting problems.

Show Notes

Audio file size





[00:00:00] CF: Like as much as I backed out of jQuery into Vanilla JavaScript for performance reasons, jQuery is probably actually of like the library, it’s one of the least impactful on performance today.


[00:00:23] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a co-founder of Forem. And today, we are talking about a topic that probably impacted all of our lives as developers at some point, whether you know it or not, and that’s jQuery. We’re going to talk about jQuery, Vanilla JavaScript, transitioning from older technology to modern technology and when and how not to do that, and all things are on the subject. And we have a nice group of guests here today. Diana Le, Senior Web Developer at TopSpot Internet Marketing. Tyler Smith, Software Engineer at Autodesk. And Chris Ferdinandi, JavaScript Educator and Creator of Go Make Things. Thank you all for being here today.


[00:01:09] TS: Thank you for having us.


[00:01:10] CF: Thanks for having us.


[00:01:11] BH: So we’re going to talk all about jQuery, but first let’s go around and have everyone introduce themselves and talk a little bit about their background and how they got here. Diana, how about you kick us off?


[00:01:21] DL: So I started as a front-end web developer in 2013 at TopSpot, and I’ve been there since, and we are a digital marketing agency. So our primary focus is SEO and PPC, but our secondary function, we build custom websites for clients who also need that in addition to their marketing. So we built about anywhere from like 70 to 90 websites a year.


[00:01:43] BH: Chris?


[00:01:44] CF: So I am a self-taught front-end web developer. This is a second career for me. I used to be an HR guy. And I actually got my start through jQuery and kind of reverse engineered jQuery into Vanilla JS back in the day and had such a horrible time learning JavaScript that I decided to start teaching other people. So I’m now a JavaScript educator who tries to make people’s journey into JS a little bit easier than mine was because I failed a lot of interviews.


[00:02:18] BH: And Tyler?


[00:02:19] TS: Yeah. So I’m actually a career changer myself. I was working at a marketing agency back in 2015 and 2016. And we had a freelance web developer that we worked with who was living in a van and would go to the mountains and the beach. And I thought, “He looks like he’s having more fun than me.” And I quit my job. I started freelancing. Did that for three years. I kind of looked into it just by happenstance of people I know. My very first client was Stanley. After three years of that, primarily doing WordPress development, I worked at a company that was doing political advocacy, helping them build an advocacy platform. And as of this week, I am at Autodesk, first week, day four.


[00:03:02] BH: So let’s get into jQuery. And can we first define what jQuery is in case anybody’s young enough in their careers or maybe they’re not in web development and they’ve heard about jQuery? Can we talk about what it is and what context it has in today’s developer ecosystem?


[00:03:23] TS: So jQuery is a library for making DOM manipulations easier and uses a more concise syntax than Vanilla JavaScript. It was originally created to help smooth out some of the browser APIs back when that was a big issue in like 2006. Internet Explorer compatibility was a big issue, but it’s stuck around because it has this really concise API that requires less finagling than Vanilla JavaScript.


[00:03:58] CF: I like to jokingly refer to it as the original querySelector because getting elements by anything other than an ID used to be horribly painful. You touched on something, Tyler, that I actually think one of the reasons why you still see jQuery stick around. It’s not just for me the conciseness of jQuery, it’s the consistency. I love Vanilla JavaScript. I teach it to everybody, but from like method to method or browser API to browser API, the syntax and the approach can be so dramatically different. And the documentation also varies wildly because you’re basically relying on like MDN or like Google’s now. And one thing jQuery has always done really, really well is documentation. It’s so easy to just pick it up and start running with it.


[00:04:44] DL: And I know for me, because jQuery was so popular, there were so many plugins and additional things built on top of it. So once you get locked into jQuery, you might get locked into these other plugins and then now that Vanilla JavaScript is getting more popular and jQuery is declining, it’s like, “How do you unpack all of these things that were all bundled together and start to convert that?”


[00:05:07] BH: Why do we think fundamentally jQuery is becoming less popular instead of perhaps evolving to serve like different needs?


[00:05:20] CF: Yeah. So I advocate for browser native stuff all the time. But a lot of the amazing browser native capability that we have today only exists because jQuery paved the cow paths. So many of the things I love that we get out of the box now, like querySelector, and querySelector, all the class list API fetch, jQuery kind of showed a better way to author JavaScript APIs, and those eventually kind of absorbed into the browser. And so what I personally think we’re seeing happen with jQuery is it has done its job and is now kind of obsolete. I still think it’s amazing. Like if you find it easier to learn with, I still think it plays an important role in that, but I think what happened with jQuery should be the goal of all libraries, like React and Vue should be built with the idea of eventually becoming obsolete once browsers absorb the best parts of them. And I think we’ve seen that happen with jQuery. They never really made the pivot into state-based UI. They had a very narrow kind of focus on DOM manipulation. That’s their lane. They stuck to it. And now browsers do that really, really well out of the box. I am hard pressed to think of any specific jQuery APIs that I can’t handle more or less as simply with just the browser these days. So for me, I mean, that’s a big part of why, and I wish more libraries took kind of this eye towards eventual obsolescence. I think it’s a good thing.


[00:06:54] TS: I want to jump off what Chris said. You mentioned state-driven UI, which has become kind of the overwhelmingly popular paradigm. with Vanilla JavaScript and with jQuery, you go in and you hook into an event, right? Be it a click or be it a mouseover or something else. And then you say, “When this happens, you’re going to go and update the page to do something or to show something.” Whereas React and Vue and Svelte and some of these newer frameworks, you have data and then just kind of like server side rendering where you have all of your data and do your ifs and loops, it completely re-renders the page based on whatever data you have. So if you have blog posts and you add a new one, it goes and adds that just like you were re-rendering the page. You don’t have to go and have a template in your jQuery and render that out. And I think that’s one of the biggest reasons why jQuery is losing popularity because state-driven UI has become so popular and jQuery really has no answer for that. Vanilla JavaScript doesn’t necessarily either, but I think that’s kind of why we’re seeing a decline.


[00:08:15] DL: Yeah. All the frameworks, React and Vue, TypeScript, they’re based off of Vanilla JavaScript. So it would be better if you’ve learned Vanilla JavaScript to be able to jump into and be more flexible to learning those frameworks. Whereas jQuery, where do you go from there once you’ve mastered jQuery? Right?


[00:08:32] BH: I made a post on DEV entitled, “Do you still work with jQuery?” And Diana and Tyler, you both commented and that’s what brought you on today. So we’ve talked about jQuery is effectively in decline and it’s kind of fine if the browser is picking up the slack, but people do still use jQuery, and there’s a lot of reason for that. Can we get into that right now?


[00:08:54] DL: Yeah. So at least for me and my company, we have a pretty set build process in terms of like what we use for CMS and we build a bunch of custom sites based on custom designs. The original issue was that we supported IE much longer than like anyone else I could find, like in person or online. So basically, up to a couple of years ago, we still supported like IE 7, 8, 9. So that was a huge thing that we stuck with jQuery. Then the other thing is, like I said before, we have so many plugins, like sliders, filters, data tables that rely on jQuery that have been vetted for years, right? They have Stack Overflow posts on solutions. There’s CodePen demos. There’s years of GitHub issues that have been resolved. So in order to switch from using that, we would have to find a Vanilla JavaScript version of that. And then also ensure that we can still build it to work the same way, because otherwise, we’re just going to ask, “So why do you want to convert JavaScript? What’s the benefit for us? Are you going to be fast?” The answer is probably going to be no, because we have to relearn a lot of things and figure out how these plugins work. So it’s a matter of how do we switch these out in the least disruptive manner to the processes that we already have in place.


[00:10:09] TS: For me, there’s a few reasons. One is ecosystem. WordPress powers something like 43% of the internet according to W3Techs. And on almost anything or using any WordPress plugin, you’re already going to have jQuery out of the box. It’s just included. It’s on most of them. jQuery is on something like 80% of all sites, W3Techs. I can check that a little later, but most websites have already paid the jQuery tax and you end up getting some kind of downstream benefits from that. One is this unbelievable consistency within the API that just makes things really, really simple. Another is when you have more code, bugs increase I believe linearly with code. So if let’s say for every one in 20 lines of code, you’ve got a bug, right? With jQuery being more concise, you have some kind of downstream benefits. Let’s say that you want to select your navigation button on mobile. Right? You have to do a few things. You need to go and grab that using Document.querySelectorAll. You need to check that it exists. You need to go and then perform an action if it exists. And if not, you may break your script. With jQuery, you just do the dollar sign. Go and have that same selector. Maybe ID nav toggle. And then you can just say .click and say what the action should be. And whether or not that exists, that’s not going to break your page. You don’t need any conditional logic for that. And with just one nav toggle, not a big deal. We’re talking a few extra lines of code. For a website that has a lot of interactivity, that’s going to add up over time. Now, again, if you’re on WordPress or a lot of older bootstrap sites pre-Version 5, you’ve already paid that. I think the other reason that I really like jQuery, and this is probably going to be a controversial take, I think it’s the best web animation library that’s ever existed. As far as being able to do really common kinds of animations like slide toggle, fade in, fade out, you can do those with CSS and a little bit of JavaScript, but it’s hard. And I have been working in React for a few years now. And I’ve seen far less animation with React than with jQuery because it is just harder. jQuery makes those really practical animations that enhance user experience a lot easier.




[00:13:13] BH: The jQuery bundle size. How has that evolved over time? Like picking it off the shelf today, am I correct in thinking that we’re past the peak of how big the library has gotten and it’s gotten smaller recently or am I misunderstanding that?


[00:13:29] CF: Thirty-one kilobytes is the CDN-hosted SAS.


[00:13:34] BH: So ultimately, it’s reasonably lightweight, even compared to like times when it hasn’t been. So your convenience does not come at a major tax, especially the way some other libraries have popped up in JavaScript plans. So maybe you don’t get as much extra stuff as some of these other libraries and it purely is about ergonomics and convenience and your own bug reduction a little bit. But trade-off wise, it seems to sort of still hit a certain sweet spot depending on what you’re looking to do.


[00:14:05] CF: It makes me sad that we think 31 kilobytes is not big. I guess it would be smaller if you served it yourself on gzip diff. I think as developers, we sometimes take for granted that we may be work on faster internet connections and like really nice machines and the people who use our things don’t necessarily always do that. Tyler, you mentioned kind of the whole WordPress thing. One of the big things that pushed me into Vanilla JS was reading an article from Dave Rupert many, many years ago, about how he kind of ripped jQuery off of his site and page load time got a lot faster. And so I kind of did a similar experiment where I ripped out any jQuery using plug-in and stopped loading it on my WordPress site. And page load times increased by, I think, almost two seconds at the time. It was like pretty substantial on a cable connection. Even though I teach people JavaScript, I’m very much in the camp that like more JavaScript bad less JavaScript good. Like just as kind of an absolute maximum, if you want to like strip all the nuance out of it. I’m sympathetic to like, Diana, the stuff you were talking about, about you have a company whose whole process is built around this tooling and the conversion costs would be really, really expensive. Or like if you’re already in WordPress, Tyler, where if you’re using plugins, there’s a good chance it’s already being loaded. And I’ll confess, even like the checkout page for my ecommerce site, it’s run on WordPress and it loads jQuery, and there’s no way around that. But if that’s not the baseline you’re starting at, I feel really strongly that adding more JavaScript just to save yourself a few lines of code is not the right move.


[00:15:42] DL: Well, so actually the main reason I even looked at getting rid of jQuery was that I started to look into site speed, this was maybe four years ago, but this was before like querySelector was an ES6 thing. I thought, “I don’t want to deal with this right now.” But a year and a half ago, I started to look at it again. But then I noticed because all of our sites were loading jQuery that when I was running it through like webpage test, it was render blocking first paint blocking, loading this jQuery file on all other sites. And the only reason that converting it wasn’t as big of an issue was that on most of our sites, I was able to defer that jQuery call to later down the page. So it doesn’t impact the original load. Right? But for my personal stuff, I always try to keep it as Vanilla as I can. I don’t want to load like an entire plugin or an entire library that you only use like a couple of things because then you’re slowing down the site and you’re just winding up bloating up things. So that was one of the main reasons that I was even considering switching to a Vanilla JavaScript.


[00:16:45] TS: One of the things that I want to jump in on is to a large extent, I do agree with you. If you’re only going to use jQuery for one or two things, it’s probably not worth pulling into your site. Right? If you’re just going to have like a toggle animation on your nav, probably not worth it. But I think that in a lot of cases, we talk about page load speed is one thing, and it’s a lot of things. There’s the actual transfer of bytes over the network. There’s parsing the JavaScript, which depending on how fast of a machine you’re on could be non-trivial. But if you have your jQuery that you’re pulling in, once you pulled it in, it is cached for that site. So even though maybe on the initial page load, it’s a little bit slower. Navigations might not necessarily incur that same performance penalty. And the other thing I think about is like on a lot of the sites that I’ve done, I’ve done a lot of work with marketing agencies where they need to get sites out the door from here’s day one, we’re planning the site, day two, we’ve got three pages in production and we’re serving ad traffic from Facebook and Twitter. On those, while I’m definitely sympathetic to like, yes, if we’re able to go and get the page load speed faster, that’s good. Being able to maintain the velocity is more important on those projects. And jQuery helps me do that. I think on longer projects where I have more runway, I probably wouldn’t be as inclined to use it. If I’m not using something where it’s already included like WordPress or an older version of bootstrap, I would be hesitant to include it at all. But I still think it has a place in those ecosystems.


[00:18:37] BH: Tyler, do you think about there being an evolution where you’re needing to reevaluate your stance? So the trade-off, as you see it right now, fits in a lot of circumstances. And there could be a time where that trade-off sort of washes away with further development of browser APIs, with more normalization of other ways to do things, or even just like your jQuery developers coming in and maintaining the popularity even, is there a point in time you’d anticipate needing to change like in your career lifetime? Or do you anticipate stability with your view on how to use these technologies?


[00:19:25] TS: It’s going to change with the ecosystems. I mean, with my day job for a while now, I’ve mostly been doing React and that’s because I’m building more web application, UI things. But with websites where the main goal is content and I’ve already paid the jQuery tax from WordPress, I’m probably going to keep using that until WordPress moves away from jQuery. And it’s just because it’s already there. I’ve already used it. I’ve already paid for those kilobytes and that transfer over the network. One thing I would like to see is a library that goes and makes some of those kinds of fundamental web app animations, like the slide toggles of jQuery, kind of decouple that from jQuery. In my free time, I’ve been using a lot of GreenSock lately, the GSAP library. And it’s great, but it’s nowhere near as easy to use. I’ll move away from jQuery once it’s no longer practical. I don’t pull it into projects that don’t already have it though.


[00:20:30] CF: Just as a side note for anybody who’s listening to this, you can disable jQuery in WordPress. It does then mean that like you can’t use a bunch of plugins, which then starts to defeat the whole purpose of using WordPress.


[00:20:42] TS: Yup.


[00:20:42] CF: But if you’re a weird purist like me and you just want to prove a point, you can. At that point, you should probably just move to like a static site generator.


[00:20:51] TS: Indeed.


[00:20:53] CF: Just as an aside. But yeah, no, I do, I appreciate what you’re saying. It’s kind of tangential, but I had a conversation with someone earlier today around like developer velocity. And I feel like as an industry, we kind of obsess over developer experience or DX and kind of like keeping that inertia up. And I think sometimes that’s to the detriment of our users and the web as a whole, and kind of this whole Facebook-y move fast and break things kind of approach that we take to dev. And I’m not, Diana or Tyler, saying that’s necessarily what either of you have done. But just as a general philosophy, kind of this idea that like being able to move quickly is the most important. I sometimes think it’s to our own detriment and to the detriment of kind of this medium that we all kind of work on, a big part of the reason why the web is so bloated and fragile today is kind of because of this obsession with like just ship it out the door. And it’s funny because in the context of jQuery, I actually feel like as much as I backed out of jQuery into Vanilla JavaScript for performance reasons, jQuery is probably actually of like the library, it’s one of the least impactful on performance today. When you compare jQuery to something like React or older versions of Vue or Angular, jQuery is miles ahead of them and it’s not until you start getting into these more modern UI libraries, like Preact or Vue Version 3, which completely rewrote its engine under the hood, that we start getting back into jQuery levels of like UI performance. I just went on a really rambling tangent. But yeah, maybe we should move slow and fix things. I think that’s kind of my takeaway.


[00:22:40] TS: The listeners couldn’t see, but I was nodding furiously with the performance stuff.


[00:22:45] CF: Yeah. You talked a little about this when you mentioned, Tyler, the state-based UI thing. But like jQuery to an extent, like a lot of what you do with Vanilla JS, there are a lot more surgical in how they modify the DOM. Just nudge this, tweak this, modify this a little bit. And I know a lot of like DOM diffing in state-based UI engines try to get at that. But because they’re like crawling through like the entire UI, trying to figure out what’s different, they just ended up being so much slower and it’s not until you then get into like tools like Svelte, which let you author in a React-like style, but then like spit out something that’s more akin to like a little bit of Vanilla JS that that problem goes away. Yeah. It’s just really… I’m sorry. I’m feeling very nostalgic right now for the web of yesteryear.


[00:23:36] TS: I like it. And I’ve seen some of that too. In my personal projects, I’m not using jQuery. I’m also getting way from Vanilla JavaScript, which I had been using on like my personal site and moving towards Alpine, which is much, much smaller, and has some of those benefits of being able to use state-based UI with, I think, it’s like eight kilobytes minified or something. It’s really nice.


[00:24:06] CF: So Alpine is like mini view, right? It’s like the same kind of syntax.


[00:24:09] TS: Yeah.


[00:24:09] CF: Yeah. Evan You liked it so much that he ended up spinning out his own like, I think it’s called petite-view. It’s basically like his approach at making Vue like smaller and more modular. But yeah, I dig that.


[00:24:22] BH: Diana, I want to throw it over to you in terms of navigating some of these discussions where this decision is so much more about the entrenched processes than either personal preference or personal righteousness or anything like that. So the reasons you do a lot of jQuery development at your organization are highly pragmatic, do you want to get into how this conversation either happens or doesn’t happen at the job?


[00:24:53] DL: Well, it’s because our work is directly tied to the client site. So it’s not like if we want to be able to switch to Vanilla JavaScript, which client is going to pay the price of this? That’s going to be a very heavy price. So thinking about this for a while, and I don’t think that we can do like a sort of scorched earth where you just like throw jQuery out and just try to like jam Vanilla JavaScript, I think it’s going to have to be more like, “Let’s start using Vanilla JavaScript for all our custom stuff that we’ve been doing in terms of like DOM manipulation or anything with forms or anything with animation,” because we have our own separate custom jQuery that we write, that we could convert to JavaScript, and then we could keep jQuery for the plugins. And that would just sort of give us a way to sort of like gradually allow the developers to learn Vanilla JavaScript to get better at it and then we can slowly replace the plugins. We either find ones that work better, or some of them have converted to Vanilla JavaScript. Some of them haven’t. So that would be a slower process of trying to find like how do we convert these tools. Because I would say the biggest motivations to convert is one is like developer retainment and hiring. Right? Because developers now are learning Vanilla JavaScript or frameworks based on that. So if they find a job, they want to keep using that and not sort of go back to jQuery and then the other part would be future-proofing, getting rid of technical debt. jQuery I think will still be around for a while. But again, in order to be nimble, in order to be able to consider static site generators, Jamstack, yeah, it’s like we need to have better Vanilla JavaScript knowledge on all our developers in order to be able to consider moving that direction.


[00:26:40] CF: I like what you described Diana about moving away gradually. And I’d been nodding along Tyler as you were talking about if you’ve already paid the jQuery tax, you might as well keep using it. I think one thing we didn’t really touch on yet is that the same interaction written in jQuery versus Vanilla JS is always going to be faster in Vanilla JS, even if you’re already loading jQuery on the page, just by nature of having abstracted that away through layers of functions in the jQuery library. And for any one operation, like the difference in milliseconds is probably like so minimal that it really doesn’t matter, like really shows up in aggregate when you’re running like multiple operations at a time and things like that. But I think what I like about the approach you described Diana is even if you’re still kind of paying that cost of loading jQuery on your page, all of the interactions that you slowly start to migrate over in Vanilla JS are going to benefit from the performance gains that you get from using something a little bit more browser native. And yeah, because I get on a high horse about this A lot of times, I think people tend to assume that I’m always advocating for just like, “Toss out your code and write the whole thing from scratch.” And that is absolutely not feasible in like 90% of the cases where I’m talking to people who work in corporate environments or agencies and things like that. So I think what you described is a really sensible path for kind of gradually moving away without having to take a huge risk on a client and then, “Oh, well, now there’s all these bugs that we had already resolved in our old jQuery version. And oh, now we got to go fix those.” So this project ran way over budget or we have to eat all these costs. You can avoid a lot of that by taking a more responsible approach as you discussed.




[00:28:48] BH: Let’s rewind the clock. Can we put ourselves in the timeline of when jQuery was at its height of popularity? And for any developers who are not necessarily familiar with that period, what was that like? Because it really was different than today in terms of the expectations of like what you’re going to use for JavaScript development. And I know personally, when I was first getting into web development and the front end was not necessarily a place I really understood particularly well, I was sort of self-taught at least in JavaScript land and I really never quite learned how the DOM worked before jQuery at all. And I really couldn’t even separate them at first for myself. Just like dollar signs everywhere, that’s just what the front end was for me, like when I was kind of just not quite getting it earlier in my career.


[00:29:50] TS: I’m not sure I was a developer during the height of jQuery. I came into this in 2017. But one of the things that I experienced, and I’m sure people are still experiencing, is when I would type in how to do anything in JavaScript. The first five results would come up that are Stack Overflow. They’re from 2010 and they’re all jQuery results. And the APIs in jQuery have been so stable that the stuff from 2010, 2008, even some of the stuff from 2006 still works. And while I wasn’t around for that, seeing those odd questions, it’s still ranked really, really high. It was a lot of just being able to, “How do you do something simply?” And for some of these older questions, the browser APIs just weren’t stable enough. You would have things work different on Chrome and Firefox and Internet Explorer that jQuery was just, “Oh my gosh! I can actually make this work in a consistent way where my client or boss isn’t going to be unhappy.” That’s what I understand of it. I wasn’t doing development during the height of jQuery, though.


[00:31:04] DL: Similar to Tyler, basically if you’re using jQuery and you need to figure out how to do something, there is an answer for you immediately if you just Google it and it will be in Stack Overflow most likely. Someone solved it 10 years ago and you don’t have to worry about compatibility or anything like that because it’s just full work because it’s been vetted. It’s stable.


[00:31:25] CF: Ben, you kind of asked about like what it was like then. I feel like I learned at the perfect time because jQuery was at its peak and browser APIs weren’t exactly there when I started. But then like a year later, ES5 dropped and everything changed and the world got like infinitely better. But up to that point, you would run into these situations that Tyler and Diana just described where browser standards just were not consistently applied the way they are now. And even then, they’re not perfect, but they’re so much better where code would just be littered with like all these if/else checks. So if the browser supports this method, use it. Otherwise, you’re going to use this other hack. And like a good example is even just like we take for granted now, like you can use Fetch to make API calls. But you had XHR back in the day and certain versions of Internet Explorer had like a slightly different implementation of it. So you had to do these conditional checks. And if you weren’t going to use jQuery, everything was a bunch of if/else checks. And the problem that jQuery really solved was, like it was the one true API. They did all that behind the scenes so you didn’t have to think about it. The other thing about writing front-end code at that time though was front-ends were way less JS heavy than they are now. So even though like jQuery is 30 kilobytes of code, you were mostly using it to nudge and tweak and massage some stuff in the UI. It wasn’t like, “For the most part, we’re going to render entire multi-page apps,” or I guess single-page apps, if you’d prefer, “with JavaScript.” It was like, “Okay, we’re going to shift some elements around or we’re going to add a little bit of interactivity,” add some classes, maybe like call some API data and throw a little like progressively enhanced thing in there. And so the web was a much more kind of stable place, even though it was slower and it was less interactive. It was very less JavaScript heavy than it is now. It was also less capable. You couldn’t do as much cool stuff. So our expectations around the web have changed now that it’s way more powerful than it was a decade or so ago. But yeah, jQuery was kind of like this like hot sauce you just sprinkled on top of the website rather than being like the whole meal that it is today.


[00:33:47] BH: I remember when Fetch sort of got over a certain hump in terms of browser compatibility and then there was some polyfills if you really needed to support older stuff. To me, that was the moment where I felt like I could really write Vanilla JavaScript guilt-free.


[00:34:06] DL: Yeah. I tried to convert a jQuery. I think it was like an Ajax call. So Vanilla JavaScript was just like a few years ago. We didn’t have like the Fetch or the Promise and I'm like, “I can’t figure this out.”


[00:34:18] BH: I think we’ve had a pretty solid overall discussion and would love to give each of you the opportunity to sort of give your final takes on how to think about whether to use jQuery for a new project and where do you think you’re going to be going with it.


[00:34:37] TS: In general, I reach for jQuery when it’s already there. I think that it makes building components like navigations on mobile that slide down or accordions or some of these UI animations really practical. And I think that it’s nice to be able to use a library with a concise API that gives you less opportunity for some common bugs. That said, on a lot of my own personal projects where I’m not using WordPress, I don’t have any legacy. It’s not the first thing I reach for. I’m just not ashamed to reach for it when it’s there, because I think in 2022, even it still has its uses.


[00:35:18] DL: For me, for my personal projects, I always try to keep the Vanilla. So I always use Vanilla JavaScript. But in terms of work or veer in a similar situation as I am, I think if you’re considering like a question of whether to upgrade jQuery, I think it’s not just a question of that. It’s a question of what else in your build process that either started at the same time as you implemented jQuery, or is it dependent on jQuery? What part of that needs to change as the web development continues to evolve? Bootstrap 5 no longer requires jQuery. And my company uses Bootstrap. When I’m looking at it, I thought, “Well, we could upgrade to Bootstrap 5 or we could think about, do we even need Bootstrap at all anymore?” So it’s a question of like rethinking a lot of things that are dependent or are tied with jQuery that you may not need anymore.


[00:36:09] CF: My take on this unsurprisingly, I never reached for jQuery because I'm a Vanilla JS guy. But I do actually think it’s a really good learning tool. And so for me, because the documentation is so great, because there are so many resources around it out there, because of its long history on the web, if you’re someone who is just learning web development and you’re struggling with JavaScript, but jQuery clicks for you, I think that’s awesome because in my mind, the most important thing for any person who’s learning to code is learning inertia. And where I see people tend to give up in their learning process is when they hit a roadblock and they just can’t move past it, they can’t find a solution and they just get frustrated and give up, that’s usually where most students just kind of like quit. And I’ve found that tools like jQuery, which have a very consistent API and are well-documented, avoid a lot of those, like, “Ah, this is too hard, I give up,” kind of moments. And whether it’s jQuery or some other library, I think you can always back your way into Vanilla JavaScript as part of that learning process. And that’s probably some confirmation bias here, but that’s how I learned where I was like, “Okay, I did this thing in jQuery. Now let me convert that into Vanilla JS,” and next you start making mental maps between jQuery APIs and browser native stuff. And so for me, I think that’s where it fits into my mental model is I think it’s a really good learning tool because of its consistency and documentation. And I love working with people who have jQuery experience because it’s very easy for me to draw connections between the things they already know and how they might do that without jQuery.


[00:37:55] BH: Awesome. Thanks to all of you for coming.


[00:37:57] TS: Thanks for having me.


[00:37:57] CF: Happy to be here. Thank you for having us.


[00:38:08] BH: This show is produced and mixed by Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join us for our DevDiscuss Twitter chats every Tuesday at 9:00 PM US Eastern Time. Or if you want to start your own discussion, write a post on DEV using the #discuss. Please rate and subscribe to this show on Apple Podcasts.