Ep. #7, The Evolution of React with Kent C. Dodds

Brian Douglas: Welcome to another installment of Open Source Ready. John, back again, to co-host with me. How you doing?

John McBride: I'm back. Doing well. How are you, Brian?

Brian: I'm doing fantastic. I think I'm in one of the warmest parts of the country out here in San Francisco with no snow, just like chilling at, what, 55?

John: I survived the deep freeze that we had last week or so. It was like negative 5, negative 10. It was ridiculous.

Brian: Cool, and we're going to find out about your weather real quick, Kent, which Kent C. Dodds here as our guest to talk about React. How you doing Kent?

Kent C. Dodds: Doing great. Hi everybody.

John: Welcome.

Brian: Excellent, so for the listeners who aren't familiar with your background, what you've done in like the front-end JavaScript space, let us know who you are, what are you doing?

Kent: Yeah, so I live here in Utah. I've been in the JavaScript world actually before I graduated. So it's been over a decade now that I've been involved in JavaScript from like just being an individual contributor, but also a community member and a speaker and teacher.

I actually, my first course that came out that I was paid for would've been 2014. So, yeah, it's been over a decade that I've been paid as an educator and I went full-time as an educator around, I think it was 2019.

And I took a little break to co-found, Remix for about a year partway through that. But yeah, I build websites. That's my thing. And actually somebody asked me today like, when are you going to make a React Native course?

And I said, well, I'm not really into React Native, I prefer to go really, really deep and understand something very, very well and then teach that rather than going shallow on a lot of things, and like nothing against that.

Like there are going to be beginners in everything all the time. And so those types of educators are very helpful too, to get help people get an headstart on that stuff. But I really like being able to go really deep and help people beyond just the "Hello Worlds!" And so I go really deep on React.

Also, I actually started out with testing. That was the first big thing that I did, was testing javascript.com and yeah, right now I'm going deep on React, React Router as far as the framework is concerned and all of that.

So I also run a conference and so we'll maybe talk about that a little bit, Epic Web Camp and maybe we'll talk about the camp as well. That's the event that I do in September. That's kind of a unique and fun thing that I do.

Brian: Nice. I definitely want to touch on both of those. But I want to mention like testing JavaScript. I was actually gifting that course to folks that I was mentoring for a while.

Kent: Wow.

Brian: Back when I was at GitHub.

Kent: Thank you.

Brian: So like, I went from full-time engineering to then doing Devereux at GitHub. And I started doing some Open Source and I would constantly always get folks from college and folks in Africa and India that I'd worked with in Open Source and be like, hey, do you want to write a test? They'd be like, I don't know how to write a test.

Well, if I give you this course, like, will you go through it? And like, we'll write tests together. And it became like just handing people a way to like level themself up 'cause, to be quite honest, like it wasn't for you and like Ryan Florence and Michael Jackson and like doing all the ReactTraining. I don't think I already had a career in React back in like 2017.

Kent: Wow.

Brian: So it was my way of paying it forward and I had the sort of extra capital to do that.

Kent: Well, the heck, that's awesome. Thank you Brian.

Brian: Yeah, yeah. And yeah, pay it forward folks.

John: I'll also say that a bunch of your stuff has come to high pedigree for me as well where I was in like Linux land and doing backend stuff, and like I hadn't touched anything frontend for years.

Then joining OpenSauced, some of the people shout out to Brandon and Nick, they recommended a bunch of your content, which was helpful for me to ramp up even just a little bit to be able to do some full stack stuff. So thank you. Thank you so much, Kent.

Kent: I love to hear it. Thank you very much, and it's always gratifying to find out that you're not just taking people's money. Like, I know that I'm making money, like I'm paying for my family and stuff, but like, that on the other end of that exchange is a lot of benefits. So I really appreciate hearing about that. Thank you.

Brian: Yeah, yeah, so you mentioned you like to go deep and like we just crossed 10 years of React and like as of recent you've been doing way more React stuff. I know like early days, I remember actually catching your Angular content back in the day.

But you've been doing React and like we saw so many evolutions of React happen over the course of years. So I wanted to like basically go through some, like, nostalgia of your experience in React and like where we are today with it.

Kent: So I first started getting into React in 2014 and like, I was way into Angular. I was doing a podcast, I was contributing to CORE and I was making libraries that were very, very popular.

