00:00 What is up, everybody? I'm Kent C. Dodds and I'm joined by my friend Sam. Say hi, Sam. Hey, how's it going? It's good to have you here, Sam. So for those of you who are listening who don't know Sam, Sam and I go back, let's see, I started following you on Twitter

00:19 when it was still called Twitter years ago, just really liking your takes on there. And then I think we met for the first time in real life this year at React Miami. It's funny because I met Ryan Florence this year too for the first time, which is insane because we've been working online together and interacting

00:37 for like 10 years. You know, it's just kind of how it is. But yeah, I think Miami was maybe the first time we met and then we got to hang again in Big Sky DevCon in Montana. Yeah, yeah, couldn't find two places more different. Yeah, that's right.

00:55 Yeah, but it was awesome and it's always been great meeting you. You're a very practical and pragmatic kind of developer. You don't have any alliances with anybody. You're just like, I'm doing the work and I'm using the things that let me do the work and appreciating

01:15 what lots of technologies have to offer, which I really appreciate. So anyway, that's my perception of you. But Sam, why don't you introduce yourself to the audience here? Yeah, thanks. I appreciate you calling that out because that is something that is, like, especially as I've gotten further into

01:33 my journey, realizing that I've had a bad impression of a piece of technology when I first heard about it and then realizing I was wrong and then just realizing, like, these things change. It's really hard to predict the future when it comes to this stuff. So just, you know, you kind of get those doses of

01:51 humble pie early in your career and realize that, okay, next time, I'm not going to just put a stake in the ground so fast because I could be wrong and I could be missing out on something that makes me more productive, makes my apps better. So, yeah, I would definitely agree with that characterization. So, yeah, I'm a front-end developer,

02:09 I guess. I mean, I'm a full-stack developer, but I call myself a front-end developer because I like to spend most of my time in the UI, in the details, micro-interactions, the styles, so CSS, HTML, JavaScript. But when I started coding back in 2013, 2014, I was using PHP, I was

02:27 using Symfony, which was a framework, and then kind of moved into JavaScript, worked on Ember for a long time. It's kind of how I cut my teeth on UI development, learning about, you know, stateful UIs, re-rendering all the kind of rich stuff that we're used to doing these days in React, and then been doing React for years now. So that's

02:45 where I'm spending my time these days. Yeah, super. So what was it that pulled you from Ember over to React at first? Well, I didn't actually go at first. I stayed in Ember for a while. We had... One of the things I do right now is run a website, Build UI. It's mine, my buddy Ryan's video course, and

03:03 we teach, you know, front-end stuff, but the previous version was EmberMap.com. It's kind of like EmberMap 2.0. So EmberMap was our video platform for teaching Ember. And so we were really in Ember and loved it, loved the community, had a lot of good friends there. Ember tried to do a lot of things.

03:21 It got a lot of things right, but it tried to cover the whole gamut. It was kind of trying to just be like a Ruby on Rails for JavaScript, which I think we can talk more about later because this is something I've been thinking a lot about with frameworks like Remix now in the ecosystem. But I think it tried

03:39 too hard to do too much out the gate, and it did too much of copying patterns that were successful in Rails and trying to shoehorn them into JavaScript where it actually didn't quite make sense. So I think they learned that lesson, but basically Ember never really kind of took off the way React

03:57 obviously came around and ate everyone's lunch. And so eventually I tried it out, loved the simplicity, loved how it embraces JavaScript patterns and all of the tooling benefits that we were getting with tools like Prettier and Imports and TypeScript just came to React apps because it was just that lower level, whereas Ember had

04:17 a lot of its own stuff for build tooling and things like that. And then if you just zoom every year, you know, you get farther and farther back. So eventually it was just, you can't really resist that tide, you know? Yeah, that is fair. So it took me a little bit because I was in AngularJS

04:35 and pretty deep into that doing education and stuff as well. But yeah, I couldn't resist as well. There's just something to be said for being able to look at the only thing that's not JavaScript in React is JSX

04:53 and it takes you all of like an afternoon to learn JSX and then from there you just compile JSX in your brain to the JavaScript it represents and you get it. Exactly. It's still JavaScript in spirit whereas the tags in Angular and handlebars

