Noel:
Hello and welcome to PodRocket. My name is no Noel and joining us today is Kent C. Dodds. Kent is a JavaScript engineer and a teacher. He's also active in the open source community and the father of four kids. Thanks for joining us, Kent. How's it going?

Kent C. Dodds:
It's going pretty good. How are you doing?

Noel:
I'm good. I'm good. It's Monday morning, so getting in the flow but doing our thing. So can you give us a quick intro about yourself, who you are, your background, where you came from and what you're working on now?

Kent C. Dodds:
Yeah, sure. So I can be a long winded person, so feel free to stop me if I'm going too long. So I live in Utah with my wife and four children and one dog. And I graduated with a master's degree in Information Systems from Brigham Young University in 2014. And I've been developing software ever since. Worked at a couple of companies. The longest was PayPal for three years and then I'd been doing a lot of teaching on the side and I built testingjavascript.com and that ended up working out really well. And so I decided to go teaching full-time for almost like two and a half years. And then I actually joined up with Remix to help build the community and developer experience for that web framework. And then about a month and a half ago or so, I decided to go back to full-time teacher and work on what I'm working on now, which is epicweb.dev.

Noel:
Nice. Perfect. That was a great overview. I don't feel like that was long winded at all. I feel like you totally nailed that. Cool. Okay, well go through chronologically here. Tell me about what drew you to Remix and how that was initially? Because initially Remix was like licensed, wasn't it? I'm a little bit shaky on the history, but...

Kent C. Dodds:
Yeah. Yeah, sure. Yeah. So when I decided to go full-time teacher, my first year I updated testingjavascript.com, second year I created epicreact.dev. And then third year, around the time while I was creating Epic React, my friend Ryan... That was 2020. So the world was on fire and everything and Ryan Florence and Michael Jackson had their React training business, which was primarily in-person trainings. And so that did not go well with COVID and they had to pivot. And to make a long story short, they decided to build software and sell it, which it seems like a no brainer, but a lot of people had a problem with that I guess. So they built a framework and sold licenses and I bought a license during the developer preview and it actually never came out a developer preview because they decided to open source it a year later.
But while it was in developer preview and actually even before that, I was consulting with Ryan, especially on some of the things that he was working on and ideas that he had and giving feedback. And so by the time it came out as a beta, I was super into the goals of what they were trying to accomplish and how they were doing it relative to other frameworks that it used Next and Gatsby. And so my site at the time was built with Gatsby and I decided to rebuild it using Remix. That was flying an airplane while rebuilding it in the air because a lot of things weren't supported yet. And there are a lot of things that my website does now that I'm only doing it that way because a better way didn't exist yet. And so a lot of, actually, several features in Remix are a direct result of issues I had when I was building my site. But I endured that because I could see that the foundation that Remix was built on was really solid and it proved really well.
So now, I'm extremely productive building with Remix and the things that I build are fast by default and the mental model is really simple. And so yeah, I took a bit of a gamble to go with something that was being built while in flight, but that has really paid off and I enjoyed it so much that all I wanted to do was teach people how to use Remix. And so Ryan and Michael were like, "Hey, how about you just do that at our company? We got funding and stuff. So come join us." And so that's what I did for about 10 or 11 months.

Noel:
You talked about the foundations being really strong there in remix. Can you go a little bit more into that? What were you seeing that really drew you to it?

