Software Huddle - Becoming an Epic Web Developer with Kent C Dodds

Episode Date: April 9, 2024

Today, we have Kent C Dodds on the show. If you don't know Kent, he's a well known expert in JavaScript, Web Development and Teaching. His courses like Testing JavaScript, Epic React, and Epic Web Dev have helped countless developers uplevel their skills and develop whole new ones. During our conversation, we discussed how he got to start in creating courses in the background on his latest project, Epic Web Dev. We also picked his brain about JavaScript. Why the heck do we have so many JavaScript frameworks? Are we just perpetually dissatisfied with what we have? Or is there a fundamental problem with how the web is actually designed? There's a lot of meat in the bone on this one, and we hope you enjoy it. Show Notes: The Web’s Next Transition https://www.epicweb.dev/the-webs-next-transition Epic Web Conference 2024 CONFERENCE DAY April 11th, 2024 WORKSHOP DAY April 10th, 2024 https://www.epicweb.dev/conf Timestamps 01:46 Kent’s Background 05:38 Epic Web Dev 15:07 Creating an engaging course 19:07 How long does it take to finish the course 23:01 JavaScript and CS 25:47 Things that you should know 29:09 JS frameworks 36:28 Re-building the Web from Scratch? 42:59 PESPA Architecture 53:04 Rapid Fire

Do you think we need to teach web development in a different way than we might teach classical computer science? We need to teach things differently, at least differently than I learned it, because I almost didn't become a programmer because it was so bad. I do not think that I use any of my knowledge of that on a regular basis at all. So I do have some knowledge of DSAs, but I don't really feel myself reaching to that knowledge very often at all. I guess like, what are those core principles for web development? Like, what are those things that you should know? Wherever you are in software development, I think it's a good idea to understand the level that you operate at and one or two layers below.

If you could invest in one company, who would it be? Hey folks, welcome back to Software Huddle. And we got a great guest today because Kent C. Dodds is here. If you don't know Kent, he's a well-known expert in JavaScript, web development and teaching. His courses like testing JavaScript, Epic React, and Epic Web Dev have helped countless developers up over their skills and develop whole new ones. During our conversation, we discussed how he got a start in creating courses in the background on his latest project, Epic Web Dev. I also picked his brain about JavaScript. Why the heck do we have so many JavaScript frameworks?

Are we just perpetually dissatisfied with what we have? Or is there a fundamental problem with how the web is actually designed? There's a lot of meat in the bone on this one, and I hope you enjoy it. And of course, if you do, let Alex and I know by contacting us on social or leaving a positive rating review. All right, let's get you over the interview with Kent C. Dodds. Kent, welcome to Software Huddle. Hey, thank you so much for having me. Yeah, thanks so much for being here. So you're, you know, in many ways, in some circles, a pretty well-known guy, I think, especially in the world of JavaScript, web development.

I'm kind of interested, like, what is your background on how you became involved in, like, creating courses and a content creator and building up an audience in a space as you turned it into a business, moving away from maybe the day-to-day sort of software engineering you've done in the past? That's interesting. So I pretty much was doing both jobs for a long time. I have always been teaching and sharing the knowledge that I have with co-workers or meetups and conferences and even giving workshops. Even while I was working, actually, it was just a couple months after graduating with a degree in information systems that I started working on courses. And on egghead.io was where I first started publishing. And then I started traveling around for conferences and stuff.

So it's always been kind of a part of what I've done. Just something I really enjoy is teaching. And so the transition from doing that as a part-time thing to doing that as a full-time thing really was a natural step for me because in the years that I was working as an individual contributor or team lead at various companies, I one day decided, hey, I've got a lot of information about testing and lots of workshops that I could put together. I was going to make a bunch of courses on Egghead. And they reached out and said, hey, how about instead of just doing a bunch of courses on Egghead, we do a special site just for you, just for your stuff.

And I said, that sounds interesting. So we created testingjavascript.com. And that went super well. And I made more than my PayPal salary just from that. And so I was like, well, I don't need two PayPal salaries. I'm doing just fine. And I would prefer to get my evenings back. And so, yeah, so I decided to go full time as an educator from that.

And so, yeah, it was kind of a natural step. Like there wasn't really a lot of risk involved because I had been doing it for like six years already. And I knew that it was working and it could only work better if I had more time to do it. Yeah. And you have a skill set that's highly marketable. So even if it did fail, you could probably go and get another job as a software engineer. Yeah, exactly. Certainly, like back then, that was 2019, I think. Yeah, the beginning of 2019 is when I left PayPal. And yeah, back then it was just like, well, what's the worst that can happen? I go get a job. These days, I think that's a little