There were like some rough edges that I wasn't a super fan of. And I had some friends who were getting into React and saying, hey, you really should check this out.

So I did and I was really impressed, but I was just like, it wasn't quite enough for me to say, okay, I'm going to quit my job and find somewhere else or like rewrite my app and React or anything until like later on that year when I wanted to change companies 'cause I was one of just two frontend engineers at this company.

I wanted to work at a bigger company with more experienced engineers than me, and it was still early on my career. And so then I made the switch at the end of 2015. And so that was like, I do remember having all of those beginner questions, like what's the difference between props and state and like different things because AngularJS was just such a unique thing where a lot of it revolves around these string templates, and if you wanted to really go deep, you spent a lot of time deep inside the framework.

Like I remember debugging in the framework code to figure out why is the digest cycle running and like why is this variable changing? Who's changing this variable? And it was just, yeah, a bit of a pain.

And so moving over to React, now, we're going into, okay, so this is JavaScript, but it's actually being compiled. And so I need to understand that a little bit differently and learn how to see the JSX, but actually like see through it into the JavaScript that it generates and actually learning JavaScript.

I remember the feeling that I had leaving the AngularJS world and thinking, oh, like, I had built all of these tools or mental models in my mind of how the world works. And I remember it felt like leaving a house and leaving all of those tools behind, going to a new house and like, I have to rebuild those mental models in large part because of the template DSL, the domain specific language of AngularJS. It was kind of frustrating. And so one of the things that I have really appreciated about React over the years is how little React is on top of JavaScripts.

When I'm writing my templates, it's actually, I'm just writing JavaScripts function calls. And so it's, you can learn JSX in an afternoon, it's not a really complicated thing. They're just a couple syntax things. And then what I do is I teach people, here's how this converts into regular JavaScript.

And so now that you understand that, oh, okay, so I can stick an expression into here and that's how that gets interpolated into the final product. And so I found myself learning JavaScripts as a byproduct of getting really good at React, which I really appreciate because that's, now, if I ever decided to move on from React, there's a lot that I could bring with me from like mental model and skills in the language and things too.

So, anyway, that's some of those like really early memories of using React. I guess another thing that early in those days was the nebulous nature of React as well. Like this was even before Redux or around the time that Redux came out, and so there was a lot of uncertainty around how to manage state.

And the context API wasn't actually an official thing. We were still doing create class, so this is even before classes. And so there were a lot of unknowns around some of that stuff, but it was still like way faster than the alternatives.

And just, that was a big draw for a lot of companies at the time, was like how much faster React was from AngularJS or doing your own bootstrap thing or whatever.

Brian: Yeah, yeah, so I came from like Ember.js, which is like a very niche community even at the time, but it was all batteries included. So like if you liked Rails, which I came from Rails, Ruby on Rails, it was all batteries included and I got that concept and then I did Angular for a bit for a job in San Francisco.

So I do, I feel the same nostalgia of like, man, like why am I constantly looking at the core code to figure out like how this is supposed to work. I had a very similar experience of it as a breath of fresh air. They'd be like, hey, I'm writing JavaScript and that's it.

Like I, and honestly even at that point, I wasn't even great at JavaScript, but I think years from that point, like I've come to now understand and enjoy JavaScript and I remember actually interviewing for Pinterest, and like we'd be like working with promises and I'm like, dude, I'll never touch this stuff.

Like, but now I come from a world of like, I get how this works, but like we come a bit from there because React is, would you say that React is a little more complicated than it was back in 2015, 2016?

Kent: Yeah. Yeah. And I can speak to some of why I think that is, but yeah, I think it would be silly to argue differently.

Brian: Yeah. So Cassidy Williams wrote a blog post over the summer about her annoyance of React. In the last, well, I guess from my 2020 to 2023, it seemed like Next.js was like kind of eating the entire React ecosystem.

Kent: Yeah.

Brian: So there were directions of the React project that are being dictated by like, not intentionally, but literally it was coming out of next JS, at that time, you joined Ryan and Michael to co-found Remix, which I sense like it's not pivoted, but maybe it's like pivoted back or re-spun back into focus on the Router.

Like, could you help us catch up on like what's going on with React? What happened to React? Like, how did we get here?

Kent: Yeah, so React back in the day when we got into it, it was 100% focused on the view because that was one of the most complicated pieces at the time. Like Backbone Views, anybody who worked on Backbone Views or even AngularJS and Ember, that model view controller thing, just like it never really mapped very well to UI.