Kent C. Dodds:
Yeah, I'd love to. So one thing from the start that they really wanted to emphasize was a exposure of the platform. So a lot of frameworks and libraries that I've worked on, you typically take the platform APIs, you can't avoid the platform APIs. At some point something's talking to the platform, but most of the time I would look at that and be like, that API is not the sort of thing that I want to work with directly, so I'm going to wrap it and provide a better API that's more tuned for my particular use case. And it wasn't until Testing Library, I created that just about the time I was toward the end of my time at PayPal. And that was when I was like, you know what? It actually is really nice to be able to just expose platform APIs.
And that worked out really well. Now Testing Library is the most widely used library for DOM testing in the world. And so exposing platform APIs seems to be a really good idea. So you do provide abstractions, but your inputs and outputs to those abstractions are all platform APIs. So with Testing Library, it was all DOM stuff. And so I saw that Remix, their focus was exposing platform APIs as well. So instead of building their own request response API, they use the web fetch API for request and response. And then that perforates through everything, URLSearchParams, and all of the things. Form data, everything that's built into the platform is an important part of Remix.
And even beyond that, for the mutation story of Remix, you use forms rather than an onclick handler or form prevent default or any of that stuff. And hitting an API route with JSON. It's just, here's how you do mutations on the web. We'll just basically do that same thing or at least emulate that behavior and provide with us with the better user experience that we're looking for. And so that's what I mean when I say a really solid foundation because the foundation is the web platform itself.

Noel:
Yeah, nice. That makes a lot of sense. And then when you transition into working, or I guess maybe teaching it full time, how did that go? How did that feel? Was there anything unexpected or was it all positive energy for the most part?

Kent C. Dodds:
Yeah. Yeah, it was... So there are some drawbacks to teaching something that's totally new. I say that there are drawbacks, but you have no resources. Nobody else can teach you how to do stuff so that you can learn how to... and so you just have to spend a silly amount of time playing with it yourself. And maybe one piece of advice that you come up with that you're like, "I think this would be a good idea," turns out to not be as great an idea or the best approach, or it's still unproven when you're working with something so early. And typically when I'm working with something that has been out for a while, I'm typically spending a ton of time working with it anyway.
I don't like to teach something that I haven't used and deployed and everything, which is why you'll probably not see anything from me about rest or anything like that. Because I'm 100% type script JavaScript person. But with something that is just totally brand new, it is a little bit challenging because you don't really have anybody who has experience to say, "Hey, I don't think you should do it that way because this thing that happened to me because," because nothing's happened to anybody yet. So that piece can be a little bit challenging, but for the most part it's exciting and very greenfield. And I suppose there are fewer abstractions as well, libraries that people have built, which can be difficult. A lot of people are working on different things and so you have to decide, okay, which one of these horses do I want to bet on for whether this is the right path to go down to solve this particular problem? Or do I want to just build my own? That can be a challenge as well.
And typically in the early days of framework, things do change quite a bit. And so keeping things up to date can be a challenge there too. But as far as the solidity of what I'm teaching people ultimately being, use Remix, it's really great. That has worked out really nicely.

Noel:
Nice. Awesome. Did you find that your audience, once you once were focused on Remix specifically or it was all Remix oriented, was that audience, were they pretty technically proficient web front end people already... I have this inclination that when you're looking at these new frameworks that are pretty, I don't know, early in the development, is the right term, but they haven't proliferated super heavily just into the professional developer ecosystem yet. I would suspect that most people there are already pretty web proficient versus some... If you put up a poster for a introduction to a React class, you might get a lot of people coming in that don't have a very deep background yet. Did you find that to be the case? Were most people, they were pretty proficient with one web technology or another already when they were coming into these dialogues, whatever form they took?

Kent C. Dodds:
Yeah, that's an interesting question. So definitely the early days, especially when it was developer preview, we didn't get anybody... I'm sure that there were a couple, but there were very few people who didn't already have a good understanding of the web platform joining up with a developer preview. Because, if you're a brand new developer and you're not sure how to evaluate different frameworks, you're probably not going to choose the one that makes you pay money to use. So the first 500 people who were actually paying for access to Remix, myself included, were experienced engineers for sure. And most of them were just building things just to play around with it and learn from what they could. And for a long time, my website was the biggest deployment of a Remix app in the world, for probably almost a year. So I think that as time has gone on, what I really like about Remix is that because of its focus on the web, the more time you spend learning Remix, you actually spend a lot of time just learning the web.
And so the skills that you get are transferable, which I think is really valuable. And the other thing with that is the Remix, because of the mental model of Remix, it actually drastically simplifies web development. And especially if we're talking about just building a React app, where in a Remix world, React, at least for a product developer, turns into just a template library. Now there are of course still advanced components like dropdowns and carousels and modals and stuff, some things that require some more experience as a web developer, but for the vast majority of product engineers who either have a UI toolkit library that their company has built or can just use one off the shelf that's open source, when you're building your pages with Remix, you're just temping things out there. There's really not a lot of complex React stuff you have to do or think about. And so I think that Remix is actually really well positioned as a beginner's first framework for sure.