less certain, or at least it's a little more difficult. I do think that the economy is coming back and everything, but there's still big tech layoffs and whatnot. But that actually is part of the reason why or something that I realized as I built a following online, that having a following online and presenting this perception or making sure that people had this perception of me being a really skilled engineer was a big part of job security and making it so that if I did ever need to get a job that people would know who I am and know that I'm good at this stuff and that they want to work with me. So yeah, there was a lot less risk certainly back then, but even today I feel like if this education thing wasn't working out, I could go and get a job because the perception people have. Absolutely. So you are the creator of Epic React and a number of other courses. And you have a sort of newer, I think, ambitious project around Epic Web Dev. Can you tell me a little bit about what inspired this project?

How is it different than maybe Epic React and what problem you're trying to address and what's the current state yeah sure so um testing javascript as i mentioned was um kind of like a bunch of egghead courses and those um egghead courses are typically just watch me do this thing and you will and take notes and then go apply it to your own project. And while that works really well, what I found was that I was always doing like, I would have a egghead version of my material, and then I have a workshop version of my material. And I found that the workshop version, it helps people's retention a lot better than just like watch me do it and then do it yourself later. And so I actually put together a workshop for testing node applications that I added to testing JavaScript a year after its initial release. And, and that was like, basically, I recorded myself as if I was giving a workshop to whoever's watching. And so they were expected to be at the keyboard

and going through the exercises and stuff. And that went really well. And so with Epic React, I decided to do the whole thing like that. And so that came out in 2020 and it went really quite well. And I, yeah, I just bought into this idea of doing things as self paced workshops that you can go at your own pace. And with my videos, kind of going along the way, helping you through

all the material. So I'll introduce the problem, then you go and try and solve it. And then you come back and watch me solve it. That is kind of the flow there. So Epic React was just enormous. There are lots of resources around React, but there's nothing quite like Epic React at all in the world that will let you work in your own editor, on your own machine machine running through these exercises that have been handcrafted by me having delivered this material so many times. So what happened after that? Like I said, I am long winded, but I will get to your question. So you're asking what about Epic Web? Like where did that come in? So after I finished with Epic React, actually taking a step back, one of the things that I was concerned about going full-time teacher is that I would lose touch with what it's

like to build applications. I'm just always teaching and making little demos. Like, yeah, that works in a little demo, but like I live in the real world, Kent, and this is totally different. And so after I launched Epic React, around the following year, Ryan and Michael, well, actually, it was that year, Ryan and Michael Jackson, Ryan Florence and Michael Jackson were working on Remix. And I was very interested in what they were doing. And so when they launched Remix under developer preview license, I got a license and started working with that. And I decided, okay, I'm going to build my website, but I'm not going to do like what people typically do with the developer portfolio with like three

pages and, and like four blog posts. At the time, I actually already had many, many blog posts. But I want to do I want to go way above and beyond because this is how I gain experience and what it's like and staying up to date with what it's like to build full applications. So I had a couple of requirements for myself. One, it needed to be globally distributed, not just the application code, but also the database so that it could be as fast as possible. And that just that right there adds an enormous amount of complexity to the application that I thought made it feel a lot more like what I was building at PayPal. And so that that was one big requirement. Another was that it needed to be server rendered and dynamic for every user. Every page should be different. So I can't use any CDN caching.

It's not a static site. It's got to be fully dynamic. And then those were probably the biggest things that I had as requirements. I also wanted features that my existing site already had, like integration with my podcast. I have a Chats with Kent podcast that I publish on my website.

So I wanted to have that integration there. And yeah, a couple other little things. But I started working on that and I worked with a team as well. So, you know, to make sure that like, I can still work with teams. And so I hired people to do design and illustration and even to implement some of the designs and that sort of thing. And I was just kind of in charge of making sure the whole project got done. And I

worked on the vast majority of it myself. So as I was going through it, and I decided to use Remix, I found out like how capable Remix was and that I could build so much more than I ever expected. So in addition to all the things that I mentioned, I also decided, OK, we can actually do user accounts and we can give personalized blog post recommendations like content recommendations to people based on things that they've already read and things that they haven't read yet. And things that are popular, so I can keep track of the blog posts that are being read and surface those. And then actually, let's make this a fun thing. So when you sign up for an account, you choose a team. And then your team, like the blog posts that you read will count to points towards your team. And so then like, it turns into like a Pokemon Go gym type of thing. So like, if you have more people owning or having read this blog post more recently than, uh, your team is the owner of that blog post and the whole thing changes to your team's color and stuff. And then, um, I

was like, how about we do a call in podcast where people can like write in the browser, record themselves asking a question and, um, and I'll record my response. And so like now it's a full-on podcasting app that I've built. And so all of these different things that I could put together because the technology that I was working with was so good. So in the process of doing that and launching that, I said, okay, this is actually, this is my next thing. I want to teach people how I did this. And that was really intense. The entire time was like, I need to think of what I want people to learn next.

I want to teach people, really, for a long time, I've always wanted a kcd.edu. Like everything that I know about everything, I'm going to teach people. But to be able to do that, I have to really know my stuff. And so I'm going to build something really ambitious. And so that's what happened with the website. I decided to take a brief break on the teaching thing, though, because Remix needed somebody to come and help build the community and work on the documentation and examples and education and stuff. And so I actually joined Remix as a co-founder for about eight months. And I ran the conference, I got meetups going, I got the Discord in a really good state and a bunch