So React really solved that problem, just like, part of the challenge was state and or data changing over time that state and how to sync that state with what the UI is showing. And so React just came in and said, hey listen, how about we just pretend time doesn't exist.

And just tell me what it should look like given the current data. So not even state, just like, here's your data, tell me what it should look like based on this. And then you can add state and things that change and interactivity and stuff to that.

But this one-way data flow was honestly like pretty revolutionary in some ways where like Knockout JS and Angular JS, they were all about like, well, Angular's specifically two-way data binding and stuff like that.

And so it was really focused on the view, but there's more to building a UI than just the view. And so the community was left to their own devices on like, how do we solve these other problems like managing state over time and managing like a large app where state needs to be shared across these things.

And so Facebook came out with their flux architecture and then there were the flux wars where we're all deciding like, "What do we want to do?" And eventually Redux came up on top of that and there were various problems with Redux at the time.

I believe now Redux is pretty cool, but I haven't, I'm not going to touch it ever again probably. But like eventually or over time Redux just like, it lets the community work out things and then it just adopts things as they become like good ideas.

An example of this would be React Broadcast by Michael Jackson and Ryan Florence. So this was the what became the context API.

And then Ryan came out with this idea, he called it the React component component. I think that's what it's still called on NPM, but it's basically a component that has props for like component amount and component will update and all of those things.

So you don't have to write a class for the components, you just like render this thing and here are the lifecycle methods right there. And that informed a lot of what ended up being hooks.

And so like the community just kind of figures out these different approaches to things. Like even the Render Props pattern came, the first time I saw that was Ryan's motion.

And that ended up being like an official part of the context, API when it was officially released and then Hooks came around and like changed everything.

And because of this evolution, and we haven't even gotten to server components yet, I'll get there, but like, because of this evolution that happens naturally, it's going to be more complex because it supports like the old stuff. And you have to like, think about, depending on how old your code base is and the code that you're working in, you have to like kind of keep those kind of in the back of your mind. And so it's naturally going to get more complex, but the hope is that like we widen things and then we narrow them down.

Like, and as a community now we don't have to think about those things anymore. But I feel like we're kind of getting into a widening of how we do things. And anytime you experience something like that, it's going to be a transition.

I think that it's actually going to stay a little bit wide with what server components do now because React has decided, "Okay, no, we're going to own a little bit more than we used to. We're not just the view anymore. Now we're going to help you manage your asynchrony."

Which they never did before, but now we have suspense and they rewrote the inner workings of React with effectively zero breaking changes for the vast majority of us. And now we have React Fiber is like a built-in thing. That's a whole thing.

But because of that, now we have suspense and concurrent features transitions and out of that, also around that like 2020, 2021 timeframe, the Covid lockdown shows up and it destroys Ryan and Michael's business of in-person training.

And so they say, "What do we do?" I guess let's finish React Router. And Ryan's like, "But actually React Router doesn't make us any money, so how about I'm going to build this store."

And in the process of building that, he's building a framework. They had documentation on server rendering with React Router. And so he just kind of followed that and slowly improved on that and that became Remix.

And Ryan was like, "Hey Michael, check this out. This is really sweet." So they didn't actually release the version six of React Router and they just went full in on Remix and React Router version six was in beta for like a year and a half or something because they stopped that to actually try and make some money. And so in the process of doing that, they have to solve a lot of problems that React doesn't solve itself.

And that Next has tried to solve and Gerber tried to solve. And the biggest one is mutations. Loading data is like, yeah, you've got this promise. And now, especially now we have suspense and now we have the use Hook, but at the time we didn't have the use Hook.

We did have Suspense, but it like, it was still kind of nebulous how to use it for your own stuff. You could really only use the Suspense features for React.lazy for lazily loading components and stuff.

And so Ryan and Michael say like, "Okay, we're going to fill in that gap with these loaders and then oh, we need to make mutations so we're going to fill in that with actions."

And then over time, and I joined up and we filled in some more gaps for, like dynamically making mutations with Fechers and loading data with Fechers and stuff. And so we're filling in all these gaps. Next JS is trying to do some of that as well.

And the React project also knows that these gaps exist. So they've been like thinking about these problems for years and years and they see what Ryan and Michael have done with Remix. They say, "Hey, those are some pretty good ideas."