Noel:
Nice. Yeah, I wasn't trying to imply that it wasn't or anything. I was more just curious. Again, on something as fledgling or a more fledgling project, I would suspect that you'd get people that are a little bit more privy to new stuff that's going on versus just walking naive. But I think-

Kent C. Dodds:
Yeah, 100%, and that was exactly the case in the early days of Remix, and I think we're moving on from that and we're getting a lot more beginners in the community for sure.

Noel:
Nice, nice. That's exciting. So what was your day to day at the time? Where were you focusing your energy?

Kent C. Dodds:
So my title was Co-founder and Director of Developer Experience, which is weird because Remix was definitely founded long before I joined, but they wanted me to be a part of product direction and things of that nature. And so they gave me the title of Co-founder. And we had our weekly planning meetings on Mondays, the three of us, to decide what was important and what people should be working on. And we had nine of us, I think, the three of us included, and so just had to decide what are different people going to be working on. And so then on Tuesdays we would meet with everybody and say, "Here is the thing, this is the direction of everything." My primary focus was developer experience related stuff. So the CIO, the stacks thing that we came up... That was Ryan's idea to have these project templates that were really easy to get something rolling.
I ran the conference that went actually crazy well. Within six months of open sourcing, we had over 300 people at a conference, in person conference. That is outrageous. So that was awesome. And then I also organized the meetups. I think there are 12 of them now all over the world, over 2000 members of those. And so that was something else. I managed the Discord community, the mailing list, all community related stuff. The biggest thing for me was getting people's attention and growth. So my job was to get people to give Remix some thought and attention. And then Ryan and Michael's job was... Well, Ryan's job was to be the CEO, which was a silly amount of work. That sounded like the worst job ever, honestly. There's so much stupid stuff you have to do to be a business. But he definitely took a lot of time to review PRs and stuff.
So Ryan and Michael's job was to make the framework awesome and then my job was just to get people interested. And so I actually spent a lot of time giving talks and traveling for conferences and writing blog posts and stuff like that too.

Noel:
Yeah, nice, nice. I'm sure it was a very busy time and you were wearing many hats and it was stressful.

Kent C. Dodds:
Yeah, early days of startups are fun.

Noel:
Yeah, no, it's awesome. So what are you taking with you from that experience into epicweb.dev? What's carrying over? What will be in the middle of the Venn diagram still?

Kent C. Dodds:
Yeah, so epicweb.dev is something that I've been wanting to build for a really long time. I always called it kcd-edu, which is basically everything that I know about web development goes into this. So it is an extremely large platform of knowledge that I plan to build ultimately that will be a good place to direct somebody who thinks they might want to learn how to program. So somebody who's never programmed before, but also somebody who's very experienced in web programming and wants to level up. So it will cover the whole spectrum. And the way that I'm doing this, I've been teaching for a long time, created Epic React and tens of thousands of people have gone through both Epic React and Testing JavaScripts. I've given workshops to thousands of people. So with that experience, I've learned that the best way that I can teach is by giving people hands on experience in building stuff.
And the way that I'm going to do or that I plan to do that is by building a real world app that has real world product requirements. And then basically when I finish building that, and right now I'm building that openly, you can watch me, I live stream pretty much every day building this app. When I'm finished with that, then I will turn it into a series of workshops and I actually have my partners at egghead.io or Skill Recordings as they're now called. They are watching all of my live streams and picking out the pieces of knowledge that I need to be able to teach so that people will know everything they need to know to be able to build what I built.
And so, yeah, I'm going to turn this into a series of probably 30 workshops and basically I see it as relatively comparable to a CS degree. So it should take people probably a year to go through all of the material if they're starting from scratch and maybe even longer depending on how committed they are to the timelines. Anyway, that's the idea of what it is. It will be, let's build this thing together from scratch.