of other things there, helped with documentation and examples and stuff like that. And so once I felt like Remix was in a good place, then I said, okay, now I can go back and teach people how I built KentCDOTS.com. And so that is where Epic Web, at least volume one, that's where that has come from. it's effectively, if I were building an ambitious large-scale application today, this is how I would do it. And there's a lot more to say about all this, but I've been talking for too long already.

But I'll just mention that what distinguishes Epic Web from Epic React is that, first of all, the learner environment, the workshop application that you use when you're going through the exercises is much improved because I built it with Remix instead of Create React app. And then the and of course, like all of my past experience and how what makes a really good workshop app. And so that is one aspect that's different. And then, of course, Epic Web is about full-stack application development, whereas Epic React is scoped down to just the React side of things.

And it is focused on the single-page app era of development, whereas Epic Web is about full-stack apps. And so, yeah, that is the long answer to your simple question that was great i appreciate the detail and all the background and context but you know one of the things you you talked uh well some time ago about it was this idea of making like the course like more of a workshop more interactive and that was like an improvement

in terms of people's like learning cycle and one of the things that I always recommend to people when, you know, people are interested in getting into engineering or they come with to me and they're like, you know, how do I learn like a new programming language or something like that? I'm like, choose a project, like, you know, choose like a reasonably like simple project that you're interested in and just like start building because you're going to learn so much more by the act of building than, you know, just reading about it or something like that. So I think that's really, really great. But one of the things I'm curious about is as you're putting together these courses and you're having people go and sort of self-direct to try to solve a problem, how do you balance like essentially

what is difficult enough so that they're learning, but it's still attainable for them to actually achieve that thing? That is a great question. Some of that comes down to the assumptions you can make about their prerequisites. So they need to have a certain amount of knowledge about like some foundational knowledge for the material. So depending on what I'm teaching, like if we're going into, I'm going to teach you how to do full stack web authentication, then I have to assume that you know how to like create a form and how to store data in a database and that sort of thing. So there's definitely some level of prerequisite knowledge that I will expect. And I always list on the workshops that say, this is what I expect you to know before you work on this workshop. But yeah, aside from that, once you're with those

prerequisites, taking a complicated problem and breaking it up into multiple steps helps a lot with not overwhelming people and making sure that it's scoped really nicely. And then another thing that I do that's kind of unique to my workshops is I actually have the like the workshop app that you're or the the playground that you're working in that has all of the code that you're going to be editing and things has little code comments with emoji that like draw your attention. Cody the koala is like my main character in that. And so the Cody koala emoji shows up and says, okay, this is where you're gonna do this.

And you're supposed to follow the emoji and do what they say. And sometimes it can feel, or people will look at that and say like that, you're just like holding my hand. I'm not actually learning anything You're just telling me exactly what to do But I've had like tens and tens of thousands maybe hundreds of thousands of people who've gone through my workshops with this format and They really like it. I haven't it

Really whether they like it or not, it actually is irrelevant. It has results. They remember the stuff that they're learning and they're applying it in their work. So I am, to help avoid people getting super lost and confused and frustrated, I am pretty handholdy in that way. And then another thing that I do is with the a new workshop app i have a tab that you can open up if you get stuck and you say what is like i something i am doing is different from what i see him doing in the video what did i miss and so it's a diff tab where you can actually look and it generates a git diff based on what you currently have in your playground versus what

the solution looks like and so if you really stuck, you can just go and look at that. And then, yeah, breaking it down to smaller bits and then iterating on that helps a great deal. And that actually, by doing that over the course of many workshops, like we do with the volume one of Epic Web, we can like start together from square one. And so by the time we get to the end of it, we may have a lot of code that's all like very domain specific and you got to have pretty good understanding. But you built the whole thing. So like by this time, you know all of that stuff. And so it does help to sometimes I'll have examples that are just like, okay, now for this example, we're going to learn these things. And now for this example,

we're going to learn these things are totally different things. And sometimes that's kind of necessary. But if you can build on the same thing over the course of all the different workshop exercises, then that helps a lot to avoid people having to context switch into totally different examples. How long does it take, you know, if someone's kind of working diligently at it to get through the entire course? Okay. So there have been some people who had very aggressive schedules. And like, I'm talking like maybe 20 hours a week or more, um, of, of dedicated time in the workshop who finished in three months.

Um, and so like that, that is way more than I would expect anybody to dedicate. And in fact, it might be too much, um, because like your brain just needs time for this stuff to settle. And, uh, on top of the workshop exercises you're doing, it's important for you to, as you said earlier, build something yourself. And so what I suggest that people do is they spend about six hours a week at most working through the workshop material. And then they spend another six or 10 hours working on some other project. That could be something for work, but it's best to do something that's related to what you learn so that your brain is forced to recall the information and that will help with the retention. And so there have been some people who work through the workshop exercises and then they go and build their own version of the app.

