Getting jQuery’d × Honourable Deaths of libraries We Don’t Use Anymore

Welcome to Syntax. On this Monday, hasty treat, we're gonna be talking about Getting jQuery, what that means. Oftentimes, for a long time, people ask to get a lot of features Added to the browser. Why can't we just have jQuery in the browser? Well, here we're here to talk about things that have been added to the platform to make it so that We don't need to use libraries or maybe as many or heavy of libraries as we did in the past. My name is Scott Talinski.

I'm a developer from Denver. With me, as always, is Wes Bos. What's up, Wes?

Not too much. We've been thinking about this episode for a while. And I initially had this episode named Express is Dead. Long live Hano JS.

But The more I got into it, the more I was thinking about like there's a lot of not a lot, but there's there's several big things in web development that are no longer as highly used, no longer as popular. I'm not going to say dead. My own My whole course empire runs on Express, and I'm not going to move that anytime soon. But there's a lot of like tech, whereas like if I were starting something new today, I probably wouldn't pick that tech because browser primitives built ins are much better now. Standardization And those things are not. I'm not using them because they're bad. I'm using them because the standards are much better than when I chose that tech in the in the past. Totally. You know what's not gonna get jQuery though is

error and exception handling because There's no way they can add that to the browser, so I think we're safe there. And if you need error and exception handling, you you wanna make sure that you can find all of your bugs if they're happening. Check out [email protected].

We're proudly presented by Century over here at Syntax. So let's check it out. Let's talk about the things that have been Added to the browser. And in jQuery, honestly, that conversation was had so many times. Why can't we just add jQuery to the browser? Everybody is using jQuery, jQuery, jQuery.

And if you don't come from that world, you might not have actually been paying attention to know that, Well, it kind of was added to the browser just without the fancy dollar sign syntax.

Many of reasons why people use jQuery were for, 1, browser compatibility.

Mhmm. 2, ease of use in selecting DOM elements.

Before jQuery existed, the means in which you could select DOM elements was not nearly as elegant as, get element by ID or or, you know, what what are the other selectors we now have for for getting down elements? I'm I'm blanking on them off the top of my head for something.

Get elements by class name, get elements by tag name, get element by ID.

And that was that was Pretty much it. We also had this thing called XPath, which is pretty nifty, but it's very bizarre to write the selectors for XPass. So when jQuery came along, specifically their Sizzle library that was the selector engine inside of it, it was So much better to be able to specifically select things based on their class, based on multiple classes, based on a fuzzy match.

And the fuzzy match was nice. Yeah. Also, like all of that wasn't just with jQuery. That was just the first part was just selecting the element stuff. Then we also had a lot of things around adding event listeners and event delegation and all kinds of

Like, there was animation stuff. Animation helpers too were were were huge. Yeah. And still today, you know, jquery's whole slide up and down, jump. Maneuvering for doing accordions is still better than what we have anywhere else, honestly.

Yeah. Exactly. So Now we have a lot of these nice built ins. You can traverse the dom with next element sibling, previous element sibling, and It's just not necessary to do that type of thing. There's jQuery still extremely popular because there's a whole backlog of websites that are built with it, and It's not that big of a deal to move off of jQuery, but I think a lot of people get into trouble when they plugins that are based on jQuery. It's just not at that point. It's not worth trying to rewrite like a slider or something like that where there are libraries out there, but for a lot of people, it's like, well, You're going to spend all this time to migrate and it's going to be the exact same experience. Not worth it, you know, just the next one. We don't use that. Did you ever write your own jQuery plugins? Yeah. I had written a couple of them. I remember, like, having, like, major enlightenment When I realized what a jQuery plug in was, you could just like add it to the namespace and it accepts. It comes an element comes in and You can have an options object. I was like, Oh, wow. Like, so you mean that all this code that I was writing, I can just put that into a plug in and make it reusable. And I was still early dev,

but that was like a major enlightenment a moment in my career realizing what those were. Yeah. That was a huge deal for me as well in that same way where I just remember being like, The these Jake worry plug ins that I had thought in my mind were these big, complex, scary things We're actually very simple, and they were easy to author. My my first one was called the DTF. It was down to fade, and it was a jquery plug in that just faded in, like, your elements on your page. So when your page loaded, the elements would fade in, and it had, like, options sequentially and stuff. It was very it was very,