05:11 and the helpers in Ember, it's not the same. I love that simplicity of React and just the one-way data flow. That influenced Ember massively. Ember started adopting data down actions

05:29 up, which was their way of saying immutable data and one-way data flow. I think that's the most important thing that came from React and it just made a lot of stuff easier. I absolutely love React. Even to this day, it's like a weekly basis where I'm just like, man, React is so cool. Yeah.

05:47 Right up there with the one-way data flow that came from React or that React really popularized as far as impact is components. Nobody really quite hit composable components until React showed up. 100%. That's 100%

06:05 true. Just making sure, we've had server components and server actions in the last year as this new thing that's coming to React. Actions actually go beyond just server actions. They're also a client-side feature.

06:23 I think it's been a mixed beta period for React because so many people are using different tools and technologies and maybe they haven't tried out server components and server actions or it's not a good fit. They're building a rich SPA with

06:41 TAN stack tools and it feels like it's across a direction. But I am just sitting back and watching and saying everything React has ever added has been a win. They have never had a bad API

06:59 that they added that they regretted that they ended up trying to cover over because they take their time. There's some things like forward rep that were there. It's almost like deliberately for backwards compatibility and that's a suboptimal API. But if you think about hooks and you think about components and you think about

07:17 all the stuff that they've added, it's only been good, really. I think you're hard-pressed to find a single API that has made it into React Core that hasn't dramatically improved the DX and the day-to-day lives of React developers. That's how I feel about the library

07:35 too. Whereas I don't think you can say the same thing about probably most other UI libraries. I would tend to agree with that for sure. And there's been evolution and stuff, but never something that you're like, oh man, this was worse than what we had before. It's always been a forward progression. And I think there's

07:53 some tension here where something like the Ember community would see a pattern like render props emerge from the community. And they would say 90% of React developers are doing this. It's 2018, right? We need to have a first-class API in React

08:11 that blesses this, that makes sure when people want to yield out data to the caller that there's no foot guns, that they fall into the pit of success. So we're going to bless it. And React doesn't do that because they know that maybe there's compound components coming. Maybe there's something else

08:29 that you can do that hooks are going to change the way we share behavior, right? And I think that takes a lot of diligence to keep things out. But I think it's easy to err on the other side. And I think when you err on the other side, we've seen it can

08:49 cause a lot of issues with upgrades. So I appreciate, whereas this was something that was hard for me to really buy into about React when I started because I was coming from a more opinionated setup, it's something I've come to appreciate about React. I can trust the APIs it has if I'm sticking to the docs

09:07 and the guides on React. I know that that's going to be really good information. Now there's a lot of stuff that we need frameworks like Remix for on top of that. But as a foundation, it's one of the technologies I felt most confident about my career. Absolutely. I actually want to dive into

09:25 the opinionated past that you're used to and the future that you hope will be one day because we've had some good discussions about this. React Miami had a great discussion about this. First, I want to get some context

09:43 from your past and other frameworks that you've used before. My impression is that you used Rails quite a bit back in the day. What was it about Rails that made it so special for you? I'm actually still using Rails. As one of our consulting projects, we have some Rails on the back end. I found Rails

10:03 and I would have to say one of the things that makes it special is it is the code and the framework but the community and what I learned about software design from the Rails community from 2010 to 2020 was pretty special. They were pretty unified.

10:21 They were focused on what you said, the pragmatic side. Maybe that's where I get that part of my developer philosophy. DHH is famous about showing me the code. We're sitting here arguing about all this stuff. Let's just look at the code. Is this more pleasant to work on than that?

10:39 That was a big part of it. Sandy Metz and her talks were very influential to me. I know you're a big testing fan. I am as well. The Ruby community is huge on that. I think all of that stuff, really when I was starting programming,

10:57 being able to build full stack apps, ship something by myself without really having to understand how all the pieces work, that was the thing that I loved about Rails. If you've never written Ruby code before, Ruby is crazy. It's a crazy programming language.

11:15 It has a lot of capabilities for what they call metaprogramming. You can write DSLs that almost don't even feel like Ruby. It feels like something closer to stitching together a visual app builder and doing data calls. It doesn't really even feel like programming sometimes. You're just following