It's even like and it's fine if it's even the same thing. But yeah, it could maybe change up a couple features and whatever, make something a little different. That will really solidify that knowledge for you. But yeah, I see Epic Web Volume 1 as almost a university degree in the amount of content that you have in there. Yeah, I think that's really good advice around like sort of overloading yourself. I found when

I was in university and I kind of like really loaded up courses, like I was so much in like do mode that I didn't really have time to kind of marinate on stuff. So I didn't retain it as well. And I didn't really have time to kind of like bring my stuff. So I didn't retain it as well. And I didn't really have time to kind of like bring my own thoughts to it because I was just basically in execution mode the entire time. So I think that's a really sage advice in terms of if you want to sort of maximize the value of the courses, basically slow down a little bit and focus on quality and give your time some time to think about what you're actually doing in terms of like the target audience. Like who is the typical sort of persona of a person that's going and taking this course? Are these

people who are like, I don't know anything and, but I'm looking to get into, you know, land my first sort of job in tech or are these experienced professionals that maybe want to add another, you know, thing to their toolkit? Yeah. So the, the target audience I want to get is people who are on the job. They're like their boss paid for it for them. They, the whole team got it together and they're going through it together that, and, and they're building like a full stack app or they want to. And that's the audience that I want to get. And I, sell team seats and stuff occasionally. But most of the people who are taking it are single developers, they're maybe consultants, or they're doing this on the side. Some people are just curious about what it's like to build full stack apps. I've had a manager or two who will get it just to stay sharp on the technical side of things. And so it is the target audience or the audience that I attract is typically experienced developers or relatively experienced developers. It's pretty beginner friendly, but it does expect that you know JavaScript and HTML and CSS. It's pretty beginner friendly,

but it does expect that, you know, JavaScript and HTML and CSS, it's not going to teach you that stuff. And, and even TypeScript as well. But yeah, so relatively experienced developers who want to upgrade their knowledge

around building full stack applications. Okay. What are your thoughts on like the foundations of web development versus learning a framework? And are the foundations of web development perhaps different than the foundations of classical computer science education where you're learning data structures, algorithms, principles of programming, language design? Do you think we need to teach web development in a different way than we might teach classical computer science? That's a great question. I definitely think yes to the last question you asked. We need to teach things differently, at least differently than I learned it, because I almost didn't become a programmer because it was so bad. We were learning about linked lists, data structures and things, and I was like, it just felt so disconnected from anything in the real world that I lost interest very quickly. And so it was only when I discovered information systems and we were trying to apply technology to business that it became interesting to me.

And so I got lucky that I discovered that, oh, okay, programming can be practical. So yes, I think we do need to teach programming in general differently than at least I learned at university. But I don't think that there's anything wrong with data structures and algorithms. I think a lot of people really get a lot out of that. And there are certain applications where that makes a lot of sense. I think for the vast majority of web developers, an understanding and data structures and algorithms is not going to hurt. But I do not think that I use any of my knowledge of that on a regular basis at all. So I do have some knowledge of DSAs, but I don't really feel myself reaching to that knowledge very often at all.

So I don't. And for that reason, I don't teach any data structures algorithms in Epic Web, not directly anyway. And the web is a little different from other platforms. But to be perfectly honest, I don't use other platforms. I I'm fully 100% on the web. And so it's hard for me to, to compare and contrast those. Um, I do think that, um, the web is, um, one of the best ways for a developer to or for an individual to become a software developer and get a gainfully employed situation um and and they don't have to be like a rock star at math which is great because i'm not yeah so i guess like it's not that there's not value in knowing data structures and algorithms but maybe they're not as directly applicable to web development.

But I guess, like, what are those core principles for web development? Like, what are those things that you should know? You know, if you're building databases from scratch, you probably need to know as principles of that data structures and algorithms and stuff. But if you're building web applications from scratch, like, what are those core principles that I should know? Oh, that's a good question. So typically, wherever you are in software development, I think it's a good idea to understand the level that you operate at and one or two layers below. What I say is like you go down to level up. So if you really want like we're all learning at the layer that we're operating at. So I'm a web developer. So I know divs and spans, and I know, you know, class selectors, and I like all of these

different tools that web developers understand. But then if you want to level up your understanding, then you can go a level down in the abstraction and say, okay, now I understand how the DOM works. And I know how this CSSOM works as well. And I understand how JavaScript is being executed and how the just-in-time compiler works and stuff like that. So yeah, the core principles, I think that really just understanding the technologies of the web,

it's a little less principle-based, I guess. But the foundations of the web are important. HTTP, definitely an important thing for a web developer to understand. And like, you know, cache headers and all of that stuff, like request response sort of things. On Epic Web, it's called Epic Web

instead of Epic Remix because while I do use Remix to teach the web, I also like use various otherix to teach the web, I also use various other tools to teach the web. And it's no more a Remix course than it is a TypeScript course or a database course, whatever. So what I do try to do in Epic Web is teach the foundations of the web platform. And so when we're talking about authentication, I'm not teaching authentication with Remix, I'm teaching authentication on the web. And here's how you use cookies and all these things. And now Remix is going to be the tool we use. But I want people to understand the underlying principles of how things like that work on the