very basic, but it was it was one of those things where you're just like, oh, yeah. Okay. This is all easier than I thought. Exactly 1 of the Sorry, 1 more thing I want to say about the jQuery thing, and this is going to be something that we'll be hearing throughout the episode is that The beauty of standardization is that you are no longer confined to a jQuery plug in. And it's just a DOM element, meaning that other like if you have something that can accept a DOM element right now, whether that is like a React hook or whether that is a web component or whether it's a Svelte plug in or whether it's an animation library.

The fact that it's all just dumb elements at the end of the day is beautiful because then there's less glue that needs to be written. And we're starting to see that in Svelte land and web component land where,

Okay. Maybe you don't necessarily need a specific plug in for this library. Maybe it can just be a DOM element. So let's move on from the jQuery reminiscing and start to talk about how this stuff was added to the browser, whether it was things from jQuery or not. And, actually, you know, one that we initially kind of left off before we even get into x express and some of that stuff, I wanna talk about Ajax request used to do Ajax through jQuery as, that was the means of fetching content from somewhere else. And it could be XML or whatever at that point in time. You know, we we weren't doing the whole fetch a a JSON from an API a whole lot.

However, now fetch is not only here in the browser, but it's here on the server side. And we have a lovely mechanism for fetching just about anything

creating requests via the fetch function. It's true. Like, I don't know if I could.

Stuff. I definitely couldn't write an XML HTTP request. That was what we had before fetch, right? And everybody just used dollar.ajaxordollar.get because it was so much easier.

Next 1 we have here is Express.

So Express is the Node. Js server. It handles requests coming in data going back.

It handles routing and all of that good stuff around building an application. Right? And we've had Express 4 for a very, very long time, and Express 5 has been in beta for, I wanna say, probably

what would you guess? How long has Express I've been in beta. I'm gonna be real with you. I have not looked to express in quite some time, so let me I I do not know. I I to be honest, I I don't even know the difference between version 4 and 5. That's how long it's been since I've looked at Express.

Yeah.

Express is kind of interesting because I think it's probably been like 3 or 4 years since it's been in beta, and I don't know if it will ever come out because Express for people that are using it. I'm using Express for it's literally good enough for absolutely every single thing that I want to do.

And there's no features that I am missing. You know, sometimes there's nice little API improvements and whatnot, but If and when I do make a jump, it's not going to be from Express 4 to Express 5. It's going to be from Express 4 to Web standards, right? And what are the standards that are replacing Express? Well, like not all of Express is replaced by standards, but The standard in the browser and on the server is the the fetch API. So the fetch API introduces the request object, the response object, a headers object, web streams.

And the beauty of that is again, it's Standard on the from the browser and on the server. It's standard across lots of different implementations.

So whether you're in Deno, a webworker, Cloudflare Workers, BUN, Fastify, all that good stuff is they are all standardized requests and responses, meaning that You can take some sort of library that accepts a request and you can use it with the stuff that you're already using.

The Hey. Before you get it going on, let me turn that question around to you and ask you, when do you think the fur because I have the answer here. Jeff. When do you think the 1st alpha was released of Express 5? And I'll I'll link up the, the PR. I'm gonna say Late 2019. You are off by about 5 years. It was, November of 2014.

No way.

Here's the, yep. Wow. Alpha one.

The most recent alpha or the most recent beta one was 2022.

So yeah.

You're, if it if it's ever going to come out at all, man, if the first alpha release was 2014 the 1st beta release was 2022.

That's a long time. Yeah. Yeah. And I don't know. Maybe it was They decided it was, like, too big of a a jump for people, and, like, like, Xero four has sync away support.

And maybe people are just like, you know what? I'm not going to do that. It's smaller incremental upgrades to Express are maybe needed.

But what else does Express give you? It gives you routing, you know, URL pattern matching. It gives you like convenience methods for sending JSON, like with fetch request response, sending JSON as a response from a endpoint is is kind of a pain because you have to set the headers to be JSON. You have to JSON stringify it yourself, and that's a lot more work than just saying res. Json and throwing it an object, and it will do the headers and the status codes and all that good stuff for you. So, but like that's not part of the web standard. You know, a server is not part of the web standard, at least not yet. Maybe it will at some point, but.

Lots of things, specifically Hano JS is my favorite by far.

Take these standards and sort of fill in those features middleware, Routing, route matching, different get and post endpoints.

And then they they just give you the request a response object, as well as a couple of convenience methods for doing things like replying with JSON or throwing an error that has All the error constructors sort of under the hood. Yeah.