11:33 the guides because the APIs are so well thought out and because Ruby is so expressive. You can get very far without having to understand how all the pieces work together. That's a very important value of Rails, of DHH. He talks about conceptual compression

11:51 and I loved that when I was starting out. But you still love it now, even though you probably do understand a lot of it. Exactly. I do still love it, absolutely. But you run into parts where you need to understand how something works beyond

12:11 what's in the guides or beyond the happy path and then you can dive in when you need to. A lot of our conversations around this is in the JavaScript spaces that I feel like that's not really true for a lot of setups in JavaScript land, in front-end

12:29 land, where there's not that progressive disclosure of complexity. Instead you're hit with a lot of that complexity right at the beginning. I can understand that, for sure. So, if Rails is so great, then what is the

12:47 motivation for somebody to not use Rails? Especially when we start talking about React server components and having JavaScript on the server, Rails, as far as I'm aware, isn't able to render React components. I think I've heard some interesting experiments, but that's

13:05 not really what it's geared for. And so, where's the cliff where you decide, okay, I'm jumping. We can't use Rails for this project. Right. Well, like I said back earlier in my career, and I talked about this at my BigSky

13:23 DevCon conference talk, where I was using PHP, I was using Symfony, which was another opinionated framework, so you could use those interchangeably, and I was rendering a D3 charts page, and I had it filtered. It was a survey for a financial software company I was working for,

13:41 and I wanted to let the folks at my company click on parts, like a chunk of the pie chart, and have it anime open and redraw and filter everything else kind of on the page. And, of course, Rails doesn't have anything for that. There's ways to jump out of

13:59 writing Ruby, or writing PHP, and write the JavaScript that you want that just uses D3. But I felt like I hit that ceiling, and I was interested in spending more of my time in the UI UX part, and just really polishing those details. It's kind of just what I fell

14:17 in love with about building products. And so I wanted to use a tool that was built for UIs. So first it was Backbone, then it was Ember, and then it was React. And now, it doesn't mean that it was like I can't use Rails. It was that I wanted to use a front-end tool for the

14:35 front-end, and then I also would build sometimes, for example, with Ember Map, we built our back-end as an API in Rails. But that's why I'm so excited about things like server components, because you get the high ceiling of a front-end framework, and hopefully we get a little bit more

14:53 of a higher level for the floor to start out with. Because, as much as I love Rails, it really shines when you're using it for everything. When you just use it for the API, now you have a lot of complexity in the in-between that Rails is no longer helping you with. That's kind of where I'm at these days. I like your metaphor

15:11 of the ceiling, and I've heard people in the Laravel and Rails communities saying, no, we don't have a ceiling, because we can use JavaScript. And they kind of include that where I would say, no, if you're bailing on the framework, it's because you have to use JavaScript. For them,

15:29 they kind of feel like the client-side JavaScript is part of the framework, which is an interesting perspective. Yes, I think that's a really good point. I would say two comments there. First, if you just say, yes, I can drop in a file and write JavaScript as part of

15:47 this app I'm building with FrameworkX, and therefore FrameworkX has no ceiling, that's not really the point. In the same way that creating a Next app or even a Remax app, I would argue, and being able to create an API endpoint in the file,

16:05 but not having, you know, just because your framework can run front-end and back-end code, I don't know if that's a really good, meaningful definition of full-stack. To me, full-stack is frameworks that have thought about the entire part, the entire lifecycle, the entire needs for user flow.

16:23 And if you are starting a new app with a framework, and you want to let a user sign up, send them an email when they do, that gets enqueued on a job system, and it can render rich UI, it can save things to a database, it can authenticate the user, and you don't have to wire that stuff up

16:41 together, and you can write a test, like we mentioned, I know you're a big testing fan, can this framework of yours let you write a test that says, when I sign up with a user, the user ends up in the database, and the email that gets sent out on a job queue is scheduled, I can assert that it's scheduled in my job queue