web. Yeah, it makes sense. I like this kind of framework that you used of like, if I'm working at, you know, this kind of certain level of abstraction, then going one to two levels beneath it allow me to understand that probably at a deeper level. But do I need to go 10 levels below that is probably not necessary. Yeah, and that comes through in my teaching by me. Typically, I will have somebody build the abstraction before we use the abstraction.

And so when I'm teaching React testing library, we're going to build our own version of testing library before we start using it. And that just helps a lot with people's comprehension and effectiveness at using the tools. Like in Epic React, the very first lesson, we don't even use React at all. We make DOM nodes with the DOM API and we insert those into the document. And then when we do bring in React, we don't start with JSX either. We're using the writing by hand,

the compiled version of React, so that people understand how JSX works. So yeah, that comes through in my teaching as well, because I do think that's an important principle. So I want to talk a little bit about JavaScript frameworks. We've had so many frameworks over the years, and it seems like there's a new one all the time. And I vividly remember the first time I encountered jQuery and then Backbone back in the day. And those were like giant leaps forward from just writing vanilla JavaScript.

And of course, now we have much more powerful frameworks at our disposal. But what are your thoughts on why the, I don't know if it's the web ecosystem or maybe the JavaScript ecosystem, like we're perpetually kind of unhappy with the frameworks that are available and keep creating new ones? Yeah. So, you know, the JavaScript ecosystem is unique because it's where everybody else converges. No matter what you're building, our users expect a user experience that requires JavaScript in the browser. They are done with full page refreshes. They're done with not having their cursor focus managed properly. Like everybody, no matter how you're building on the web, you're going to have to write

JavaScript at some point, or you're going to use something that compiles to JavaScript. And so for that reason, we've got vastly different ecosystems and different minds of how we build software, all participating in the discussion on how do we build, you know, the JavaScript side of things. And so because of that, I think those sensibilities are reflected in the tools and frameworks that are developed for the web. And so, yeah, we just have different thoughts around how to do that. And I don't think that it's necessarily a bad thing. Like, we don't have to have one winner of all the things. It's just what speaks most to your own sensibilities for building for the web. Yeah.

And it seems like there's sort of different schools of thought in terms of like where things should happen. You know, there was a time like in the early days of web development, basically like all the heavy lifting was like server side. And then your front end was, you know, pretty, pretty bare bones. And then eventually we shifted to like doing a lot of heavy lifting on the front end. And then there's probably some happy medium in there as well. You know, I guess like from your experience, what do you think is the right balance?

That's a great question. So this kind of gets into the framework architecture or web architecture that I've dubbed the PESPA. So we have the MPA, that's the multi-page app, which it wasn't called that back then because it was the only way to do it. So like it was building websites. But that's just where every interaction is a navigation. Like you click a link, you go somewhere, you submit a form, you go somewhere and it's a full page refresh, all of that. And that became problematic because users don't want full page refreshes when they're liking a post or whatever. And so we added a progressively enhanced version of that where JavaScript on the page would take over.

And when you add a comment on GitHub instead of a full page refresh, it just shows up right there. But there were big challenges with that because now you're duplicating your templates between your Ruby backend that's generating HTML and your JavaScript client that's generating DOM nodes that should resemble the exact same HTML. So if the user refreshes, the comment looks exactly the same. And so for that reason and various others, we decided, well, this is really challenging.

How about we just throw away all of the template stuff on the backend, and now our backend is just a REST API, and we can have the frontend client side stuff just do fetch requests, and it can be in charge of all UI-related stuff. And that actually feels like a really clean separation, right? Like JavaScript is in charge of UI, and Ruby is in charge of our API. And you know, what's wrong with that? Well, there's a lot of things wrong with that. Like it definitely solves some significant problems with developer experience, which does feed into user experience as well. Like if your developer experience is so bad that you have to keep on updating, you know, two copies of the code or whatever, your users are going to experience bugs.

Things are going to look different. It's going to be a pain for them. So it did sort of improve some areas of user experience as a result of the developer experience improvements there. But yeah, at the same time, there were a lot of other problems because now you're not server, because you're not server rendering, your users are getting, you know, a bunch of loading spinners all over the place. And, and there's just, uh, the performance is going to be worse. Lots of, lots of things are a problem there. And so, um, but, uh, yeah, single page apps kind of took over for a long time. There was the jam stack that got really popular for a while and static apps. And so, and like all of these solutions

to the problem that was invented by this architecture. So like, you know, incremental static regeneration, this whole entire really complicated solution, ISR that was built to solve the problems that wouldn't exist if we just stayed with server-side rendering stuff. And so in my mind, the pinnacle of user experience and developer experience is the progressively enhanced