I'm sure they were inspired by others, but at the the latest React confetti, they gave credit to the Remix project for what became the formAction API and use formStatus and useActionState. Yeah, I think it's useActionState.

Anyway, now they are adopting these features, building them into the framework and then, oh yeah, let's talk about, like actually loading data. Well, okay, so what if we make it so that instead of loading data, you load React elements.

And so then those react elements can be generated on the server the same place where you'd be like generating your JSON, let's instead of generating JSON for, you know, loading that into the view, we can just load the view from the server, let the server generate the view, then we'll load it up and then we'll spit it out onto the page. Save ourselves, solves a lot of problems or it completely eliminates a lot of problems.

But like all of this complexity that's been added to React over time, it's not just because they're bored and they want to make up problems to solve. These are real problems that we actually experience that the community has been trying to fill in these gaps for data loading and data mutations.

And so now in 2025 we've got React Server components and React form actions or server actions that solve problems that frameworks have been trying to solve for quite a while. And that kind of renders a lot of what Remix was unnecessary. I wouldn't say like irrelevant or anything, but yeah, we can do the same thing in two different ways now.

And so that kind of is a peak into what the Remix team is planning for the future. I can talk about that too, but React has become more complicated because it's taking over more than just the view.

Brian: I appreciate you catching us up. 'Cause honestly, I'll be honest, like I haven't been paying attention to React that closely in the last year and a half mainly 'cause I've been trying to run a company myself.

So I do have some head space now to get back in the React. So I'm actually really excited to start. Actually I'm going to start building more projects, but I don't know what I'm going to build them in. Definitely React, but I don't know what the flavor of the situation will be moving forward 'cause I still have to catch up.

So to be clear, like so the Remix company got acquired by Shopify, Remix, the team still exists and is still working on what is Remix or is that React Router? 'Cause I know there's some confusion last year around that as well.

Kent: Yeah, let me cover all that too. So Ryan is implementing the server rendering documentation for React Router to build out his store. The pieces that are in addition to React Router become what is Remix.

And so from the very beginning, Remix was a wrapper around React Router for like a couple of things like loaders to actions and things. And also it started with Rollup and then they went to esbuild.

So like there was an element of the Bundler as well to make all of that work. So Remix itself was mostly React Router. They get Remix launched, I join up and then they decide, okay, we got to actually launch React Router v7.

They launched version seven and then they realize, you know what, there's like some stuff here in Remix that make a lot of sense over in React Router. So even if people aren't using Remix, they can still benefit from these things.

And so that becomes React Router version 6.4. And so in 6.4 React Router gets loaders and actions and they also add client loaders and client actions. It's a whole thing that it makes a lot of sense, but we're not going to get into it.

And so in the process of doing that, they posted this blog post titled Remixing React Router, but they're basically taking Remix, which was around React Router and just shrinking it down and sucking it into React Router.

And so at that point, by around 6.4 there wasn't a lot left with Remix. And around that time also they abandoned their own esbuild compiler thing and just adopted Vite and added a plugin. By this time I was gone, I'd moved on.

And so yeah, they did that and that made it so that most of Remix was just export star from React Router. And so there's not a whole lot there. And so now they have this like fork in the road, what do we do? Do we like say okay, if you're on React Router migrate to Remix or do we say if you're on Remix migrate to React Router? 'Cause they're the same thing.

There's nothing different. It's just like a VIP plugin now. And so because like seven out of 10 React apps are React Router apps, it just makes it so much easier for developers to go to their boss and say, "Hey, we need to upgrade our version of our Router because like it's so core to what we do."

Or they could go to their boss and say, "Hey, we need to migrate to this new framework." Like which one of those things do you think the boss is more into, right? And so it's just so much better for the ecosystem to say, "Hey, they're still going to use the Remix brand."

'Cause it's the cool, like I'm wearing the Remix shirt right now, it's like the coolest brand ever. So we can talk about what the future is for the brand in a bit and what they're working on right now. But they said we're going to put that away for a second and focus everything on React Router.

And so they slurped up the final thing into React Router and now it's React Router v7, another release with I think like one, maybe one breaking change. I don't know, they've made like three or four breaking changes in the last decade. It's insane how well they maintain that project.

But yeah, so now it's React Router version seven. So if you're on version seven, you actually, you can use React Router in like two ways, even in the same app. So you can have some of your routes that are all client side and it's, you know, spa that we're used to from the Jamstack days.

