Brian: We're rolling. Welcome to PodRocket. I'm Brian. That's Chris. How are you? Chris: I'm doing great. How are you, Brian? Brian: I am very well this morning, which we are recording in the morning. I've been yelled at before for giving that away, but I don't think really anyone cares. Everyone who's listening to this probably knows who I am at this point, but maybe they don't know who you are. So please introduce yourself. You can do a better job than I can. Chris: Doubtful. But so, hi everyone. I am Chris Ferdinandi and I help people learn vanilla JavaScript. It's my whole focus or the thing I evangelize constantly, is that there's maybe a simpler and more resilient way to build things for the web. Brian: You have a lot of stuff, I guess, is the easiest way to say it. You're working on a lot of things. You did a great job explaining it concisely. I'm interested in the... Give us the whole thing. What's the suite of projects, I suppose? Chris: Yeah. Yeah. I have a lot going on. The thing I think most people know me for, every weekday I publish a short email newsletter over at gomakethings.com, where I share just random tips, tricks, ideas, cool stuff I've found from around the web. These are the kinds of things you can just easily consume while having your morning coffee. I also have a suite of eBooks and courses over at vanillajsguides.com. Chris: Online, I call it semi asynchronous project based workshop, Vanilla JavaScript Academy at vanillajs.com, where we spend a handful of weeks together building cool projects and really just learning how to solve problems with code. Brian: I'm going to start with the first thing you said, but the asynchronous learning is interesting also. Chris: Yeah. Brian: The weekly newsletter, I'm I thinking of it right? Chris: Yeah. Actually, it's every weekday, so five days a week. Brian: Oh my God. Chris: Yeah. You would think it's a lot, and it kind of is. But I've found it's an easier cadence to keep up than once a week or once a month, just because it becomes a habit and you become really efficient at writing when you write every weekday. These are not long form essays most of the time. Every now and then they are, like I'll get on a tear about something and I'll just sit down for an hour and crank out a short story. Chris: But yeah, for the most part, it's if you imagine something that might be like a big in-depth article and then you break it up into a few small parts over a couple of days, that's usually the length. I was pushed by actually a couple of folks I know who run their own small businesses, to try doing the daily writing. I was really, really hesitant, in large part because I thought no one would want to read my thoughts that frequently. Chris: But I think the really interesting shift that happens is, because everything necessarily becomes a lot shorter because you just can't keep up a volume if it doesn't, people like it better. It's easier to read. It's not the kind of thing that comes in and then you're like, "Oh, I'll set this aside till when I get back to it later." You can read it just a couple of minutes. People seem to retain the stuff in it a lot better because it's shorter, like you're not trying to cram as much stuff into your brain in one sitting. Chris: I tend to get a lot of questions if I'm writing a series of articles. I'll get a lot of questions early on, which help me clarify the things I'm explaining later. So it's a really nice back and forth. I get a lot out of it, as someone who teaches people, because I get a lot of questions, a lot of feedback, and that helps me do what I do better. Brian: You were talking to small business owners and they inspired you to write regularly or daily really. Chris: Yeah. Brian: Do you remember when you first started? Were you terrified? Chris: Yes. Very much so. Brian: Even now, how do you... The reason I'm asking is I'm sure other people are in the same places, like they're thinking, "Should I start a newsletter? Should I not? And how am I going to come up with things to write about to this particular community?" Yeah. Chris: Yeah. Just to name names, so Jonathan Stark over at jonathanstark.com and Philip Morgan at philipmorganconsulting.com, were the two folks who really encouraged me to do this. Jonathan was my business coach at the time, and Philip was just a... I shouldn't say just, he's a friend. They had, for weeks, maybe months, been pushing me to switch my newsletter, which was at 38 subscribers at that point, to daily. And I'm like, "Look, man, there's just no way I can keep up that cadence. I can't come up with that many ideas. This will not work." Chris: They're like, "Just try it for like a month, two weeks. If you hate it, you can always switch back. You only have 38 subscribers. Who cares? It's not like you really have anything to lose." They were a lot nicer about it than I just described it. I was like, "All right, if I can come up with a month of ideas in 10 minutes, I'll give it a go." And so, I just sat down with a piece of paper, started a timer on my phone and jotted down a list. I think I came up with like 25 or 28. It wasn't quite a month, but it was close enough. Chris: It was really, really simple things like how to get an element by class in the DOM, or how to add or remove a class from an element. Not like everything you ever wanted to know, DOM manipulation, just really short focused kind of stuff. A really weird thing happened. I started writing, I did it for a week. In that week, my list that had been stuck at 38 subscribers for like two months doubled to 60, 70, something like that. It doubled. I'm bad at math. 70. There we go. Chris: I lost a few folks, but I gained some new folks, and I started getting questions back, like, "Oh, this is cool. I don't understand this part. Can you explain it more?" By the end of the month, I'd started a to-do list of article ideas as they came to me, because I started getting questions back. Instead of ending with zero when I was done with my 28 original items, I now had a list of 50 topics, because people kept writing back with questions. Chris: And so, I've heard it described as this... It's like a flywheel effect where once it starts moving, it propels itself a little bit. And so, the entire rest of my business exists because Philip and Jonathan convinced me to write every weekday, because these questions started to like... I'd notice trends. So then I started putting together some short guides around like broader topics. So I'd like take some of my newsletters, clean them up a little bit, mash them up into a book. Then I started having people say, "Hey, I learn better with video. Can you make some video courses?" Chris: So then I made video versions of the books. Then people finished all the books and they're like, "I have memorized all of these methods and I know exactly how to use them. But when I sit down to start a project, I have no idea how to get going. Can you help me with that?" That led to a whole workshop that was focused on building projects. Yeah, it's been this really weird organic thing that all starts with the newsletter decision. Chris: At this point, I have a list of about a hundred article ideas and I know half of them, I'll just never get to. I will die before I get to write them. Brian: Well, you're probably... I mean, if you have an idea, wherever it is you are or doing, you're either writing it in your phone or scratching it on pieces of paper. Then it just goes into your note-taking app of choice. Chris: Yep. Brian: I mean, I'm speaking from experience. The LogRocket content is a different animal, but there's a really linear relationship between traffic and regular posting cadence. Chris: Yeah, for sure. Brian: I think sometimes people who are first starting out or considering going into business for themselves doing this, teaching JavaScript, being an instructor, the business side or the marketing side is maybe, I don't want to say foreign, but that's not something that you were doing before, right? Chris: Yeah. Brian: That's why I asked the question. Also, it's just- Chris: It's a little terrifying, to be honest. It was, for a long time, one of my biggest hesitancies about doing this. Everybody's mileage will vary, but I will say, the thing that really helped me get comfortable with it was, first of all, you don't have to do everything. I think there's this, when you start off, there's this perspective that like, "Okay, I'm marketing. I need to run ads," just all these things. Chris: What I've found is if you pick a couple of things that you're comfortable with, that work well for you, you don't have to do all the things. Like, for me, it's stuff like, Brian, what you and I are doing now, just chatting. I can talk all day long. I'm very chatty. So this is super easy and fun. And then the newsletter. I don't really do any other marketing beyond these two things. Chris: I choose these two things because I enjoy them. I know a lot of folks really enjoy like conference talks and meetups. I get like anxious in large social situations, even pre COVID. And so, for me, that's just not really my favorite type of marketing, so I don't really do much of it. I think, for folks who are listening, who are thinking about this, do not feel like you have to do everything. Chris: And then, I think the other piece here is I always, before having my own business, thought of marketing as this icky thing. I think the reason I felt that way is because it often is. But again, it doesn't have to be. Brian: As a marketer, sorry to interrupt, as a marketer, yeah, I agree. It can be kind of icky. Chris: Yeah. Just because most of your experiences with marketing are shady marketers pushing crap products on people who don't need them. You don't have to do that. One of the things I do is sometimes I'll just go on Twitter and search for JavaScript, and then if people have questions, I'll answer them. If I have an article about it, I'll link to it. If I don't, I'll write one and link to it. That's technically marketing, but it's really just me helping people with their problems. Brian: 100%. I think all of those things, I agree with, and I think we've done. There is, first of all, that the whole message resonates with the audience. I could say that after like four plus years of doing this, that in a lot of ways, less is more. But maybe more importantly, provide value, which is an annoying thing to say. Give people stuff they would actually use and like. Brian: But you don't have to do much else. A lot of it does happen organically. So if you're feeling really overwhelmed, like, "Should I think about Twitter ads?" I mean, I've seen them, and maybe, but I don't know. I think the easiest way to do it is get people to like you and trust, and the way you do that is... Like I did the same thing. If someone has a question about a blog post that we put out, it's not that hard to just follow Twitter and answer personally and be like, "This is the author who wrote it. Here's what happened." Brian: Or if we screwed up, which I talk about maybe too often, if we screw up and someone comes back, and it's like, "Oh, we messed up. That's a bummer, but thank you for pointing it out," how do we work that? And then, almost everyone comes back and it's like, "Oh, no problem." I love the blog and that's what... It's really rare that anything negative happens. Anyway, going back to the point, you're not always guaranteed that if you build it, they will come, but kind of. Chris: One other thing, you mentioned to help people and give them things they need. One thing I don't talk about as often as I should, but so I have... Anybody who buys my stuff gets access to a Slack community that I have set up. If I were doing it today, it might end up being Discord. But same idea, just a chat space. You could even do an old school internet forum, if that's more your speed. Chris: But it was originally a nice value add for folks, like, "Hey, if you have questions about what you're learning, here you have a direct line of contact. We can chat. I can answer your questions." That was helpful. But it's become this place now where anytime I'm unsure what to do with my business, I have literally a group of customers who are hanging out, waiting to talk to me, and I can ask them questions and get immediate responses and gut check things. Chris: I'd never be like, "Hey, should I run Twitter ads?" But I might say something like, "Hey, when you're not here, where do you hang out to learn more about front-end development?" Or whatever the topic happens to be. They'll be like, "Oh, I..." Maybe it is Twitter. Maybe it's some other place. Maybe there's another community. Maybe there's a podcast they listen to all the time that would be a great place for me to run an ad or something like that. Chris: But yeah. It's such a cliche at this point, but building a community is a really powerful thing, especially if you are a business of one or a smaller company or organization, Brian: I think we're hitting all of the important cliches early on in this episode, because [inaudible 00:14:25] I say- Chris: Yeah. I forgot my bingo card, but- Brian: Somebody who's like, "Okay, Brian said provide value. If you build it, they will come." Which is, I'm not even sure half the audience will understand what I'm talking about. And then, of course, build a community. We're not lying. I mean, it does work. It's funny. When we were thinking about starting this podcast, for example, we would ask our own engineers, the same thing you would ask that Slack community, like, "Where do you guys hang..." Brian: Well, so I would ask, "What kind of podcasts do you like, or do you listen to?" I got zero helpful answers. It was all like, "I really love 18th century history podcasts," so I'm like, "Cool, man." This does not help me at all. I mean, I believe you. But in general, I think that those Discords or those private Slack communities, because like now I'm starting to see them tiered. You've got the free ones that if you're really lucky or if it's a really popular community, there's like 50,000 people in this and it becomes just totally unmanageable, even if you have moderators. Brian: Then you have the paid version, which, let's say, if you're on Substack for like 15 bucks a month, and that's like 5,000 people. That's better, but yeah, it still requires a lot of... That's a whole job in and of itself and that's not really what... The whole point wasn't to be community moderator. Chris: Yeah. Yeah. Having a community that's too big has always been my fear. It sometimes feels a little bit like... People tend to worry about scale when they're just building a project that has no customers yet. It's important to think about, but it's probably too early to worry about. I've been at this for like five or six years now and I still haven't hit a community size where I'm like, "Okay, this is like drinking from a fire hose. This doesn't really work anymore." Chris: I also really strongly believe that you get the community you deserve. And so, some of the worst communities I've been in have almost no presence from the person who started it, or like there's no expectation setting, norm modeling, for lack of a better word. Like I have a code of conduct that people have to agree to, and I am very, very strict about both pointing out when people deviate from it, or booting people entirely and refunding them for anything they've purchased if it's either too egregious or just a recurring issue. Chris: A lot of times, people do things that they just don't realize they're coming across a certain way. Just as an example, around diversity topics. Sometimes I have students who are, they're white, they're male. Maybe they grow in an area where they are not really exposed to a diverse audience and they'll use phrases or say things that they don't... Not racial slurs or anything like that. But they may say something that they don't realize is problematic. Chris: My community has gotten really good about pointing those things out for me, if I don't see it, in large part because I made a very strong point of modeling the kind of behavior I wanted to see early on. I don't have a moderator. I did for a while. Now it's just me. I think there's like 6,000 people in the Slack, although to be fair, on any given week, only about one to 300 of them are actually active. But I've been in Slacks, like you've described, or communities like you've described where there's just thousands of people firing questions into the void and no one ever responds to any of them. Brian: Well, that's the hard part, is once you get that big, there are a lot of people asking and it's not really practical for that many people to give, you don't think. I'm sure that there's a book on this somewhere, but... Chris: Yeah, for sure, for sure. It feels like one of those things, growing a community is actually harder than it sounds like it would be. I worried about it for a while and then I realized it's just not a problem I expect to have for a while. But I feel like I'll start to get a sense for when it's happening and I don't really have a plan for how to deal with it yet. But it is definitely something that's always in the back of my mind a little bit. Brian: Yeah. Well, I mean, I... Ready? Are you ready for another cliché? Chris: I am. Brian: There's an aspect of building in public, there it is, to that. I don't know what's going to happen to this, and as long as people are here for the right reasons and are behaving themselves, then sure, then it should go pretty well. And it seems like it is for you. Chris: Yeah. Yeah, so far. Brian: Well, that's all really any of us can ask. Okay. Let's pivot from business stuff. I want to move a little bit to what is it that people should know about... You're the vanilla JavaScript guy. That's how I would think about it. Is that accurate in our [crosstalk 00:20:15]- Chris: That's how I describe myself. I didn't coin the term. I didn't make the joke website. But I do spend an absurd amount of time evangelizing it. So, yeah. Okay. I think that's accurate. I've heard other people refer to me as that. And so I was like, "Oh, I like that. I'll go with that. That works." Brian: All right. Maybe there are two parts. Give us the quick... For someone who's not familiar why this so exciting. And then, I guess the second part of the question is, right now, what are the things that you're excited about or at least interested in. Sometimes those can be different. Chris: Yeah, sure. Just at a super high level, so if you've never heard the term vanilla JavaScript before, it's just a phrase that means platform native or baked into the browser, JavaScript, APIs, methods, things like that. I know a lot of folks who hate the term because they're like, "That's just JavaScript," and they're right. But these days, when you search for how to do X with JavaScript, you end up getting a ton of like React, jQuery, Underscore, Angular, Vue, kind of solutions. Chris: Vanilla JavaScript became this nice little shorthand for filtering out all that stuff. You could do Boolean searches that say, "Ignore all these phrases," but that's an unending task to keep up with them all. So just tacking vanilla JavaScript or vanilla JS onto a search, cuts most of that stuff out. It started off as a joke. Someone made this website vanilla-js.com that positions it as this hot new framework used by all the other frameworks. Chris: But the writing is so dry and so serious that if you're not versed in New England style sarcasm, it probably doesn't... I picked up on it because that's the way my friends and I talk to each other all the time. But I see a lot of beginners who are like, "I installed the file from the CDN, but nothing's loading. This doesn't seem to be working. What's going on?" And so, yeah. I spend a small amount of time every now and then seeing these tweets on Twitter and trying to explain to people what's actually going on. Chris: That's a tangent. I digress. The reason I got into this in the first place is I learned JavaScript through jQuery. At the time, I was really digging into web performance. Dave Rupert, a developer out in Texas, had written this whole thing about how he dropped jQuery for browser Native JavaScript and shaved several seconds off start render time and load time on his site. Part of that was because WordPress loves to load jQuery in the header and do all sorts of render blocking terribleness. Chris: But part of it was he stripped out a bunch of abstractions and the site started to run faster. I started digging into this and since then, a lot has changed. Browsers pulled in a ton of features inspired by jQuery. So things that used to be really hard are now really, really easy with just what's baked into the browser. Then we started to see the rise of frameworks. Chris: And so, for a handful of years now, I've spent a lot of time talking about how these tools are awesome for a very specific group of things, for which they were built. They're absolutely terrible for both developers and the people who use the things they build for a whole large set of other things. My big argument is that we overuse a lot of the big libraries that are most popular today, and we use them for applications for which they're not the best choice. Brian: What's your hypothesis for why? Chris: Yeah. I think there's a few things going on here. Just generally as an industry, I see a few things. I see this move in cycles. One of them is, I think there's a little bit of a, like, "If it's good enough for Facebook or Twitter, it's good enough for me," kind of thing. Like, "Well, Facebook uses React, so it must... Look at all the amazing things they built. So it must be great for me too." Chris: Facebook has a whole suite of engineering problems that maybe don't necessarily apply to the thing that you're building. The other, I think, piece here is there's a little bit of marketing going on. People who build new things go out to conferences, and podcasts and talk about them. And then, if they get enough hype, our industry seems to be... Especially front-end engineers, get really, really fickle and love to jump to the new exciting thing. Chris: I speak as a front-end engineer myself. We love to learn new things and play around with cool new shiny toys and stuff. And so, I've noticed with things like Angular, and Vue, and React, there's been this thing now where you get a bunch of developers excited about these tools, And then, companies are like, "Oh, if we want to hire the best engineers, we need to use the tools that they're really excited to work with." So you start seeing job descriptions looking for these tools. Chris: And then companies are like, "Oh, my competitor over there is using this tool. We need to make sure that we're using it too, so that we can compete for developers." And then, before you know it, a whole industry is using a small set of tools because of this hype cycle. It's not that React and Vue and Angular are bad. They're very, very good at the things they were specifically built to do, state-based UI in a very complex DOM-heavy environment. Chris: But most of what we build is not nearly as complex as these tools require. If you look at a lot of the HTML that gets spit out in something like Facebook or React... Sorry, Facebook or Twitter, there's a reason why a virtual DOM-heavy library probably gives them better performance and makes it easier to work with. They have bunch of different engineering teams working on a subset of products that all get cobbled into one UI. A lot of the things that we build don't require that. Chris: Then the other angle here too is I know a lot of agencies use these tools, and I think the thing that happens there is if you're going to take the time to invest in training your staff on a particular tool set, and you build a bunch of tooling around that, things you maybe use on a lot of projects you work on for clients, it makes sense to keep using that over and over again because you're incentivized to build things as quickly as possible for your clients and you want to get a good ROI on this tooling that you've built. Chris: Yeah, so I think there's a whole bunch of issues that happen here. I mean, I could, sorry, ramble on and on about this, but I think there's also a bit of a false narrative around the developer experience, which is not to say the developer experience isn't important. It really, really is. But I hear this perspective all the time, that these tools make it easier for developers to build things. And because that is true, we can focus on building all these great features for our clients and our customers or users, and that experience that we get gets passed on to the users. Chris: I would argue that the developer experience isn't actually better for at least a not insignificant subset of people who work on the front end, and that it rarely gets passed along to the users as a net win for them. In fact, I think, often the opposite is true. I can come up with some very specific counter arguments for when it actually has made the user experience better. I can argue with myself here on this one if you'd like me to. Brian: No, no, you're not alone. I mean, I feel like that happens. Hey, I definitely have said before, it's what keeps me personally in business. It's those kinds of... There's actually no real answer for this, but if you present these two sides and... Yeah. In doing prep for this episode, I started thinking about the big three frameworks or the big four, because we left out Svelte, which maybe we shouldn't. I was like, "Maybe we should..." Brian: I'm sure someone else has already thought about this, like vanilla JavaScript as the fifth. Maybe that's more appealing if you don't necessarily want to use... I don't really know the best way to put it, a library that comes from a large tech company with baggage. That's pretty- Chris: That's a very diplomatic way to phrase that. Brian: How about that? So yeah. I mean, that seems like a plus to me, if you've... No, I'm going to get so much... Well, I probably will. I mean, how could you not? Boy, I mean- Chris: Yeah. No, I actually didn't bring ups Svelte for a very specific reason, because I see Svelte, and new kid on the block, Astro, and static site generators, I see them as a different category. For me, they're actually one of the things I'm most excited about for what's coming next. They're in my mind kind of a... They're a good leap forward, I think, is a right way to describe it. Not perfect, but I think potentially a good leap forward. And we can talk about that if you'd like. Brian: I would very much like to. Let's pull in that [crosstalk 00:30:10]- Chris: Okay. Yeah. The thing that, just at a super high level, the one or two liner on this, is I think the problem with a lot of the modern client side libraries that we use is, not only are they big, there are a lot of JavaScript that gets sent to the user, and that has a bunch of performance implications just because of how JavaScript is downloaded, compiled, and parsed compared to, say, CSS or HTML or image files. Chris: But JavaScript is also really, really fragile. It's way more prone to breaking than HTML and CSS are. If the browser doesn't understand something in your HTML or CSS, it just ignores it and moves on. But with JavaScript, it's like, "No. This whole file's garbage. Just toss it out. We're done here." And so, there's this new set of tools that I'm really excited to start seeing more of. I put them in maybe two categories. Chris: The first is micro libraries. I'm starting to see more front-end tools that mimic the approaches of bigger tools like Vue or React, but do it with a much smaller footprint, maybe shed a few of the features that are nice-to-haves, or like, "Hey, Facebook needs that, most people don't." They end up with something that's both smaller and faster. I think the shining example here is probably Preact, which is one-tenth the size of React, uses the same API, including React hooks. Chris: It's literally like three kilobytes, which is absolutely amazing, after minifying in [inaudible 00:31:53]. Not only is it a smaller package, but because it has fewer abstractions baked into it, it actually not just renders faster, but responds to data changes that's reactivity engine is faster as well by quite a bit. It's about four times faster than React in terms of implementing UI updates when state change. I can, if you want, an article on that for the show notes. I have some research that was done, some data I can share with you to link to. Chris: That's one bucket. You've got Preact. Evan You, the guy who built Vue, recently released something called Petite Vue, which is a small subset of Vue that's really intended for more of the progressive enhancement type stuff that is a very common use case for Vue and doesn't require the full 30 kilobyte package. He was inspired by another project called Alpine that mimicked Vue's approach, but in a smaller library, a little bit closer to the middle. Chris: Micro libraries, they're really cool, but they still have some of the problems, in my mind, that these older libraries do, which is that they're shipping a bunch of abstractions and they're effectively putting the rendering and runtime in the browser for stuff that, in a more classical architecture, used to happen on the server, back in the day when everything was like PHP driven or like .net. Chris: I think the other category that I find even more exciting, I just broadly refer to them as pre compilers, and it covers a wide suite of things. On one hand, you've got stuff like Svelte, which is really, really neat. For those of you who don't know, Svelte allows you to create views the same way you might in something akin to React or Vue. It's a little bit different, but you've got the same basic concept where you've got a component, and some state, and you specify some things that happen when the state changes. Chris: And then, instead of that being the thing you ship, you compile these .Svelte files into the thing that actually ships. What Svelte does is it takes all that code and it spits out mostly HTML, mostly pre-rendered, with a little bit of, honestly, old school DOM manipulation style vanilla JavaScript, the kind that you might hand code if you were still doing things that way. Chris: And so, it gives you the authoring experience of working with a library, but gives the user something that's going to be a lot more resilient and way more performant. They're currently working on a new tool called Svelte kit that adds routing and add some really interesting progressive enhancement features. So that's really neat. Then there's new kid on the block... I always forget if it's called Astro or Atomic. Please give me a minute. Chris: I want to say it's called Atomic. There are two of them. Astro. Okay. It is Astro, is the one I'm thinking of. Here we go, and I apologize. It literally just came out, as far as I know, a couple of weeks ago. Astro's really neat. It takes the concept that Svelte had and takes it to the next level. It says, "Hey, so what if instead of having to use our own syntax here, you could use anything you want?" With Astro, you could take a card component from Vue and a tab component from React and some Svelte file you started working on and mash them all together in one project and compile it into mostly HTML with a little bit of JavaScript. Chris: It's going to strip out all of the libraries that you put in there and output the things that they're actually doing into close to browser native JavaScript. If you're a team that really enjoys that authoring experience, let's say you're already all in on React, you can still use React and give your users a more resilient and performant experience by layering Astro on top. Jason Lengstorf from Netlify played around with this just a couple of weeks ago. Chris: He took this Next.js site that he had, ported it over to Astro, used 90% of the same component code and ended up spitting out something that had 90% less client side JavaScript and a page load time that was 30% faster than it was before. So really just big wins all around with almost no additional work or overhead. So tools like that. And then, on the other end of the spectrum, there's still technically pre compilers, but the authoring experience is very different, static site generators. Chris: You've got things like Hugo, Jekyll. I used to call them new kid on the block, Eleventy, but Eleventy's been around for a while now and they're doing great things. They just hit version one, which is awesome. Yeah, those are really, really powerful too. I think, for me, the thing that I'm most excited about is tools that allow developers to work in a flexible way that fits their needs, but doesn't make the end user of the thing that they've built pay for that convenience. Chris: That's always been my problem with a lot of these bigger libraries, is I'm getting a benefit, allegedly, as a developer and I'm passing that cost onto my user. Brian: Literally pay or trade off? Chris: Figuratively pay. Brian: Got it. Chris: ... in the sense of slower load times, potential crashes on older devices and lower bandwidth situations. Yeah, not in the monetary sense, but in the user experience kind of sense. I gain something as a developer, it costs you something as the person who uses what I built. Brian: Yeah. What I was fishing for maybe it was there are literal costs- Chris: No, you're right. Brian: ... if you mess up. You're going to have to pay for a lot of different things. Chris: You saying it made me think about, for a lot of people who are on limited bandwidth data plans and things like that, there is a literal cost for shipping all this, all this JavaScript. Not even getting to if you want to get really heady about it, you could make I think a really valid argument about the environmental cost of just shipping that much code, like storing it, sending it down the wire, the amount of electricity devices you use to process and run it. Yeah. It just turtles all the way down. Brian: People do that all the time. Chris: Yeah. Brian: It's terrible. I know. People do that all the time with crypto and in my opinion, justifiably so. So yeah. No, I'm not going down a crypto rabbit hole, believe me. I'm not there yet. Chris: If you really want to get angry emails, though, Brian, we could. Brian: No, I don't. Believe me, which I really don't. One thing I was thinking is we started by saying like, "Hey, maybe should we consider Svelte big four?" And you said, "I consider that part of a new wave." Do I have that right? And then, so we talked about what that new wave was, the pre compilers, and then smaller libraries. To me, all of that still sounds pretty complex. Chris: Yes. There's another... I think it's a longer term play. One of the things I've noticed is... And I am by no means... Actually, probably I didn't even notice this. I probably had someone point it out to me and now I can't unsee it. And I've got a little bit of a, like, "I built this," kind of thing going on. But the industry moves in circles, and what often happens, because the standards process is necessarily slow, you have a bunch of stuff. People want to do that the platform doesn't support yet, but that could be bolted on through tooling. Chris: And so, people build a bunch of tools to make the things that they want to do work in a reasonable way in the browser. And then, eventually, sometime down the road, the browser catches up. Then there's a really slow petering off of the tooling as more people realize they don't need it anymore. The most recent example of this... I shouldn't say most recent, but I think the shiniest example of this is jQuery. If you're not old and gray in the beard like I am, you may not remember the web before jQuery and how absolutely abysmal it was to try and write JavaScript for that web, where Internet Explorer and Firefox and Netscape, they all did think things their own way and didn't care what the other one was doing. Chris: And so, you'd have code that was littered with a bunch of if/else kind of statements. If the browser supports this method, use it. If not, use this other one. You couldn't get an element in the UI by class, unless you got all of the elements by a specific tag name and then looped through all of them to check if they had a class on them using some complicated Redjacks thing. It was a pain. Chris: And then jQuery came around and was like, "Hey, we've abstracted all that stuff away for you. Use these methods instead. They're really well-documented, by the way. Now you can write it once, it'll work everywhere." That was just a revelation. And then, years later, we got ES5, which took many of these conventions from jQuery and baked them right into the platform. So we got querySelector and queryselectorAll that let you find elements in the UI by any CSS selector. Chris: We got the class list APIs. You could add and remove stuff really easily. We got better methods for looping over a raise and making changes to them. It just got really, really good. And so, I see what's happening now, with all of this tooling, as another... I don't know if you'd call this the crest or the trough, I guess it really depends on how you look at it in terms of the wave of development. We're either at the high or the low. But- Brian: No, I understand. Chris: What I'm envisioning is that more and more of the stuff that libraries do is going to get absorbed into the platform as time goes on. It's a very slow process and the things they're doing are way more complicated than what jQuery was doing back in the day. So I think it will be a slower process to figure out what that really looks like. But what most of these tools do, in my perspective, is pave cow paths, show the way things could be. Chris: It allows developers to, in the wild, experiment with some ideas and then be like, "This works, this doesn't. This is a better way." And then, hopefully the best stuff floats to the top and gets pulled into the platform. I would love, for example, to see some sort of native DOM diffing. That's really at the heart of what a lot of these libraries do with like, "Here's how the UI looks. Here's how it should look, make them the same with as little effort as possible." Chris: I would love some sort of browser native way to do that, maybe with HTML strings because template literals are awesome and it would be really cool to get a JSX-like experience right in the browser. One of the things that's in the works that a lot of libraries do is sanitizing HTML strings so that you don't accidentally cross-site scripting attack your users with like malicious third-party code. Chris: A lot of libraries have a mechanism baked in to remove dangerous stuff out of the HTML before actually rendering it. There is a browser API in the works right now to do that. At present, if you're not using a library, you have to use something like DOMPurify to handle that for you, or use some really, really onerous manual creation of elements to avoid the danger there. Those are the two big ones. I did the classic Chris Ferdinandi, lost my train of thought halfway through. So, Brian, I'll shut up and if you have anything you want to respond to, I'm happy to... Brian: No. Actually, it's why I ask those big questions. It happens all the time, or I go like, "There's no right answer. Go for it." All right. We have reached the point of the show where guests plug things. Is there anything that you think people should go, or maybe other people you think don't get enough attention? That's kind of the part of the... I like to wrap it up this way. Yeah. Chris: Yeah, that's really nice. I really like that. Yeah. Great question. Yeah, two things. First, if you found anything that we talked about on the show interesting, or if you just disagreed with me and want to shout at me on the internet, head over to gomakethings.com/podrocket. I'm going to have a bunch of resources related to stuff that we talked about, links to any of the things I mentioned, as well as a whole bunch of other stuff if you want to dig deeper in here. Chris: You can also find my contact information. So if you want to shout at me on Twitter about how wrong I was, you can do that as well. Yeah, that. And then, for people I don't feel that get enough attention. I actually really like that question. I've never had anyone mention that before. I would love to direct people to Stephanie Eckles over at moderncss.dev. She also has another really awesome super useful tool called SmolCSS at smolcss.dev. Chris: Much like I spend a lot of time talking about how much JavaScript has evolved over the years and how much you can do just with the browser gives you out of the box, Stephanie does the same thing for CSS. I love CSS, but I'm not super great at it. And so, I find myself going to Stephanie's sites to copy paste stuff from her cheat sheets all the time. Just an amazing resource for all things modern CSS related. So if you haven't heard of her yet and you want to learn more about how to write awesome CSS, I would recommend giving her stuff a look. Brian: Very cool. We'll put all that stuff in our show notes as well. If- Chris: Fantastic. Brian: ... you're in the car or outside for some reason. That was a joke, just didn't work. Chris, a pleasure having you on. Chris: Brian, thanks so much for having me. This was great. I really appreciate it. Brian: Cool. See you. Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter, or you could always email me, even though that's not a popular option. It's brian@logrocket.