16:59 system, that the name matches the name from the user in the table, and that the UI renders correctly, and if you try to sign up with an email that already exists, I see a failure. You know, frameworks like Laravel and Rails let you do that in an unbelievably elegant way. Like, it is, if you've never seen this before, if you've always wired

17:17 these components of an app up yourself, to see how expressive you can get when you use a full-stack framework, it is pretty mind-blowing. So, to me, that is the more meaningful and interesting definition of full-stack. Yeah, yeah. I think I really liked what

17:35 Taylor Otwell said about full-stack, because it confirmed my biases. He said, well, if you can run code on both sides, then I call that full-stack. But, no, I agree with you. I think that there's more... Maybe that is full-stack, but is it a framework? Maybe what I'm talking about is more of

17:53 like, what is a framework? And to me, it's like, it's your buddy that helps you actually build something and ship it, and it's going to do everything. It's like your friend that's doing that. If I just have a tool that lets me run code in the back, well, now I still have to write all the code. And all that complexity has moved to that in-between, just like you were saying, you know?

18:11 So, that's why I think things like Laravel and Rails are a framework. You know, Laravel doesn't just let you write JavaScript on the front end. They actually do have some... They have different tools like Blade, and there's other first-party tools that let you do things

18:29 like, when I hover a button in JavaScript, like, enqueue this to the job system. And, again, it's taking in a lot of that complexity that's the network and the different parts of the system. But there is a ceiling when you use those really built-in tools

18:47 that, if you want to drop down to just writing D3 or writing any browser JavaScript, well, then, yeah, you're going to be kind of on your own. But they're still trying to mesh all of those things together. And so, I think that's why I give them the framework flag. You know? Whereas

19:05 something like a lot of what we see in our front-end space, we don't have opinions about the job systems, the database, and off built-in. Everyone has to do that themselves, which requires you to understand a lot of things. Yeah, 100%. I think... Which is what Epic Stack is all about,

19:23 right? Reducing that complexity. Yeah, precisely. But the thing with the Epic Stack is that we're still wiring it up. We just did it already. But the wiring is still there. It's like you're building a house, and before you get the drywall in,

19:41 you can see all the wires, and you can change them. And that's actually one of the nice things about it. You could go over to Laravel or to Rails, and that's like buying a house that's built, and you can change the pictures on the walls. Or you can go into a half- finished house, and

19:59 you can make changes to it, and then put up the drywall yourself. But actually, that's a pretty good metaphor, I think. Yes, I think something that's interesting is that it's definitely true. Obviously, if you write all the code yourself, you could do so much more. However, and again, this is my bias, especially being influenced

20:17 by the Rails community, but I also think this is... I really deeply believe that this is true, is that the wires can be shared, right? And so you can give me the wires, and I can build my whole house. But I can also change the wires.

20:35 In Rails and Laravel, the wires are themselves a product that is being worked on. That really is the framework. And so every time someone clones your wire scaffolding and starts a new thing, everyone's using the same thing. And if they find something,

20:53 oh, the wire didn't work in this outlet in the bathroom, that's the open source part that is improving the foundational wires for everyone to come after. And it's all of the stuff in between. Oh, how does it work when we have this thing talking to this thing? It's that code about the code. It's almost like

21:11 metaware. It's like middleware. Or it's like the software glue. It's the software glue that is actually being thought of as its own component, own system, and how are we going to get, especially in a testing environment, all these things to talk to each other. And that's complex, because it's very abstract, right?

21:29 It has to work for everyone's house. And so that software glue is an important thing. And I do think our tools are really good these days, and it is easier than it ever has been for someone like a front-end developer to wire up all the glue they need for auth in a database. But there's a lot of hidden stuff in that glue,

21:47 and I still think there's room for someone to pick up that mantle and give us React developers a framework that manages that complexity in a way that meets us where we are. And it feels like React. It doesn't feel like now we're using some big thing that's

22:05 inspired from Java or something like that. Yeah, yeah. You know, I think that's a really good point right there too, because there are JavaScript-based frameworks that are trying to be the Rails, but they do feel that they're not React, really. They're just like

22:23 a sidecar to what React is in the composability model, which is why React server components and form actions and server actions are so exciting because it enables somebody to build an entire framework with these pieces. Exactly. I don't think