And then parts of your app can be server rendered and like the modern way that we use things. And coming up here in March probably we'll be able to use React Server components with React Router as well.

And so this is what the React Router team has done for the React ecosystem is they said, we know that you started your app a decade ago and you've been like trying to keep up with things over time and now your app is 3 million lines long and there's not a chance in the world that you're migrating to Next.js.

So in your mind you're not ever going to get to the modern React that is React Server components and server function. And so here's what we're going to do. We'll make it so that you just stick with React Router and we're the bridge to get you to the future of React.

So I would say like if anybody's starting a React app right now, use React Router version seven, it is going to bridge you to whatever future there is in React going forward. And it's a phenomenal framework.

So also, has kind of grown in its capabilities but at the same time React 19 itself has grown in capabilities and things and so there is some overlap in what's going on there, which kind of leads us into what the Remix team is doing next.

John: Yeah, that's exciting stuff. One of the questions I always have around really any open source or I guess frontend framework in the open source is kind of around governance and the future of these things.

'Cause it seems so fluid, I'm kind of more on the outside seeing people like Dan Abramov move on and then Meta trying to fill in big shoes like that. Where do you see the future of not only React but I guess like frontend frameworks in general going? Yeah, maybe we start with React and go from there.

Kent: Yeah, no, it's super interesting because you see a lot of frameworks getting bought. Remix isn't the only one. Of course Astro got bought by Netlify, 11ty got bought by Netlify, Gatsby got bought by Netlify and then of course Vercel is working on Next.js and actually spelt is over at Vercel as well. SolidJS I think got bought by Netlify as well.

So like these frameworks are just kind of, they end up in these com, in fact even like PartyKit, which is not quite a framework, it's web socket magic, but got like Slurped up by CloudFlare as well. So you just see these open source projects that are getting acquired.

And of course it's not an acquisition in like the sense of the technology 'cause it's open source, like they could literally just fork it, but like they're acquiring the talent in the community and the brand is what's being acquired there.

Brian: Yeah, so the the the brain trust and yeah, I don't know if we're going to get a bunch of reactionary comments, but like Netlify acquired Gatsby, but I think they sponsored heavily Astro and then SolidJS, they sponsor the efforts, so they didn't actually absorb the actual IP or anything like that.

Kent: Okay. Okay. Yeah, thanks for correcting me.

Brian: Yeah, saving here all the DMs that you're about to get.

Kent: Yeah, I thought they hired the team or something like that, but yeah, that's good correction. So yeah, it's just interesting that you get this like really, really strong interest from these companies and strong investments to the point where Shopify acquires Remix.

And so what is the future is, like, I can tell you from what I've heard from the lived experience of the Remix team, they love it there. Five of them have told me like personally, like "it's been amazing. They just kind of let us do our thing, they trust us and all of that."

So that has gone well. That doesn't always go well, I'm sure, but that has worked out super, super well. Governance is a challenging topic.

I have mixed feelings about open source being sponsored primarily by a single company because I always feel like, well, okay, they're going to optimize for that company's use cases that worked out okay for React that turned out that the use cases that Facebook had applied, like relatively generally, and you could find some examples of situations where the community wanted them to prioritize other things and that wasn't really necessary for Facebook.

But like also Meta or Facebook had projects or things that they didn't need done for themselves, but the team worked on anyway. Like Create React app is a good example of that. Facebook never used to Create React app and then of course Create React app inspires a whole another thing.

I think that it's probably fair to say that Vite was inspired in part by Create React app as well. And so yeah, I think there's a lot to be said for Facebook giving some engineering time on problems that weren't really their own.

And then of course now we have Vercel that has such a vested interest in the team such that like they employ lots of the core members of the team, which I have mixed feelings about as well.

But when a project gets to that size, then you need to have multiple stakeholders on it anyway. So it's probably for the better I guess.

John: Yeah, it's a challenging people problem and I don't know if any community in any technology solves it, you know, a hundred percent well, but that's an interesting perspective.

I really wanted to ask you about WebAssembly and if you have any hot takes there. Granted again, coming from more of the backend world, discovering that technology and be able to compile down rust or Go or C++ into kind of a unit that can be run by the web browser in a sandbox way safely feels very exciting.

I'm curious if you see, you know, apps in general going a direction more towards some of those backend languages for, you know, bottleneck purposes or yeah, any of those reasons there.