And not necessarily even a browser thing, but, you know, one of the The big reasons why many people aren't turning to something like Express nowadays is because we have all these meta frameworks.

If you're using React, you know, why not use Next. Js and get a server for free or Svelte and you get SvelteKit for free? And And I don't know what all of the different ones you use, to be honest. I know SvelteKit uses something called Polka, which is a micro web Server.

So fast, it makes you dance.

Like the, dance.

Here, I'll I'll paste it in the Polka. I thought I said polka. Polka.

And this is, 50% 30 33 to 50% faster than Express.

Ninety lines of code.

So, yeah, seems like it's pretty small and uses the express middleware style of things. So, yeah,

highly perform Express alternative. That's beautiful because, yeah, like if you aren't building a server from scratch with something like Hano, you're probably using routes in something like next or remix or SvelteKit.

And again, all of those things are they're fairly standard, right? Like, I'll say, like, 95%.

There's always some specific implementation to the framework where they add on properties to the request in the response And the like convenience methods of returning JSON might be a little bit different, but.

Stuff. Even URL, like right URL params.

All that stuff is a browser standard. So if you have a function in one of these frameworks. You can move it over to the other frameworks in probably a couple of minutes.

Word. Next 1 we have here is Underscorejs, and I'll throw in Lodash with this as well.

And this is not people always get like a little huffy when you talk about this type of thing.

And again, it's not because.

You don't necessarily need it.

You probably still will need to reach for some of the stuff that lives in Lodash or Just is one that we talk about a lot on the show.

But most like common use cases of working with data, Working with objects, arrays and working with events, things like delegation and whatnot.

Most Of those common use cases are so doable in vanilla JavaScript that you don't necessarily have to go off and reach for a library like we're getting groupby in JavaScript now. That was something I always reach for a library for because It was kind of annoying to have to write your own group buy in, in like a reduce. You can do it in a But there's always just like there's so much of like that overhead of checking if it's null and if it's not there, then create a key. And sometimes it's easier just to do it. Now we have object. Groupby and map. Groupby. I'm using it in the new syntax website. It had to polyfill it because it's not there yet. It's Not in any browsers yet, but you can polyfill it. No problem.

But what else do we have? Maps and sets take care of a lot of like the interesting data use cases. If you look at the the low or the underscore docs, which I haven't been here in quite a quite a little while, like, the lead off methods are each And that was such a the classic way of doing it is like I remember once I understood that, oh, you can use a library like Underscore at the time do all of those concepts, that's when I started really understanding JavaScript a little bit more. But then once that it got added obviously to the browser, stuff. So much easier.

I mean, underscore was was everywhere. I mean, it was baked into so many of the libraries and and Tools that you use just because it was every single utility that we would want, now we get to have. This is

it's amazing if you look at the collections. So So that's that's working with like arrays. Yep.

How many of them have landed in JavaScript? How many of these are in

JavaScript? Like like a pluck. If you have an array of objects and you want the people's names like that's a one liner like stooges.map Highly used library, and now we have I'm trying to look at the list. If there's anything in here I would still reach for, Shuffle is maybe one.

Stuff. We don't have shuffle in in JavaScript, do we? I don't think so, but I've

yeah. I don't know. I don't yeah. How often do you need to randomize an array? I think so many times now I would just go to, just Angus c just. But Yeah.

Just Copy paste. Yeah. Copy paste. Right? You can see exactly how they do it. And partition,

split list into 2 arrays, one whose elements satisfy justify predicate and one whose elements do not satisfy the predicate. So you can list. But again, that would probably be a super duced, you know, like I'm not sure if I would install something for that. Yeah, that's amazing. But like Lodash has gone a little bit more in the direction of like Lodash does so much. They do a lot of like, event stuff, debounce.

And what's the other one that I always mix up?

Bubba, the debounce and

just Throttle.

Throttle. He bounces throttle. You saying that you couldn't remember it, it removed it from my brain. I could I could see it. I just could not say it. And also, like, spreads. That was a big one.

Like Lodash had a lots of copying and data, you know, doing deep clones and whatnot. We still don't have deep clone in JavaScript. But if it's a top level clone, which is almost always what you want Yeah.