single-page app. So it's like taking all of the good things of both a multi-page app and a single-page app and putting it together, where instead of having two copies of the same code, you've got two copies of the same code, you've got, or like, you know, two copies of the same template, one in Ruby and one in JavaScript spaghetti. You've just got one source of truth for your templates and that's your React components. And those run both on the client and on the server. And now we don't have to have that code duplication,

but we also can have all of the dynamic stuff that our users have come to expect from the single page apps. And we can render it on the server and pick it up on the client. And then even in the near future, I think the PESPA architecture evolves into what is being worked on the React team

with React server components. And now some of those components can actually stay on the server. They don't need to go over to the client. But we still maintain that primary benefit that it's still progressively enhanced. It's server rendered. The forms still work.

The links still work. Even if the JavaScript isn't finished loading yet, and the transitions between pages are really fluid, no full page refreshes and focus management is really nicely handled for us, all of that stuff, because we have JavaScript in the browser. So it's like a mix of the MPAs and SPAs that I think is the pinnacle of architecture on the web.

Yeah, and I definitely want to talk more about what you sort of term as PESPA in your really great article, The Web's Next Transition, which I'll link in the show notes, and I encourage anybody listening to definitely read it. It's really fascinating and a great sort of history of

all the different ways of essentially web applications over the last 20 years or so. But one of the things I wanted to touch on before we get there was through this history, we're kind of trying to balance this trade-off between creating a better user experience, but also not punishing our developers with duplication of code

and coding in one language and context switching to another language between the front end and the back end is there because we keep kind of like having to like hack these systems together to to get something better like are there is like the raw materials of how we build web applications just like broken like it should we do we need to basically revisit the like fundamental like http and how some of this stuff works like is that sort of paradigm maybe the the problem and we keep trying to like tool our way into something that works but the kind of raw materials are broken that is a very good question um there are definitely a lot of people who would say who would say yes absolutely um and I would say um

there are plenty of things on the web that should not be the way that they are, um, but are that way because of backward compatibility requirements and things. Uh, the web is just really unique in that way. Um, like you can say, uh, to iPhone users, sorry, your iPhone is like six years old. We cannot support with new OS updates or anything. Uh, and as the operating system updates, and as we get rid of old phones and stuff, we can have completely like breaking changes to that platform. And we can't do that on the web

because there's no central authority saying whether or not, sorry, your website is 10 years old and it just, it can't work anymore. Like I'm glad that we are in that state. That nobody, there's no central authority saying whether or not I can have an old website that still works. And so we do have unique constraints on the web that I think if we were to just like throw it away and build it from scratch, I hope we wouldn't lose those constraints because I think those are important for democratizing what the web is.

And so I don't think that there's a really great, reasonable way for us to say that, like, yeah, if we did throw it all away and build something completely from scratch that didn't have those limitations, but we maintain those constraints, we'd have the same problem in 20 years. We just like, who knows what the future of the web will look like, even if we rebuilt it from scratch today. And so, yeah, like there are some platform issues, like certainly with the UI elements that you can use. And there's a bunch of component libraries that I wish didn't have to exist, but do for accessibility reasons and things. So, and then, yeah, even with HTTP, there are some improvements that could be had there. And like some things are evolving. The challenge is though,

that like one of the things that's unique about the web and why it's sometimes the platforms move at a pace that's a little slower than a lot would like is because that the people on those committees, I've been on the TC39 committee, I know what this is like. Every decision that we make is set in stone forever. And so we have to be very careful about the advancements that are there. And then at the same time, we have to make sure that it doesn't conflict

with anything of the past. So yes, there are definitely holes in the web, but those holes exist for a good reason. And that is the importance of backward compatibility. Yeah, I mean, I think you raise a really, really interesting and valid point is just that the web works in a way that's like different than almost any other type of like application you're building for

because of this, you basically need to adhere to like the legacy. Like a web application built in 1995 still should be able to render on someone's browser the way it did. Hopefully it's a little faster now because you're not connecting with a 56K bottom or something. But fundamentally, the building blocks

still should be able to do that, should be able to render that. But you couldn't run a modern application on Windows 95 today. So it's a completely different paradigm. And there's both, you know, pros and cons to kind of adhering to that historic history there. And it would be difficult to kind of just decide that we're going to dismantle the system

and start something brand new. And that might also not necessarily get you to what you are hoping to achieve anyway. So we kind of have to work within the constraints of the system that we put in place. Yeah, yeah, exactly. And it's actually been tried at least once, and I'm sure many other times. And in fact, it may still be an effort, an ongoing effort. But Douglas Crockford, famous for JavaScript, the good parts and stuff, and also not being a very nice person online

but uh he uh um he when he was at paypal he was trying to reinvent the web um with you know various things uh uh ideas of different technologies that he thought were better and uh doesn't have the legacy and all that it does does not work. It just it doesn't. And actually, Google tried to reinvent the scripting language with Dart. And that language is still relevant. They have their Flutter thing. I don't really know any much about that. I did write a Dart program once. But yeah, certainly, I can't claim any knowledge around that, really. But that also failed. Because the other thing is, because there's no central authority, you have to get a group of people, of different companies, to agree on everything that happens. And so Google says, hey, we're going to do this Dart thing.