Kent: Yeah, I remember when WebAssembly first started becoming a thing and there were some people who would say, yeah, like, goodbye JavaScript, we're going to be able to write all of our stuff in a proper language.

John: Exciting.

Kent: And I was like, I kind of like Java. I don't know, I like JavaScript. It's great, but I was always skeptical and I feel very validated now.

I don't think there's a chance in the world that WebAssembly is going to be the one way that you deliver properties on the web. Like even for a given app. I don't think that any app is going to just totally do away with all their JavaScripts that their engineers are writing. That said, it fills in some pretty significant gaps on the platform and enables some really, really cool things.

I think a really popular example of this is Figma, where lots of Figma is written in Rust, at least the last time I heard about that. And then also StackBlitz, what they're doing on the web is insane.

Just like totally amazing. Basically like let's be infra level like in browser IDE, but we're not going to actually host or run any of their code. Like, so we're running Node, but it's in the browser and it's not actually Node, but it's like close enough that like it can pass for like, it can run most frameworks and things.

It's remarkable what they're able to do. And I know that like there's a Wasm version of even esbuild and FFmpeg and so, like they're just really, really cool things that allow you to do distributed compute because you're just literally running on the user's device, which I think is very interesting.

So I don't personally plan on getting into any Wasm stuff that's just not my vertical that I'm want to go deep on, but I am happy that it's been able to fill some major gaps on the platform.

John: Yeah, well said. I was definitely one of those people, I was like, I'd never have to write JavaScript again. Great, but funny enough, I find myself, I recently rewrote my blog in Astro.

I found myself really enjoying just a little bit of JavaScript here or there where I needed, you know, and then mostly making it about the markdown content and not having to go too deep.

So yeah, I think that was very well said about where Wasm, you know, fills in different gaps and things.

Brian: Yeah, you're like, you're in the position where you're teaching, I don't know if it's thousands of, of people worldwide, like how to build on the web in an epic way.

And you'd already hinted like React Router V7, like if you're going to start today, start there. Like what other sort of tips would you pitch people who are looking to get React today?

Kent: Yeah, I have the Epic Stack that I built and I maintain actively, which is a project starter that people can use to just get started on building their apps in a way that's like, this is a maintainable foundation.

It has all like the testing stuff set up for you and the deployment and database and models and all like all of that stuff with decision documents that explain why certain things are the way that they are.

So you can say like, well, you know, why did you do authentication this way? Well you can go read about that and the Epic Stack is actually the foundation for all of my course material as well. And so on epicweb.dev, if you go through the full stack workshop series, you effectively are building the Epic Stack.

And so if you really want to like, if anybody's listening to this and they're just like, I just want somebody to tell me a way to do it, there's not the way to do it. There are many ways to do it and you can choose just about any of 'em and you'll be just fine.

So if you want a really clear path on a way to do it that, experience engineer like can guide you, then that is what epicweb.dev is all about. That's what Epic Stack is about. It's a great way to do it and has all of the things that you need to build out, like full stack, great web application.

So yeah, that would be a really good place for anybody who wants to get into building web apps. Beyond that, I would say keep up with the cool stuff going on in the React world because React 19 is pretty legit.

Epicreact.dev is updated to React 19. So I will teach you how all of that stuff works, including React Server components actually. So we haven't talked too deeply about that, but in my React Server components and Form Actions workshop, we build our own framework on React Server components so we can really understand it.

'Cause I'm not teaching Next JS, I just like, I don't use it, I don't recommend it, I recommend React Router V7 but React Router V7 doesn't currently have support for RSCs and so we build our own framework so you can, but like I would want to do that anyway because it just really helps you understand how all that works.

So that would be another thing to look at as well as, like what are React Server components, this is the future, what does this mean for me? So there are a couple tips.

Brian: Excellent. Yeah, appreciate that. And definitely in the show notes we'll have epicreact.dev as well for folks to just click in and catch up from there. But what that says, I do want to move us to Reads, so I appreciate the conversation around React and where we are today. So Ken are you ready to Read?

Kent: Yeah. I've got a couple. My first one is anything by Brandon Sanderson. He's my favorite author. I've got a couple books by him behind me and a couple in front of me.

And yeah, he's just a phenomenal fantasy and sci-fi author. I shared a link of "where do I start?" So depending on what you're into that will tell you what to look at.