Noel:
Nice, Nice. I have other questions I'm going to ask. I'm dig in a little bit there because I feel like very seldom do you hear someone talking about an online course or a code school S thing that they will say is the... commitment of getting a CS degree, it will take a year to get through. What has led you to that? Do you think that that's necessary? Do you think a lot of those little, oh, get up to speed on software dev in two months? Do you think that's unrealistic?

Kent C. Dodds:
Yeah, totally is unrealistic. Everybody's making things up. I hate that so much, that people feel like there's a shortcut to learning this stuff. There is super duper not. There is no such thing as a shortcut to being an experienced engineer. The only way you get experience is by having experiences. And so yeah, Epic React I tell people takes 14 weeks and it's important... You could go through the material in probably a week of just every day you're watching videos. There are like 350 videos on there. It's over 20 hours of content. So if you wanted to marathon it and you watch it on 2X, okay, yeah, sure you can get through all the material, but the videos are not where the learning happens. The learning happens when you go in and you try to work through the material yourself and then you use the video to correct any misperceptions or misunderstandings that you had.
And so the idea that you could learn to become an engineer after just a couple of weeks of going through some course is bogus. Now, I should say that most courses don't have the scope that what I'm planning on has, most of them are just like, I'll learn everything there is to know about Prisma in two weeks or something. Okay, yeah, sure I can learn everything about Prisma in two weeks, but mine is, learn how to be a full stack web engineer from zero in a year. I think even that is pretty ambitious. And so learning is not cheap from a time commitment standpoint. It takes dedication and it's really hard to go through. But yeah, if you've got that commitment, then what I'm building is the best way I know how to get people to learn this stuff.

Noel:
Yeah, I think that is, I don't know, a pretty wise perspective. I think we have a tendency to underestimate the complexity of learning. A lot of them are like, "Oh, we're smart people. We know things about web dev already." But it's the same thing. Until you get in the habit of setting reminders for yourself and keeping things on track, you always lose the details and it's hard to recall stuff. And I think, like you said, you become experienced by experiencing the thing, is a very good way to put it. Awesome. So I guess, how far are you along in your course building your epicweb.dev process, putting that together? Are you getting pretty close or are you pretty early still?

Kent C. Dodds:
Yeah, I'm glad you're asking. So a lot of people will say, "Should I just wait for Epic Web Dev or should I buy Course X?" And most of the time since they're asking me, they're asking about Epic React or Testing JavaScript. But any course, if you're thinking about, I want to learn web dev now, should I just wait for Epic Web? Do not wait. My expectation is that this will take me two years to finish and I do plan on releasing it in chunks because I need to get some feedback and make this sustainable. And the way that I build courses, it is impossible to build them fast because I give these as workshops to real people at least three times before I record it. And so if we are thinking this'll be 20 to 30 workshops, that's like 90 workshops I have to run at least to make this happen.
So this is going to take a long time. I expect the first piece of this to come out part way through next year, maybe toward the end, latter half of the next year. And I'm going to start with the advanced stuff first. It's actually a lot better because I want it to be all cohesive. And so I want workshop one to then go lead into workshop two, and then that leads into... So it's a linear thing. There will of course be specific things like, okay, let's learn about X, that's a side quest or something. But for the most part it's all linear built on itself. And so to be able to do that effectively I actually have... If you ever do a maze on a paper, you'll find that it's always easier to start at the end and work backwards to the start. And there's a reason for that.
And so I think that I'm planning on finishing the whole app that we're going to build together, and then I'll start with the last thing that I did and make a workshop out of that and then work backwards so that it actually can build on itself. And then I'll also mention that the beginner stuff when I get down to here, let's learn JavaScript, let's learn HTML and CSS, that will all be free. I have no interest in making money off of people's hopes and dreams, and that's the type of person who's going to be taking those ones, are people who are like, "I'm not sure I want to do this, but maybe." So the beginner stuff will be free and that definitely is going to come... That'll probably come last in the next year and a half or so.