22:41 we've had a React framework win yet, but I think the React framework that will win is going to be the one that feels most like React to use. Yeah. And what feels like React? Well, how do you learn React? You build a to-do list in a component with state. You call a set state

22:59 to create new to-dos. You map over the list of to-dos, and you use closures to do things like deleting a to-do or marking it as completed. All of these concepts are supported by server components and server actions, and I think the framework that wins is going to

23:17 feel like I can take that React component that is a local to-do list that uses idiomatic React patterns, things you would find from the React.dev docs, and just kind of start hoisting it to the back end. And I have suspense for loading, but I'm rendering components, and I'm

23:35 basically calling a server action, but it feels just like calling set state, and it's going to be refreshing things. I have my optimistic hooks. It's so exciting that this stuff is coming to React because I really feel like we now have the tools for a framework that can

23:53 just totally embrace this stuff, and it doesn't feel like, oh, now I have to bring in some model layer, and I have to use an ORM, and are we going to use the data mapper pattern or the active record pattern? JavaScript developers love working with objects, JavaScript objects.

24:11 I think that's why Mongo did so well. There's real differences between something like NoSQL and SQL database, but why did Mongo do so well? Because any JavaScript developer felt comfortable with it right away. If you're telling me to define an ES6 class and use decorators to mark, that doesn't feel like the code I write

24:29 on a day-to-day basis, whereas all these APIs that are coming to React, 19, the form data and form and form action on buttons, server action supporting closures, all of this stuff, it just feels more like React.

24:47 It's great. Absolutely with you. That was kind of the premise of Ryan's talk at BigSkyDevCon as well. He's just like, it was almost like a little bit of a warning, because most of the people there were more back-end folks, and he's just like, listen folks, we left

25:05 for a while to work on this front-end problem, but we nailed it, and we're coming for you. We're coming to the back-end now. I think React did nail it, and I think evidence of that is that a lot of folks I still follow who are big in the Rails space, for example, love

25:23 bringing in React for things like Radix and React ARIA. In fact, they'll be frustrated at the backflips they have to do to get React into their Rails app just because our UI stuff is so good. Especially DHH and the vibe of the Rails community

25:41 is they kind of have their own thing. I think Laravel has more first-class ways to get it in with things like Inertia, but the point being, React is the big dog. It won the battle, obviously, and the other libraries and other spaces I just don't think hold a candle to something like React ARIA, Radix, Framer Motion, all this stuff.

26:01 I think something that came out of the last five, six years of us just obsessing over React components and all these compound components and controlled components and render props and hooks and unstyled components, all these patterns that we developed to make really good UI libraries that we can share.

26:19 And then we have frameworks come out. Next comes out and introduces GetServerSideProps and then Remix comes out and we have Loaders and Actions and Redwood has its own ideas. All of those are specific ways to build the whole thing

26:37 and none of them really feel like writing components do and writing hooks does and we can't share any code that relies on GetServerSideProps with code that needs a loader or an action. And now we have server components and server actions so we just get to keep going and it still feels like components

26:55 and we can still bring all of that amazing composition knowledge that has been created in our community to the problem of how do I bring Auth in and a database from Neon and get those to just work with each other and re-render and respect the data flow. How do I sub them out in a different part of the

27:13 subtree? All of the things mock them out. All of the things that we've been doing we can now do on backend concerns. I think that my hope is that if we were to flash forward five years from this conversation and hopefully we're still talking about React

27:31 then, I think we will be, there will be at least one framework that one of the big frameworks if not multiple of them will look and feel very similar to each other. And it won't feel or look like Rails or Laravel. Not because those frameworks aren't

27:49 excellent, but because those frameworks embrace the strengths and patterns of PHP and Ruby, but this framework will embrace the strengths and the patterns of the React community and they look different. I'm 100% with you. And I am betting

28:07 hard on Remix to be that framework. Yeah, I think Remix is in a great spot. For those who are unfamiliar what Remix is today is going to become React Router version 7. This was announced at React Conf. And then Remix

28:25 is going, the Remix team is right now working on a from scratch rewrite of Remix. And it's a RST first framework which is exactly what you're describing, Sam. Just like, what if we started completely from scratch with the tools we have in React 19.