Also, I just a couple months ago released the Epic programming principles. I should count how many there are, but there are probably like 70 principles of how I think about programming, what guides my sensibilities around things and my decisions.

So I think principles based programming is really useful to like think about why do you feel the way you do? So check out my principles for programming. And then finally just today or you know, yesterday it was published today, "The Epic Web Conf Boss Letter."

So if you have a boss and you want to go to Epic Web Conf, then I wrote an email that you can send to them to get them to send your team.

Brian: I love when conferences do this, put in the list of things and why I should be going to this conference. It makes this really easy. I've done this in the past for my boss of like, "Hey, I'm going to be here. I'm not speaking on stage but there's value."

Like "here's where I'm meeting, here's what I'm learning." I haven't read the letter yet, but I assume there's going to be some of that value in there so-

Kent: Yep, exactly that.

Brian: Cool, I have a read, I just have one, I assume you haven't read this yet, but I wanted to get your take on this Kent, which is titled "How to Be a Tech Influencer" from Will Larson.

So, Will Larson, he is been like CTO and early employee in a lot of startups. A Stripe for like a moment. I'm not sure where he is doing like, there's a Calm app I think is where he is at now. Maybe he's moved on.

Oh, no Carta, he's at Carta now. Based prolific as far as like CTO engineering. And he has this blog where actually John put me on this blog where he just kind of talks like what it's like to be an engineer.

And the content of it is actually not what you would think of, which is, you know, like do hot takes and get on TikTok. But it's more of like just being approach yourself as like you know, something and like see something that people can get some value from.

And it talks about like distribution of like, hey, like check out newsletters, see if your stuff can get in the newsletters. Look for people who you look up to. And I like this 'cause it's actually kind of me 10 years ago when I started writing content for my blog about what I was learning yesterday and doing workshops, which--

Shout out to your, I did the "Zero to Webpack" workshop years ago. You had put that on open source and like it completely changed the way I knew like how Frontend Web worked at the time of Webpack. So like being able to approach content like that but also turn around and teach it to other people.

So anybody who wants to be an influencer or start a podcast, get a TikTok speak on stage, I highly recommend reading this actual blog post. 'cause I think there's like some really good grounding material for you.

Kent: That sounds awesome.

John: Yeah, this has been a huge guiding light for me in, you know, a bunch of my different content endeavors and things. And I think it's encouraging you to see somebody with like, in my opinion, massive prestige in, you know, tech in Silicon Valley, kind of say like, you don't have to do this.

You know, it's more important that you can like talk to some expertise that you do have, get at a conference or in some blog post or something. But especially the last piece of advice he gives where don't assume everyone's playing the same game and that some people are making content for wildly different reasons than you would maybe assume just at face level for what they're doing.

You know, like maybe they're trying to market their agency or build, you know, the personal brand for various different reasons and stuff where, you know, maybe I just want to talk about some dorky thing and get it out on the internet to, you know, converse with other people of similar interests, right?

I'm curious, yeah Kent, how you would approach that because you do have Epic Web and you know, you want to obviously continue to build a personal brand. Has it been important to, you know, view it in different ways like that? Or what do you think about it?

Kent: Yeah, this looks really interesting. Of course I haven't read it yet, but I think you don't have to be a tech influencer like he says, but it is--

I remember at like in the first year or two when I started building up a following, I realized, oh my gosh, this is such good job security because not like at a specific job but like security in that I will always have a job because like at the time tech was doing so, so great, but eventually it could take a downturn, which it has. And so then jobs aren't as readily available, but I probably am going to be one of the last ones to get let go because like people know who I am and they know that I know my stuff.

And so being well known, like you could be the best engineer in the world and if nobody knows, then you're not going to get the opportunities that you want. And so people do have to know who you are for you to get those opportunities or you just have to make them for yourself.

So there's a lot of value in becoming like a public person, somebody who's known at least by the right people. But yeah, I also really like that don't assume everyone's playing the same game 'cause we're not, those of us public people.

Some people really are just out there for their egos. Some people are really just out there having fun and it just so happens that them having fun is very engaging. Some people are trying to feed their families and this is like their livelihood. So yeah, everybody's kind of doing their own thing.

John: Yeah, very, very well said. The two Reads that I had this week first was Pebble is coming back, which I'm so incredibly excited about. Like it's unreal how excited I am for this.