And Apple and Mozilla are like, well, have fun with that, I guess. And, and so now, you know, works on Chrome is slapped on any site that wants to do dart, and you're not going to convince any business person that like, their users can only use Chrome, that just is not going to be a thing. So. So yeah, there, there are a lot of unique and interesting constraints on the web and it has been tried to reinvent stuff and it just has failed. So I, um, even if we wanted to, uh, and even if we could, I think we'd end up in the same situation where we're like, oh man, we got all this legacy stuff. Yeah, yeah, exactly. Um, so I want to go back to the, the, the, the PESPA architecture.

And can you, like, can we walk through a specific example and kind of break down, you know, what is the toolkit that I would be using? And like, where does different, you know, things basically happen front end, back end for us? Let's say I'm doing like, I'm creating an account, you know, I have an account creation page. I'm going to submit a form that's going to get saved, that information somewhere that I did, you know, I have an account creation page, I'm going to submit a form that's going to get saved that information somewhere that, you know, database or something like that,

you know, essentially where does the different parts of that code live and how's that interaction in the Pespa architecture, maybe in comparison to like one of the, you know, prior architectures. Yeah, yeah, sure. So in an MPA architecture, everything's on the server, like the generating the HTML, all of that, everything is going to be on the server. Like generating the HTML, all of that, everything is going to be on the server. The only thing that runs on the client is what the browser vendors wrote to run in the client when you've got these HTML elements.

In a progressively enhanced multi-page app architecture, I call that the PEMPA. I don't think anybody's ever called that a PEMPA, but that's what I'm calling it. But in that architecture, you'll have like sprinklings of JavaScript on the client to make the experience better. So when the user submits things, maybe it does a full page refresh, or maybe it's going to do some validation on the client before you submit to say, hey, that username has already been taken or whatever.

And maybe you'll have some localized loading spinners and stuff. You hit sign in and it does a little spinner. So that's progressively enhanced. So it still works even if you don't have JavaScript, but if you do, then we can make it better. And in the spa architecture, so you're going to have rest endpoints that actually do validation and stuff. You always want to have validation on the backend for sure,

no matter what architecture you have. But yeah, this is going to be a lot more stuff happening on the client where validation happens on the client. Like you will do some client side validation just for a better user experience. But again, all validation finally does happen on the server. But yeah, you'll be making fetch requests. You'll prevent default on your form so it doesn't do a full page refresh. And you just do like a fetch request with JSON and stuff. Certainly does not work without JavaScript at all. In fact, for a lot of apps,

it won't even show you the login form or the account creation form if you don't have JavaScript on the client, which is to say like everybody's got JavaScript on the client. Almost, almost everybody supports running JavaScript. There are edge cases where it may fail to load or somebody turns it off for some reason, but like that, that is such an edge case. So it's not so much about like that it matters that it doesn't work without JavaScript. It's more about how quickly does it show up for the user and will it work without JavaScript

while we're waiting for the JavaScript to download. That's what we're talking about here. So anyway, in the spot architecture, we move a lot of our business logic over to the client about like, what are we going to render and when? And then the server just becomes APIs. In the PESPA architecture, if we're moving from SPA to PESPA,

we move tons of our stuff back to the server. And so handling that form submission, there's going to be just the tiniest little bit of JavaScript that says, okay, don't do a full page refresh. And then I'm going to submit this form as if it had been submitted by the browser. And then our server-side code doesn't know or care whether it was submitted by the browser itself

or submitted by JavaScript. It's going to look the same as far as the server code is concerned. And so all the business logic will be on the server. Deciding what to render is going to be shared between the client and the server. And so the router is going to work on both sides. And then like what data to load that's going to be hooked into some sort of router of some kind.

And lots of that can live on the server. And with React server components in particular, we can actually move even more of that logic over to the server, which ultimately is going to help a lot with the performance of your application, not just in the initial load time, but also as you're making changes to things and things are re-rendering,

that should speed that up as well. Is the main advantage of moving from like the spa to the PESPA like a performance gain? Especially like if you're on like a, let's say you're on a, you know, like a lower end mobile device, then we're having to download the JavaScript and render everything client side is going to really be like device dependent. And you only have so much control as an engineer to be able to optimize that experience for your user. That's a big part of it. Another big part is the developer experience as well.

So it's both the user experience and developer experience improvement. Because the fact is that the developer experience of a multi-page app is really simple because HTTP is stateless. And so you don't really think about managing state when every single time a user performs some sort of action, like clicking on a link or submitting a form, they're getting a brand new version of your app that has got the latest of everything that was just generated by your server. You've got a little bit of state in there regarding like cookies and stuff. But for the most part, it's all just like request response, easy peasy.