You've got that. Another one is require JS, Which, it it feels like I remember when I first saw this landing page. So this landing page for acquire dotjs is it's got a target and an arrow. It's got these really great colors. I remember seeing this as a young JavaScript developer And just really truly thing feeling like, why would I ever need something like this? Why would I never ever need a module loader in JavaScript when I can just Copy and paste my code into a file and just have it working. It felt like such overkill, but this is JavaScript Essentially, modular script loading before we had, common JS, before we had, anything.

And you can tell it's that you with use with Node, with use with jQuery, use with Dojo. The fact that they put Dojo as one of their 3 things here is is how to use.

To me, this was this was one of those ones that felt like truly the The beginning of the next level of JavaScript around the same time as, like, backbone or any of those things, and and it just felt like, Wow.

This is a a whole new world where you're writing real software.

However, you know, we we got those, features in Node first is common JS, and then we got those features now in the browser and everywhere as JavaScript modules or ESM, the import syntax that you know and love and have hopefully not had too many struggles with but probably have, you know, been upset by at some point here.

Yeah. Next 1 we have here is Left Pad. This one is a bit of a history lesson and a bit of a funny story.

So there is a module on NPM called Left Pad, which is Essentially, if you have a string, let's say I have Wes, right? And we have Scott, right? Scott has 4 letters.

Wes has 3. I want it to be 6 letters, right? So you have to pad however many letters You need to get up to 6, right? That's what Left Pad does.

And there was a very popular NPM package called Left Pad, and I think it was in 2016, the developer, 1 Friday afternoon, he just nuked it. He just took it off NPM. And at that point, you were allowed to do that. You're allowed to just delete packages on NPM. And it broke NPM itself. It broke React. I remember, like, Everybody was freaking out, and it was like a Friday afternoon and everybody's builds were breaking because the entire ecosystem was all dependent on this one, probably like 6 lines of code.

And it was all Everything came crashing down. I'm pretty sure as Brian LaRue stepped in and really grabbed the name on NPM and published it, republished it just to get everybody's bills back and running. But now you're no longer allowed to delete something off of NPM, which is Some people don't like, but also that's the house of cards we've built here, which is hilarious that the entire like Like how much damage did that 1 guy do by simply just deleting 6 lines of code? So now obviously we have that in string. Pad start.

Or you can pass it however many characters you need that thing to be. It's really popular in terminal applications because if you need to indent something

Whenever I I saw that happen, and I was just like, everybody's using this. It feels like why why am I not using this if everybody's using it? But it it's just I I'm not the type of person who has had this type of situations where I needed it.

Another huge one was, hey, grid systems.

You know, we used to have to import a massive library to do a grid system. You know, everybody used Bootstrap, but before Bootstrap Existed. There was 9, 9 60 GS. Let's see how many kilobytes 9 60 GS is. Let's see. The big old download button, let's Click that. The zipped version of it is 4.2 megabytes, but there's no way that that's the size of the CSS.

The actual CSS.

Yeah. It's about 10 kilobytes. It came with, like, all the Photoshop grids. Yeah. It's actually kinda nice that you can And they had sketch sheets that you could print off.

Dude, I loved that. We gotta have we gotta have Nathan on on the podcast, actually, because this was

Next level. This is next level, and this is you know, those of you who who use Tailwind know, the way you define Where your item existed in a grid, you'd give something a container and how many columns it had with a container underscore, let's say 12.

Then if you want a grid column to start at the left side and go from 1 and span 7, you do grid underscore seven, and it would span that length.

And then there were some other helper classes like alpha and omega.

And this has allowed you to have a grid system. You could also So build your own custom grid system with this.

And then we got things like Bootstrap that had a grid system. There was all sorts I I remember very clearly, Many times using a grid system. But nowadays, hey. Why do you need a grid system with full of classes, full of grids, Where you can build your own custom grids that are not only, like, a full on nice grid system when you need to use it, But can be fully responsive even with just one line of CSS, making it truly custom.

And now with subgrid, you can have that grid populate down into children and do all these really awesome alignments And everything without having to import a ton of CSS to do it. Yeah. I remember when

Flexbox and Grid came out, there was a big rush to make, like, the next Grid system grid system, you know, like all these in CSS. And I think we sort of realized over over the while, like you don't need a grid system for your grid system. You don't need like some CSS on top of it.

It's it's pretty good on its own. My favorite grid system was Susie,