Noel:
A way to set it up, in that, I feel like it has to be almost frustrating to you to an extent to know that, oh, I want to do this thing, but I've got to start at the end to make sure that the transitions are clean and everything works. But I appreciate it.

Kent C. Dodds:
It's a little frustrating. It feels a little waterfall to me where I have to build this app and I'm maybe halfway done with building the app and then I'm going to have some experts come in and help with stuff like design. I'm going to actually hire a designer because I'm not teaching design. I am not good at that. And you wouldn't want me to teach design. So I'm going to have a designer come in and then I'm actually going to do interviews with experts to review the code. So somebody who's an expert in database modeling, how do I do? And we'll record that and that will be a part of the course as well. And then of course I'll make adjustments to the material before actually recording. So I'll have a number or a series where experts tear apart what I've done, which I think will be valuable for people to see as well.
And then, yeah, so far I've gotten probably 20 to 30, actually maybe quite a bit more, maybe 50 hours worth of live streaming that people can go watch now and see my progress on the app. So if somebody just didn't have the money to do this and wanted to learn right now what I'm doing, a dedicated person could just go and watch my live streams. The problem is that live streams are low value to time ratio things, but I have thousands of people watching my live streams. And so people do it and it can be interesting.

Noel:
Yeah, maybe people just enjoy listening to your voice and they find you calming and entertaining. But yeah, amidst this though, you're still writing blog posts and working out a bunch of other stuff. How are you managing and splitting up your time?

Kent C. Dodds:
Yeah, I am also the father of four children and all of that too. So this is my full-time thing. And so when my kids come home from school and everything, and when I'm done with the day, at 5:00, I'm just hanging out with them and stuff, weekends and all that. All the blog posts that I'm writing now are going onto the epicweb.dev/articles that's important for SEL purposes and all that too. So I'm not shy to admit that I'm trying to get people's attention on this so that... You got to build an audience around it and the brand and stuff. And so everything that I'm doing is centered around Epic Web. In fact, the last couple of live streams I've been updating my website, kentcdodds.com. But it's because I want to investigate a technology I want to use in what I'm building for the app that I'm building.
It's called Rocket Rental. It's basically, if you've heard of turo.com where you can rent out your car to somebody, this is where you can rent out a rocket, it falls the epic theme of space and stuff. So hopefully, ridiculous enough that people won't actually believe it's real, but realistic enough that we've got a product I can basically clone so I don't have to make as many product decisions and I can just focus on, okay, what does a real world product need for this sort of thing? Anyway, that's where things are at so far with that.

Noel:
Nice. Yeah, we're into fun space puns and space analogies too, being at LogRocket, it's all there. I'm in into the energy. So I guess part of the reason I brought up the blog is we were... Kate brought it up actually, one of your recent posts and I read through it and it was really good, your posts on the web's next transition. It's a pretty long post, but can you give us a high level of what that post covers and what you're talking about there?

