Paul: Hi there, and welcome to PodRocket, a podcast brought to you by LogRocket. LogRocket combines session replay, error tracking, and product analytics to help software teams solve user-reported issues, find those issues faster, and improve conversion and adoption. Get a free trial at logrocket.com today. I'm your host, Paul, and we have an exceptional guest joining us. Someone who's been making waves in the web development community by advocating for, I mean, we'd love to hear a simpler, and more resilient approach to building things for the web. It feels like the holy grail of the day and age. Please give a warm welcome to Chris Ferdinandi. Chris Ferdinandi : Wow, Paul, if I ever have the money for the hype man to just follow me around and talk about how awesome I am, I want it to be you. That was one of the nicest podcast intros I've ever gotten. Thank you so much. Paul: I went over with Chris at the beginning. I want to make sure our listeners know who we're talking to today, we're talking about grandiose things about the state of web development, our attitude towards the industry. Chris, we could say you're an expert in vanilla JavaScript. You've dedicated a large portion of your career to helping others learn and master through courses, eBooks, workshops, videos, whatever it might be. So, we're going to get into some of these topics today and I'm really pumped for that. Chris Ferdinandi : Awesome. Yeah, I'm really excited to be here. Thanks. Paul: I think the poster child sentence of this podcast is like the bloated web or the transitional web. I'm flip-flopping between the transitional web and the bloated web, but I like the bloated web, because I think it hits that nail about what is the problem of the day and age. I'd love to know from you, is it the transitional web or the bloated web and why do you say the bloated web, Chris? Chris Ferdinandi : Yeah. I think for a while now we've been in the bloated web. This is something I've been talking about for a few years. Maybe four years ago or so, five, I gave this talk called The Lean Web, where I was talking about where we are today, where we've been in this period of time, where if a little bit of JavaScript is good, a lot is even better. We've been doing all these things in the browser with lots and lots of JavaScript that we used to rely on the server for. In doing so, we've created this really fragile house of cards where JavaScript is incredibly easy to break. Like most browsers, if there's an error with your HTML or CSS, they just ignore it and move on. But because JavaScript is a scripting language, if something goes wrong, they just stop running it. When your entire UI is rendered with JavaScript, that's really bad. JavaScript is also a lot more expensive for browsers to parse and render. It involves an extra step and it's just a lot more computationally expensive. So, a byte of JavaScript is substantially worse for performance than a byte of JPEG or HTML or CSS might be. So, we found ourself in this situation where we're throwing the worst part of the stack at the browser in increasingly large amounts. Even though internet speeds have gotten phenomenally faster over the last decade, websites are not actually meaningfully faster. They can do cool stuff, but we're building them in a way that is slower, more prone to breaking, just generally less resilient and worse. A lot of times we're recreating stuff that we could just use the browser for or do on the server in a much more reliable and performant way. When I talk about the transitional web, for a while, I was very doom and gloom about the current state of things. I actually see the pendulum finally starting to swing in the other direction. I don't think we're a hundred percent there yet, but I think we're at the beginning of the next big shift in how we build things for the web. So, I've been referring to that as the transitional web. Sometimes I talk about the rise and the fall of JavaScript frameworks, not that they've fallen yet, but I see their use in the front-end starting to diminish over the next few years. Paul: I think your call-out about having bugs crop up or maintainability is a good call-out, because this conversation about we can't ship too much JavaScript is like everybody's talking about that these days. That is the common point of view to be in. It's, okay, we want to ship less JavaScript. We know we shouldn't just dump JavaScript on the client, so we have this solution and that solution, we're going to get into some of them like Astro is one ship no JavaScript by default. But I think your call-out about developer experience and bug-solving and maintainability really steps into play here, because the future of the web could be using actually less things. Maybe it's not tacking on yet another thing onto the meta of the meta of the meta-framework, and that's one thing I really like about your course, for example, is it brings us back to the basics. It's like maybe you could use CSS as just CSS. Chris Ferdinandi : One of the things we don't talk about enough is developers who've been doing it for a while, myself included, like a certain amount of tooling, because it can make repetitive tasks easier. But that same tooling or too much of it can make things a lot harder for people who are trying to learn, who trying to get into the industry. Junior developers and, a lot of times, even people who are involved in the process of making a web thing, but are not actively front-end developers or JavaScript developers, you'll have CSS specialists or folks who do accessibility audits, who, when you throw overly complex tooling at them, it gets in the way of them being able to do the thing they're really good at. One of the things that I talk about is we've seen or we're starting to see this emergence of tools that shift a lot of the rendering from the browser back to the server, but they do it using modern approaches and tools. You've got things like Svelte or Astro, which allow you to do state-based UI and that diffing approach to rendering the UI, but what they spit out is not the entirety of React or Vue, but just a little bit of JavaScript that does... They'll compile what you've written into just the minimal amount of JavaScript that you need to do those. The thing that always makes me a little bit leery about those tools, and I think they're great, they're much better, real big shift in the right direction, but it is still using a very tooling-heavy process and it's still a lot of work for someone who's newish to this space to have to manage and deal with. It's another set of things to break. I'm a big fan of using just enough tooling and no more. I feel like, for a lot of folks in our industry, the right amount of tooling is as much as possible. Yeah, the thing is, I don't know if it's like people really enjoy that or it feels like what you're supposed to do if you're, quote, "a real developer." So, everybody just goes along with it. And there's a huge amount of pressure from conference talks and, just call them, thought leaders, I guess, on Twitter, or whatever, to constantly chase after tooling. If we wanted to get really controversial, we could dive into TypeScript and whether or not that's actually worth all the overhead, throwing a tool in there. I think tools can be useful, but too many of them makes what you build harder to maintain in the long run. I used to run into this really ridiculous situation where if I didn't touch a website for five months and then I went to go update something, I'd have to spend the first hour and a half trying to update my gulp build and figure out how to actually get all of my stuff to compile, which was really stupid and annoying to have to do, and I just wanted to change a couple of lines of CSS. Paul: I think the TypeScript comment makes me think about this on a more abstract layer, which is what am I using the tools for? I think we say web development is this big umbrella term of web development, and what's the best for web development? But it's like, who are you as a developer and what's your end goal here? Because there might be a lot of scenarios where you're using a Jamstack deployment, using Jamstack, you're using prefab APIs and you're not as concerned about data validity. Maybe TypeScript, you don't have to jump through those hoops. Maybe we have to reframe the question about what level web developer are you, one, two, three or four? I don't know. Not every tool is for everything. Chris Ferdinandi : Yeah, I think there was this trend for a while where every website that people were building, they were grabbing a state-based UI library. It was usually React, sometimes a Vue, maybe one of the other newer ones like Preact or Solid or something like that. But it was one of those just because that's what you do. And I don't know if there was this mindset of like, "Well, if it's good enough for Twitter and Facebook, it must be good enough for me." But conversation I always like to have is about tool appropriateness, and not just for you as the developer, but for the project. So, if the tool actually adds specific benefit to a project, go ahead and use it, but if it doesn't, it might not really be worth the time and effort to do it. I think TypeScript is a really good example. I've never personally had an issue with types breaking my code, passing in variables that had the wrong type, or the fact that JavaScript is not a strictly typed language. I could imagine a situation where on teams of a certain size, with a range of developers at different points in their career, that could potentially be an issue. I've even seen certain industry leaders who are like, "TypeScript won, we should use it for everything." It's like, "Should we, though?" Because it's a lot of work to set up, a lot of times you spend time fighting TypeScript to just get it to validate when the code you've written is perfectly valid and will run fine. To me, it might not always be worth the effort. I think that's true of most of the tools that we use. State-based UI libraries provide an incredible benefit for certain types of user interfaces and add a lot of overhead and create a lot of potential break points in many, many others. But we have a tendency today to just use them for everything. So, for me, that's what it's really about, being a little bit more thoughtful about the tools that we choose to use and when and why we choose to use them. Paul: I'd love to talk about state-based UI libraries such as React and Vue. We'll get into that in a sec. But if you are a React developer, you are a Vue developer, use frameworks and stuff, and you're trying to debug your code, I'll take a quick pause here in our episode just to remind our viewers that the podcast is brought to you by LogRocket and LogRocket can help you understand exactly how your users are interacting with your digital products and on your React site throughout your components. So, it provides session replay, error tracking, product analytics, and other cool AI features such as frustration indicators and analytics and algorithms to surface the most impactful issues affecting your users. So you can spend more time building great product rather than hunting through tools or other frameworks or integrations like we're talking about here. You want to solve your user reported issues that your users bring up, actually find them before they bring them up and improve conversion and adoption. So, you could do that with LogRocket today. I want to turn us back to React. Thinking about React in particular, do you think that React as a state-based UI library has a permanent king's throne, a lion's share of our... I mean, it does now, but for the transitional web, we're talking about the next 10 years. Do you think it has that lion's share? Because tools like Astro come out and they say, "We have all these components, we have Astro pages and layouts, but wait, you can put React in it." Me, as a developer, my first reaction is, "Oh, whoa, I don't have to learn anything new. I'm just going to go use React." Chris Ferdinandi : Your first reaction, Paul? Paul: Yeah, my first reaction, my first state change is no state change. I just do what I've been doing. We use Astro and then we stick in React. Do you think that this is... Are we going to continue down this path? Are people going to be lazy like me and we're just going to keep sticking everything in a state library, like React, and wrap some meta-framework and say, "Oh, you're shipping less"? Chris Ferdinandi : So, there's a couple of threads we could pull at. One of them is, for a while, before React ever existed, jQuery was the hot thing to use to build for the web, and it still has a much more dominant share of the market than React does, even though jQuery isn't like the cool new thing to build with and it's not what I think most people reach for as their first tool when they go to make things. But what's definitely going to happen, because React definitely won the UI library war, is there is a ton of websites that were built with React that are going to have to be maintained for quite a while, and it's way more expensive to rip out a library on an existing site that's running it than it is to just keep using it. If you have a site that's running fine with React and you need to make some tweaks, it almost always makes more business sense to just keep React in there, than rip it out and try to rebuild it with something else. Paul: For the business, in the context of the team. Chris Ferdinandi : For the business, yeah, not necessarily for the user. If you're thinking about companies and how they're investing their developer effort. I think one thing you probably will see, and you mentioned this already, Paul, is Astro is a compiler that allows you to use React, Vue, Svelte, a bunch of other stuff, and you can even mix and match them and use them together. So, I think at least as a transitional period, we will probably see more developers reaching for a tool like that and just making a few tweaks to their existing setup to do more server rendering using the build that they already have. From that regard, yeah. I think what comes next for the web will not be client-side state-based DOM diffing, but I don't think React is going to just disappear from the web anytime soon, much in the same way that jQuery has not disappeared from the web and probably won't anytime soon. There are sites built today that are going to be around for a long time and they're going to continue to run on React, whether that's in the browser or through some kind of server based, or OS based, compiled ahead of time, and distributed as HTML with a little [inaudible 00:14:35], I think React has staying power. I think the other side of this though, the thing I don't know is state-based UI was a really big paradigm shift, and the web seems to have one of those every 10 years or so. I feel really strongly that at some point in the next four to five years there will be a big rethinking on how we build UIs and I don't think it'll be state-based UI, I'm not smart enough to know what it's going to be. I don't think it'll be more of what we're already doing. Paul: You're just here to tell us there's going to be a thing, guys. Chris Ferdinandi : I'm just looking back at historical trends and I know something will likely change, but just the tech industry moves too fast. Technology evolves too quickly. I started doing web development back when the idea of responsive web design and having a site that could work on your desktop and your phone was this really novel concept and now it's just taken for granted, that's just what everybody does. Paul: A site on a phone. Chris Ferdinandi : Yeah. It's a long-winded rant, but what I'm trying to get at is that React, I don't think React is going away, but I also don't necessarily think it'll be like the first tool people reach for in three to five years time. It will be something else. I'm also not entirely sure that these server-based compilers are going to be it either. When we shifted away from jQuery, there was this period of time where the browser natively could do a lot of stuff that jQuery used to be able to do, like getting a bunch of elements by a class instead of an ID, used to be really, really hard, so jQuery added all these layers of abstraction to do it. And then we got query selector, and query selector all... Suddenly, this was way easy to do just in the browser. But there were certain stuff that was still a little bit more difficult. People built a bunch of these transitional tools that bridged that gap. So, you had Umbrella JS was one of the big ones, which still around on the web, you can find the website for it if you do a Google search, Shoestring JS from the folks at Filament Group up here in the Northeast, and nobody uses those today, but they were really popular for a year or two as people were like, "We don't need jQuery anymore," but the native web still isn't enough. There's a part of me that wonders if tools like Svelte and Astro are the next React or the next Umbrella JS. Are they just bridging the gap to whatever comes next or are they the thing that becomes what's next? I'm not sure and I'm not sure I would, at this point, bet money either way, but if you forced me, I suspect that they might be transitional tools that pave the way for whatever comes next and not the next big thing. Paul: I think that also steps into... At a fundamental level, in our context of conversation, I agree with you and I think it also comes back to how are you using this tool? Because if you're using Astro to bandaid your React, it's totally a transitional tool, that's how you're using it, but if you're using it to re-architect the way you fetch, load data, that's a different domain you're stepping into. Chris Ferdinandi : That's fair. The other piece here too is maybe we talk about something like SvelteKit, which allows you to... Let's say, you're not just... Okay, I'm going to move my React to something pre-compiled, so I'm shipping less code, which is a huge win just in and of itself, like you might do with Astro. And you're going into like, okay, I'm going to write my pages in a way that feels very comfortable to me, and what I'm going to ship to the user is almost entirely HTML and CSS with a sprinkling of JavaScript when needed. Oh, by the way, if that fails, it'll make an old school server call and work anyways. That's huge. You could very much convince me that approach has staying power. I think that's part of the problem is like Svelte came out, people were excited, and then Astro came out and people were like, "Oh, I can keep using React and just better?" Yeah, I think that's for me, I've gotten a little hung up on the fact that I see a lot of folks using Astro as a use the same approaches, but more servery, and there is potential to just do things a lot differently with these tools, too. Paul: I think you're starting to highlight, yeah, what are some things I might bet on being in... I bet depend on React versus, right now, for example, we're talking about page transition. I remember when Angular came out with that, that was one of the poster child things about Angular. I can transition in my SPA between pages and now we're talking about putting that straight into the browser. What other things do you think are going to follow suit? Chris Ferdinandi : There's a couple of them. One of the ones that's in the works right now, I think it's in a stage two or three proposal, but there's an API to do HTML string sanitization, and I think that would be a huge win. One of the challenges with third-party data with vanilla JavaScript right now is that if someone has some sort of malicious cross-site scripting attack in the data you get back, you can do a lot of bad things to a UI. Most state-based UI libraries include some sort of sanitization process that strips out stuff that's not on some sort of allow list. It's the reason why React, for example, has the SetInnerHTMLdangerously property instead of just innerHTML, and Vue has their own process for what's allowed and what's not. There's going to be a native web API for that that will make things a lot easier. One thing that I would love to see in the browser is some sort of DOM diffing function that makes setting HTML in the UI as easy as using something like innerHTML, but without destructively rendering every single thing on the page. I'd love to be able to say, "Here's an HTML string, here's an existing element. Make everything in there look like this with as little destruction as possible." Effectively doing what React and Vue do in the browser. Because I think a lot of what people use these tools for is not full on single-page applications. There's a lot of just progressively enhanced, like I have a filter component, or something like that, and you really don't need a whole library for that. But it can be difficult, it's much easier to do with state-based UI than old school DOM manipulation. So, having a native way to do that would be great. The other thing that would be kind of neat is, one of the things that single... So, single-page applications are, I'm going to say something a little controversial, they're terrible for the web. Most of the ones that get implemented are done with accessibility issues, because you're breaking so many things that the browser just does for you, and then re-implementing them with JavaScript, usually, badly. The one thing where SPAs really shine though is with media continuity. For example, on YouTube, I can play a video and then navigate around and open other pages and pull up descriptions for other videos, and the video I was watching continues to play down on the corner. Same thing with Spotify WebView, I can listen to music and jump around to a bunch of different songs and tracks and artists, and that media continues to play, or like SoundCloud, same thing. You really need an SPA to do that today. It would be really cool if, in addition to, say, the Element Transitions API, which allows you to get those cool page transition effects, there was a way to keep certain media persistent while making a full HTTP request and getting a page back and hot swapping what's in there with what you just got back. I guess, not all that dissimilar to what, say, the folks at Basecamp or 37Signals did with their Hotwire, HTML over the wire thing, but natively. I guess, effectively, I'm still talking about DOM diffing, you're also including the head and all the stuff up there. But yeah, I think that would be really interesting. Then, this gets a little more difficult to answer, because what invariably ends up happening is stuff that we use libraries for today, the best stuff ends up getting absorbed into the platform eventually, the best parts of jQuery got pulled into the web. As soon as that happens, a bunch of new libraries come out that tackle a whole new set of problems that we didn't even know we had. Is that going to be like AI integration? Is it going to be VR? Is it going to be something else? It's really difficult to predict what that's going to be. But I almost see this as a never-ending cycle. We'll get there with the native web and then there'll be a whole new set of tools bringing a whole new set of features that push things forward. Paul: What's important for a new web dev? Somebody coming into the space for the next three years of their career, for example. I think before we even think about the new frameworks and what would a company want? Who do they want hire? And they want to hire and use tools that have a good knowledge base, a good set of support. When it comes to these new AI tools, for example, I mean, in my own testing, there's no other framework they know better than React, and there's a reason for that. It's because there's so much React. AIs are pros in React and it's like, that's an undeniable truth that we're going to have to grapple with as this becomes the de facto technology to spit out components. Chris Ferdinandi : Just the what-do-people-need-to-know thing. One of the things I've really benefited from, because I've focused on just the web platform and a lot of those foundational technologies, is I'm less concerned with which new libraries are popular and in vogue at the moment, because it's a lot easier to transition and pick those up when you understand more of the fundamentals of how they work. Like React is infinitely easier to learn when you understand JavaScript basics than if you don't. But I'm also pragmatic. If you're someone who's just graduating and you're looking for your first web developer job, it's really hard for me to say don't learn React. Because React is what most of the job description's looking for. It's probably the easiest way for you to find work is learn React. Yeah, I think you're right. I think at least in the near term a tool like React, or to a lesser extent Vue, there are still some companies that use that too, are probably good bets. But I do think learning or, if you have the time, digging into a compiled tool like Svelte or Astro, or I'll take a look at Qwik, will potentially put you a little bit ahead for what's going to happen in the next few years. I remember when I was first getting into this and I was really digging into responsive web design, because it was like this brand new thing, and I knew more about it than a lot of the more senior devs, because they just dismissed it as this fad, or weren't really aware of it. It really benefited me early in my career once it finally clicked, I knew a lot more about it than some of my peers did, and that was really helpful. Yeah, my general advice to folks now is if you desperately needed a job today, learn React. If you want to potentially set yourself up for a bit more success over the next couple of years, maybe dig into Astro or Svelte or something like it. Paul: Chris, thank you for your time coming on and picking apart this very vague topic. This podcast ended up indeed just being a brain dump and us talking about the state of things, the future of things. Then I think you're just an interesting person to talk to because you have a slightly different corner of the room that you're yelling from, where you're like, "Hey, basics, people, fundamentals." If you're into that, like we mentioned at the beginning, Chris, he has a course, what's the name of the course one more time? Chris Ferdinandi : I have a handful of things. The easiest way to find that and all things me is if you got to gomakethings.com/podrocket, you can find my daily newsletter, some courses, workshops, a bunch of free stuff, and a ton of links related to all the things that we talked about today. Paul: Chris, are you on Twitter or Medium, if people wanted to follow on your musings? Chris Ferdinandi : Yeah, I'm on Twitter @ChrisFerdinandi, my last name is a nightmare, it's got like a bajillion vowels in it. So, go to gomakethings.com. I have links to all that stuff. My email address, if you want to tell me how stupid and wrong I am, Twitter, if you want to yell at me, and my YouTube channel, if you want to heckle me in the comments. Paul: YouTube, there it is. Well, gomakethings.com, easy to remember. Appreciate it, Chris. Chris Ferdinandi : Awesome. Thanks for having me. It was really great chatting.