which was a SaaS based grid system Because you could just do some really nice and easy functions to do all of your grids. That was by Miriam Suzanne who we've had on the show before. That was such a a really nice thing because it took your grid system out of classes. We no longer have to rely on dumping a bunch of Classes in our CSS to do a grid system. You can do it right there in the CSS with Susie, so that was a nice thing for me. Next up, Sass and Less and all those

frameworks. Obviously, CSS nesting variables. I think we've talked about this till we're blue in the face on the podcast in the past, but Those things are mostly not necessary. There's still a couple of use cases here and there for Sass, and we did a whole show on that. If you want to go back and listen episode 603 on

can vanilla CSS replace Sass yet? Yeah. And there was Compass too, which was an addition on to Sass the the last 2 days. For doing sprites? Yeah. Oh, yeah. Next up is socket dot I o. I never got too much into you know, evolved past socket.io? Yeah. Socket.io was was still popping. Wes, do you wanna talk about how WebSockets, You know, evolved past socket. Io? Yeah, socket. Io was like

an implementation of WebSockets that fell back to polling and had a bunch of features on top of it. But as WebSockets evolved, as we got them both in the browser and in the client, stuff. We don't necessarily need those things anymore.

Like a lot of the things we talk about today, there still are some useful features doing things like rooms where you can, like, have a room of people who you can broadcast to and and whatnot. But Sakurai Oh! Died like a valiant death. Stuff. If I if I were to say, hey, because

we don't necessarily need it like a lot of things on this list. Yeah. I think the only time I use socket. Io was in a Code Cool course. CodeSkull is a really, really great learning resource back in the day. And and along the lines of the CSS stuff, there is really too many things to list For all of the new features, whether it is, you know, we used to have to do images for border radius and things like that, but like Coupon or a scalable the Inman Flash replacement for replacing your fonts.

We can just use web fonts. I mean, there's a countless list of of things that we used to have to reach for.

In in that case, Flash to do replacements of fonts or images replacing fonts. You can now just use web fonts. Do you know who made Socket. Io? I don't.

Is it TJ Holotruck? No. Surprisingly not. It was, a Guillermo from Vercel. Oh, nice. Yeah. And there's this, Like amazing video from JSConf 2011 of him sort of explaining it and whatnot.

And it's kind of funny to look back at it. He's been involved in so many really amazing

JavaScript projects.

Honestly, why Vercel does so well is that it's Guillermo has been a dev at the forefront a lot of this JavaScript stuff from day 1. You know, like, I wonder what else what other

libraries did he build? MooTools? He well, no. Not MooTools. He looks like I'm just looking at his, oh, stuff. Mongoose? He he was involved in MooTools a lot. Yeah. Slacking? What's Slack? Going way back in his GitHub history here. But yeah.

Oh, Slackin was public Slack organizations before Discord.

Cool.

We have Siffern. This is just a funny one. As before we had web fonts, you could use Siffern to replace them with Flash. I remember that would blew people's minds. How to get that custom font. And it's not an image, you know? Yeah. And then I thought we'll talk real quick about

what do you think Will be the next things that get Jake Gray'd. You know, I think the next thing that everybody who's been listening to the show for a little bit will think of stuff. Will be date libraries, date anything involving dates. For a long time, it was like moment. Js was the one, and then date f n s came out because It was an ESM based, and you could pluck out just the stuff you need instead of loading this massive library for it.

But The new temporal date library for JavaScript well, it's not a library. The new date feature for JavaScript is going to be Really, the thing that is going to transform how we write dates and times in JavaScript.

And in fact, I've used it before via polyfill, And it is quite simply lovely. You don't need date f n s anymore. So also, I think we're starting to see rumbles of getting observables

in JavaScript. So maybe something like RxJS and libraries that are based on observables will go by the wayside because we have them.

There's also a, signals

Oh, yes. Signals. Yep.

Is it it's possible that it could come to the browser. And in fact, You know, I think that was one of the reasons why Svelte has decided to move to signals is, hey. You know, you don't have to ship all that code for your your entire reactivity

system if signals end up being part of the browser. Right? Yeah. All right, that's it. Shout out to everybody who worked on these libraries and whatnot. I thought we'd give them not an I don't even know what to call it, not an honorable death, but stuff. Just it's beautiful that we don't need these things and they were worked on for so long. Now we have them in the browser and on the server. Yeah. I I it is

stuff. But slowly and surely, all of the things that we know and use and love, we had to go to user land for will be available at our fingertips us having to install something. There it goes, just in the browser, in the engine. Love it. Alright. Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.