28:43 And you can actually watch it now. Michael Jackson has been publishing these packages that are server-side packages that like, okay, now that we've got some really good tools, here's how we're going to do file upload and here's how we're going to work with headers. And he's going to keep, like the Remix team has said, we're going to keep on building

29:01 more and more of these packages so that they can be used by Remix. I think it's really exciting. We'll see. We will see. But it's super exciting. I mean, this is something else I talked about in my talk where actually this was my talk at NextConf where I was talking about server actions and server

29:19 components and kind of motivating what the point of them is. And the way I talked about it was like Lego blocks, right? Because React feels like playing with Legos and it's just like amazing when you snap together a dropdown from Radix with an animated list from FramerMotion and it just works and you have like a full access. I mean, it's like the

29:37 most fun I've ever had programming still to this day. And the novel ways that we can combine these different primitives from libraries, hooks and components from different libraries and have them work in ways that the authors didn't even know. Like, FramerMotion author didn't know Radix was going to exist.

29:55 That unstyled component libraries were going to just come crashing into the scene and it's just like a perfect match for it. But it's so much fun to use all of these things in the UI. And then it's like what part of our apps are not fun? Well, as soon as I can't just be snapping Lego bricks in my

30:13 tidy little JSX tree and I go to write an API handler, it's like, oh my gosh, that sucks. And it's like I have to go write some crazy off code and I have to set something up and I have to as soon as you leave the comfort of

30:31 the nice boundaries that React has given you and all the guarantees you get when you just pull in a good hook or a good component from a library. As soon as you leave that, it's just not as fun. And it's not as productive. And you rewrite a lot of stuff. But now we can do all that stuff and still be snapping together

30:49 Lego bricks. And I'm super excited about that. Yeah, definitely here for it. This is awesome, Sam. It's been sweet chatting with you. Is there anything else that you wanted to talk about we didn't get to touch on before we go? I think the last thing I would mention is that

31:07 the actions are a big deal. I'm really excited about actions coming to React 19. We're talking right now and it's August 16th so React 19 is not out yet. But it's coming. And server actions were kind of the first way everyone heard about this concept of actions. But it turns out

31:25 actions are applicable to every React developer. And they are going to let us share the pending state of a mutation of any form submission that you have. So you probably have a lot of code in your app that's like when I click a button, mark the to-do as completed or delete the contact

31:43 whatever it is, something like that. It's basically not loading data. It's not rendering. It's about doing an action. That's what an action is for. And instead of having to do on submit and prevent the default and set as pending to true, you get all that stuff from React which I think is going to enable even more awesome patterns. You could have a

32:01 radix library that lets you toggle something and you give it an action and it knows to show that it's loading or if it's success or failure. It's going to be really cool. And so actions are something I'm really excited about and I think it's also going to influence the next crop of React frameworks like we were talking about.

32:19 100%. I think action, because we've got lots of form libraries and stuff too and I think that form libraries are going to need to either adapt for what form actions give us or just be uninstalled and new ones will need to take

32:37 their place because it's that transformative to the way that we do forms in React. Absolutely. Also things like the useMutation hook from something like TanStackQuery or SWR. They have their own isPending state but you want that to come from an action which under the hood is a transition because

32:55 now I could open a menu, press it, wait for a frame or motion animation and then dismiss it and now React knows about all of that. It's still interruptible and cancelable. The rest of my app is responsive even if there's async work involved. We want all of those primitives to just be talking the same language because finally

33:13 we have a first class concept for our app being in a state of transition that we've never had before. That we can share across all of these different parts of the UI. It's going to be really cool to see how all of these popular libraries that we have embrace things

33:31 like useTransition, actions, useOptimistic. I think it's going to look really cool. I've never been more excited about the future of React. This is so sick. Thanks so much, Sam. Thanks everybody for watching. We'll see you all later. Really quick, Sam. How do people follow up with you if they want to connect

33:51 with you? Twitter is a great place. Twitter.com. I also have a YouTube channel so I'm pretty active there. That's the best way to do it. Sweet. Thanks, Sam. See you all later.