Kent C. Dodds:
Yeah, sure. I could obviously talk about this at length, but I'll keep it brief. So the idea is that since the beginning of the web, we've been able to build applications even over 25 years ago when HTML came out, it had both a form and an anchor tag. So you had the ability to transition between pages, go from one page to another, and the ability to make changes to the data on the back end, to submit data through the form. And so we've been able to build web applications since the beginning of the web and the mechanisms were there. And so the first way that we did that was with a multi-page app. We didn't call it that, it was just a website, but that's what we call it now is a multi-page app. That's the architecture for that. There were problems with the architecture that led us to the next architecture that I call a progressively enhanced multi-page app.
Problems with that one led us to a single page app architecture, which is where most developers are working on single page apps. People sometimes take issue when I say that because they're like, "No, no, no, you look at all the web stats and most apps are multi-page apps." Well yeah, that's because we have WordPress. And I'm not talking about most deployments, I'm talking about what most developers are working on. And by far, most developers are working on single page apps or some variance of that SSG that counts. That's a single page app too. So once the user gets there and they transition, the architecture of how requests happen, that's single page app. And so the blog post describes those architectures. I feel like we are currently in the process of transitioning to a new web architecture that I'm calling a progressively enhanced single page app, or shortened to a PESPA.
And Remix leading the charge on that, but other frameworks are following suit. So Sveltekit and SolidJS in particular are taking advantage of what the web has to offer today and applying progressive enhancement to that to make the mental model for building the web app a lot better and the user experience as well. So I think there are other exciting things that are happening on the web, but as far as taking away whatever UI library you prefer to use it, that doesn't matter. What I'm talking about is the whole web architecture for where the code you're writing ends up running. And in the world that I'm seeing, we are moving to an architecture that is similar to a multi-page app, but with the user experience of a single page app. And that's what I'm calling it, PASPA.

Noel:
Nice. And I know there's a ton we could get into. Again, the blog post is really good. I encourage users to go read it because I read through it and I enjoyed it quite a bit. Can you contextualize a little bit why we would care? What are some of the good disadvantages of Big SPA right now?

Kent C. Dodds:
Yeah, sure. So when we went from MPA to PEMPA, the progressively enhanced MPA or PEMPA, that was driven mostly by user experience needs, the user experience of an MPA is problematic because full page refreshes and inability to really control the loading experience, but progressively enhanced multi pitch apps resulted in an enormous amount of code duplication, made it very, very difficult to maintain. And so we decided to get rid of the progressive enhanced piece and just do all rendering on the client. And so that transition was driven mostly by developer experience and we just lost a lot of user experience benefits there and started doing all sorts of things to benefit primarily the developer. Now developer experience is an input into user experience. So that's fine, you can be more productive, that's great, but what if we could just have a great user experience and developer experience at the same time?
And that's what PESPA does. It brings us back to the mental model of an MPA, which is crazy simple to think about it. It just drastically simplifies your development, so a developer experience is better, but it also gives us the loading experience of an MPA as far as getting on the page on first time, even if all the data on the page is dynamic. A lot of people are like, "Well, I've got SSG, and so it's all just on a CDN." Well, yeah, most of the apps that you build for money where the app actually makes money, it has dynamic data, and so you're going to just have loading spinners in front of your face forever. And that's the status quo right now. My favorite example is chase.com. You have 12 loading spinners on the page, the homepage, not even authenticated. You're on the homepage, you got 12 spinners in your face. Youtube.com, same problem. You download three megabytes of JavaScript before you see anything useful. It's nuts what the status quo is right now.

Noel:
Yeah, Chase is bad. You prompted me. I just loaded it. It's rough. What a landing page.

Kent C. Dodds:
It's crazy. We've gotten so used to this, it's the status quo, but it doesn't have to be that bad. So from product standpoint, it's way better. PESPA architecture is just so much better. And then from a developer experience standpoint, PESPA is also better. So this is the first time we're transitioning into something that's better for both UX and DX and it's really exciting. People definitely need to pay attention.

Noel:
Nice. I guess, do you foresee this transition happening because the developer tooling is finally getting there? Do you think that's driving this more? Or do you think there is a need? Is it a competitive need in the market where to be competitive and cutting edge and for SEO's sake and all this stuff, you need to be doing this? Do you think that's driving it or do you think it's primarily now the developer experience is good enough? You can develop in this kind of way where you have all these nice at ease of a single page app, but you can do it with the performance that the multi-page apps gave us of old?