I'm such a dork. But for those unaware Pebble was kind of a now long dead smartwatch that started on Kickstarter and what was unique about it was it had an e-Ink display and was very low power.

So the battery went for like weeks and weeks, maybe months. I remember having one of the early versions that I barely had to charge, but in my opinion pioneered a lot of like what we would consider good smartwatch UI/UX today and didn't get too in the way.

I think that's what I really liked about it, where, you know, for me Apple watches are just so in the way and like it's another smartphone on your wrist basically. I wear a Garmin today, which is good for like fitness and everything, but is actually kind of dumb for everything besides fitness.

So I'm definitely getting a Pebble when it comes back. When was it in 2016 I think they were acquired by Fitbit and then basically killed the whole product line. So very excited for Pebble. Did either of you wear a Pebble watch or remember this?

Kent: I did, yeah.

Brian: I didn't, but I remember the Kickstarter for sure.

John: Yeah, it was great technology, very excited to see it's coming back and talking of open source, they open source the OS, which I think is very important to mention as well. So you can find it at github.com/google/pebble, which up until this point I didn't really realize that Fitbit was a Google subsidiary, but here we are.

Brian: Hmm, yeah, I think they got acquired as well, like 2018, like right before GitHub actually.

John: Gotcha, so it's one of those acquisition by acquisition situations.

Brian: Yeah.

John: And what was wonky about this is people with old Pebbles couldn't really, the watch just didn't work anymore 'cause it was using a bunch of services in the cloud and yada yada yada, so there were even efforts to like recreate an operating system for the watch to be able to still use your now dead hardware, but it's been open sourced by Google.

So if anybody's interested in OS dev and wants to check that out, it's at, yeah again, github.com/google/pebble.

My other Read was maybe a little cheeky, but DeepSeek-R1 and the research paper around DeepSeek announcing this and you know, the ensuing market buzz and everybody talking about it.

I think it's great, I'm actually very, very excited that, you know, there's more and more innovation and AI and large language models today 'cause it seems like we were kind of stalling for a little bit.

Maybe we were reaching like a, you know, like, ah, I don't know, like, are we going to get another good model? But here we are.

Brian: Yeah, I was playing around with DeepSeek yesterday, locally 'cause you could run it locally on Ollama and it's pretty impressive. I mean, I think the more novel thing is that it's open sourced and that you could see what it looks like and play with it, which also got me to go look at Meta and their Llama 3.2.

So I'm like, oh, okay, let's compare and contrast. So I think it, any takeaway at least for this audience is open source is like winning.

And if you're not paying attention to OpenAI and all this AI hoopla, just know that if you wanted to go build a little small interaction on top of AI in a bunch of training, you can. And it's like it's one end point away, which is, that's the coolest part about it.

John: Yeah, there was a great quote that I saw from this, from people talking about this from Pat Gelsinger, and I don't know when he said this, you know, I guess he could be credited for any of these things, Pat Gelsinger former CEO of VMware now CEO of Intel once said that open wins.

And, you know, it's exciting to see that, at least in my opinion, some of the market value being cut away from these proprietary companies and accelerating open source innovation continues.

Kent: Yeah, the Nvidia drop was hilarious though. Like ridiculous.

John: Yeah. Kind of expected. Like we all know it's a bubble, right?

Kent: Yeah, like, I don't know, I feel like Nvidia is still like going to win with this. Like yes, it's more efficient, therefore we do more things with Nvidia chips.

John: Yeah, I mean, my big takeaway in regards to Nvidia is that, and maybe this is a hot take. I didn't think it used to be a hot take, but somebody told me it was, Nvidia's a software company.

I don't think people realize this. They're a software company that happens to make the best chips in the world, primarily because of Cuda and all these AI and ML frameworks under the hood are running GPU acceleration technology on top of Cuda.

And sure, there's a bunch of stuff you can run on AMD with ROCm and all this other stuff. And this gets like way down into the nitty gritty of how, you know, GPU acceleration works.

But Nvidia is a software company and I can't imagine in the next few years, even five years plus that all these AI frameworks, PyTorch, Scikit, that they're going to move off of Cuda in any way possible.

Brian: Hmm. Yeah. Well, hot take received.

Kent: There you go.

Brian: Excellent. Well, Kent, thanks so much for coming on, sharing some Reads and also just chatting about React. It's always good to catch up.

Kent: That was a lot of fun. Thanks guys.

Brian: And listeners, stay ready.