And so this is actually one of the reasons why a lot of developers who've been around for a while lament the way that things work now because it's so much harder than it used to be. But the and the reason that it's harder is because now with single page apps, you're loading up all of this data into the client. And then as the user is making changes, you have to both change it in the client and you have to change it on the server. And so because what you effectively have is a cache. And so now you're just inviting one of the hardest problems in computer programming in the software industry is cache invalidation. And so you're just bringing that into your entire application.

Now your entire app is a cache. And so that makes things really complicated. And so if you can embrace the fact that what you have on the nice developer experience of a multi-page app with the nice user experience of a single page app. And so that's the idea behind that. Now, you can actually get some of that nice developer experience improvement on a single page app architecture by modeling things properly with and saying, yes, this data is a cache and I'm going to do the same thing the browser would have done, which is anytime the user submits a form, all the data is invalid and I'll just go revalidate it all.

And that actually is a pretty winning solution to this particular problem. And Remix has built SPA mode in part because there are some applications that cannot get away from the spa architecture. They're an embedded iframe on somebody's website. They need to be a spa for that reason. And so, like for various other reasons there. And so, yeah, you can get lots of the developer experience improvements there. But moving things back over to the server, to get back to your question. Yes, that primarily is a performance improvement. Yeah, one of the things that really kind of like annoyed me as I started to build with like a smaller architecture was the fact that like suddenly had to start like managing history and state and all this sort of stuff that like you just kind of took for granted was done for you.

I was like, well, you you know why is this so difficult you know we had this problem solved and now we've like like reintroduced this problem all of a sudden and of course there's certain advantages that you got but like it was like like felt more difficult than what you could do previously so in terms of like that's what is this something that you're seeing like is this basically the from your opinion and also from what you're seeing in the industry, like how like modern applications are, are, are going to be developed now? Or is this kind of more like the future where you think things are going? This is the way that I've been developing for the last three, three or four years now with Remix. For me, I'm unaware of any other framework that was capable of doing what Remix does.

And so I give, at the time that Remix was released, and so I give Remix the crown of introducing the PESPA architecture, even if they don't like saying that. Because in Remix, you can actually mix and match different architectures in the same application. And there are use cases for doing that.

But I pretty much just, my entire app is a Pespa with the way that I build it. And yeah, so I've been doing this for a long time. And it's a trend that I've seen in the industry that whether you're using Remix, most application or frameworks are moving to this architecture, even outside of the JavaScript ecosystem. So within

JavaScript, you've got Svelte, you've got Next.js, and there are various others, SolidStart, QuickStart, all these frameworks are consolidating on this PESPA architecture. Even if they don't call it that, that's effectively what it is

because it's a really good architecture. And then outside of the JavaScript ecosystem, you have Phoenix and you've got LiveView and even Rails is trying to do stuff that follows this architecture. They're limited because they are so dedicated to not writing JavaScript that you have to have

some layer between you and the JavaScript. But they are trying to do something similar to this architecture. And so, yeah, it is definitely the present for many developers and it's the future for pretty much most of us.

As we start to wrap up, I want to go with some It's the present for many developers, and it's the future for pretty much most of us. Okay. I mean, as we start to wrap up, I want to go with some quickfire questions here. So don't think too hard about these. Just go with your gut. So if you could master one skill that you don't have right now, what would it be? Slowing down. What wastes the most time in your day? Email.

If you could invest in one company, who would it be? Tesla. What tool of technology can you not live without? My air filter. Which person influenced you the most in your career? My wife. That's a good answer. What's your probability that AI equals doom for the human race?

My probability? I'd say zero. All right. Well, that's great, Kent. Thank you so much. Anything else you'd like to share? How people can reach out to you or follow you online? Yeah, so I have many places.

So kentcdots.com is my personal website. That's where you can go and ask me a question on the call Kent podcast. Uh, I also have office hours. I just finished that before recording this, uh, join me for my office hours, uh, each week. Um, I'm on X at Kent cdots. And, um, I also on epic epicweb.dev, I'm actually just barely scheduled a bunch of React workshops. So anybody who wants to learn React can go through this masterclass of seven workshops over five weeks, 10 days worth of workshops. It's going to be pretty intense. It'll be awesome. And then in April, we're doing Epic WebConf, which will be awesome. Is that your own conference? Yes.

Yeah. So it's an evolution of RemixConf now that RemixConf isn't happening anymore. So I've just taken that and made it my own. So yeah, you definitely know some of the speakers there. And you'll love to get to know the other speakers that will be there. So it's in Utah. And it's a really awesome time of year to be in Utah. And then what's your... Do you have any speaking gigs coming up? Yes, I do. I have a map of all the places I'm going to be. If you go to kcd.im slash map,

that will show you all the places I'm scheduled to be and when I'm going to be there. I'm going to be in Miami, Poland, New York. Yeah. various other, here in Utah, of course. And so, yeah, that's a good way to keep up with where I'm going to be. Fantastic. Well, thanks so much, Kent, for being here. And hopefully you can join us again down the road. Well, thank you, Sean. I appreciate the time. Cheers.