Kent C. Dodds:
Yeah. Yeah, that's a great question. I think that this architecture was possible technically since we could make AJAX calls. So back in the early 2000s, we could easily have gone with this architecture. We didn't do that for various... okay, so I shouldn't say easily, because one aspect of the PESPA architecture that makes it different from the PEMPA, which is progressively enhanced multi pitch apps, is that we can write our UI and have it run both on the server and the client, in the same language. That is an important aspect of what a PESPA offers you. And so the ability to do that may be a little bit later, but what's driving this, I think frankly for most developers, it's the developer experience that they're looking for. And so our tools have gotten better and Remix is the one that has made people start caring about this, because for a long time people didn't care about progressive enhancement.
If I have a white screen until a JavaScript loads, I'm going to have a white screen until the HTML is downloaded, what's extra JavaScript? And so a lot of what drove our move into SPAS was people just not caring about the UX as much and just focusing on the DX. And so the fact that DX is improved with progressive enhancement single page apps, I think that's driving a lot of developers, but there's very, very clearly a user experience improvement as well with the PESPA architecture. And there are definitely a lot of developers who care about the user experience as well. And also sometimes people care maybe a little too much about the user experience where they're measuring or optimizing for milliseconds rather than how fast their UI renders, rather than thinking about, hey, how about we change our infrastructure a little bit and get hundreds of milliseconds faster?
There are may be some misunderstanding on where the biggest bang for your buck is. But the cool thing is that Remix also deploys everywhere. Wherever you want to deploy, you can deploy it on Akamai if you wanted to and have it run server side on the edge on Akamai, which is pretty wild. Remix is just going to improve both UX and DX. And so I think that's a big reason why so many frameworks are moving toward this type of architecture, is because you just get both UX improvement as well as a DX improvement.

Noel:
Yeah. Awesome. Awesome. Yeah, thank you for that overview. I know it's always hard to distill this thing that you felt more into a big lengthy blog post, it's like, oh, give us the five minute version, but I appreciate you going through it.

Kent C. Dodds:
I am giving this as a talk, so if people want to dive a little deeper even than the blog post, I have various conferences I'm going to in the next couple months. So if you go to kcd.im/map, you'll see the conferences I'm attending in person. And if you go to my website slash talks, that includes remote workshops there too, or remote talks I'm giving there as well.

Noel:
Nice. Awesome. Yeah, we'll get links to both of those and all the other stuff we talked about in the show notes so people can find it. Is there anything else you'd want to point listeners to?

Kent C. Dodds:
Yeah, so as far as shameless self-promotion, testingjavascript.com is a great place to learn testing, epicreact.dev is a great place to learn React. And I have a really awesome Discord community as well. If you want to join that, you'll find links to that on my website. And if you want to keep up with what I'm doing, my YouTube channel is where I'm live streaming and epicweb.dev is where you'll find new articles that I'm writing, all about the web. The thing is, you asked earlier what the Venn diagram between what I was doing at Remix, what I'm doing now with Epic Web Dev is, and there's definitely overlap. The cool thing about Remix is that it's not so much a... We don't like people calling it a React framework because it totally is not. In the future, React will be an option and you'll be able to use other UI libraries.
What it is a web framework and so much of what Epic Web is going to be is about web fundamentals web stuff. And so there definitely is a crossover and I'm using Remix of course, to build it the app that we're going to be learning with, but so much of what Epic Web is about the web and that's why it's not epicremix.dev, which I was actually planning on building, but my ambition grew. I know I want to focus more on just everything there is to be a full stack web developer.

Noel:
Nice. I think Epic Web Dev rolls off the tongue a little bit.

Kent C. Dodds:
Yeah. The idea is I want to turn you into an epic web dev.

Noel:
Yeah. Yeah, it's good. It's great. Perfect. Cool. Thank you so much for coming on and chatting with us, Kent. It's been a pleasure.

Kent C. Dodds:
Thank you very much, Noel. Take care.