Sam Selikoff 5.2.24
===

[00:00:00] 

Hello and welcome to pod rocket, a web development podcast brought to you by log rocket. Log rocket helps software teams improve user experience with session replay, error tracking, and product analytics.

You can try it free at logrocket. com. I'm Noel, and today I'm joined by Sam Selikoff. Sam's an educator, consultant, and he focuses on modern UI development. He's here to talk about Incomplete React, which is a talk he gave recently, ~I believe, ~at React Miami. ~I getting that right?~

Yes, sir.

Nice. Welcome to the show, Sam.

How's it going?

~Thanks. Nice to meet you. ~Thanks for having me on. I'm excited to chat about React.

~Cool. Cool. ~So I guess I don't know, React's Kind of a steeped topic at this point.~ What, like where do you think,~ where do you see React kind of sitting in the ecosystem right now? Cause ~it's like, ~it's tendrils are creeping out everywhere. When you think about React and people are talking about React, what are you focusing on?

What do you mean?

That's a great question. ~And definitely ~I remember when React came out and we were all talking about whether it's a library or a framework I've come to think of it really as more, almost like a programming language. ~It's. ~My background originally with kind of heavy JavaScript front ends was Ember.

[00:01:00] And that was definitely more of a complete, like a framework like tool. And it had a lot of opinions about. Even things like how to model your data, how to structure your URLs, React's never had those kinds of opinions. And it's felt pretty low level comparatively. And so I think that's the best way to think about it.

It's really more like a programming language for UIs within the constraints of the JavaScript programming language. And a lot of what they've added over the years has been what feels like missing primitives that allow us to do more and more. Of our app building inside of react. And so traditionally it was just the front end and whenever you make a JavaScript client app, there's this backend piece and the question's always like, how do we talk to each other?

There's too many options. And so they've never been able to have strong opinions about that, but with server components, server actions. And some of these new APIs [00:02:00] that are still contained within the React component model. We now can have more opinions about those sorts of things. So that's how I think about it these days.

And that's what the talk was about.

Nice. ~Yeah. Yeah. That's a,~ it's an interesting lens through which to view this. I guess just to, ~I don't know, ~establish a little bit more of a grammar for us here. Would you also make the same argument for ~I don't know, ~the other popular front end frameworks, like ~it's ~Svelte, SvelteKit, Vue.

Are these also kind of languages in your head now as they become more feature rich?

I think~ the difference, ~the big difference between react and other tools is the other tools are really focused more on the case of helping an app developer build an app from the get go. So you could go to a view doc page or a Svelte doc page and see like How do I render a 404 page? Which is something that like developers need to do and react probably is never going to have something like that because that's too specific.

React is more general purpose. You can ~ ~render things [00:03:00] on iOS with react. You can render 3d scenes with react. So it really always feels a little bit lower level to me than those frameworks. And it's the things that are built on top of react, like the next JS is the remixes that are going to be more at that same level of abstraction as.

A Svelte or even a Svelte kit, but even Svelte itself they're going to have more built in things for just an easy way to do animations, things that 80 percent or 90 percent of everyone making a web app with Svelte need to do. It's more likely that will be rolled back into Svelte.

Whereas if there's something that 95 percent of react developers need to do and they're always doing it the same way. If it doesn't, Work for the 5%. If the 5 percent case is not there, it's not like a complete primitive. It's not a complete abstraction. So that stuff stays out of react longer. That's how I think about it.

I see. ~Yeah. ~Yeah. So these new primitives, air quotes, that React is adding, ~do you think that does You know, ~do you see other frameworks that have these already in your like from this [00:04:00] an advantage point or is this like a unique kind of advantage that react has because it's operating at this lower level where it's and we have to solve this versus just being able to say here's the 404 page function.

I don't have a ton of experience with the newest take on the server client, models and the other frameworks. But I still think ~they're basically trying, ~they've gotten to a point, really started with ~data fetching. ~Data fetching. There was no real way to do it or no real opinionated way to do it.

And that led to suspense and ultimately server components was like the answer for that whole multi year journey, but the key part of all that is this RSC payload, which is like the serialized format of a component tree. And so that still feels like low level, primitivity to me, and it can integrate with a lot of different tools.

So it's still less opinionated and it's still going to be harder. to do a common app developer ~like ~thing with just those base tools. But again, ~it's it's, ~these missing primitives are going to let the frameworks like remix and next provide the higher level things without [00:05:00] sacrificing the composability of a react app.

So that's a lot of this development makes a lot more sense when you think about it from that perspective, where the reacts team job is not it's opposite of what I think of when DHH talks about rails. When DHH talks about Rails, he uses this term conceptual compression, which is somebody should be able to create a blog that is backed by a database, even if they don't know a lot about databases or Ruby, because Rails is going to just guide them through that.

So ~they're compressing. ~He's wanting to compress all the moving pieces into a nice API that covers. A majority of cases, whereas again, react, it's not really ~the motivate. ~The motivation is more, what are missing primitives? Where are parts that some of our APIs don't compose with others, and that's going to allow tools like a rails to exist and cover more cases and just have a more diverse ecosystem.

~So~

Yeah. So like the, I guess the server component abstraction, ~like as it You know~ as a means of data, cause I'm with you that it feels [00:06:00] like a pretty fundamental shift just in like how we are transferring. Information from the server to the client. Do you think that there is some universal abstraction that should be happening or is it okay that it's like part of the language of react?

universal abstraction, that would be outside of react.

~Is this something like, is it. ~Is react the tool to be solving this problem? If it is ~like, why, like, ~why do you think that makes sense? And if not~ wait, ~why does it give you pause?

I think it is an attempt to be that universal abstraction within ~the ~the values and the programming model ~that ~of react. So if you look at where server components came from and Sebastian, one of the main kind of design leads in terms of the actual design of the whole model, it came from wanting to use relay.

Kind of everywhere and seeing the benefits that relay provided react apps, and then asking that question, what is the universal way we can get this to all react apps? And so people could use [00:07:00] relay, but not everyone does or wants to. So the big benefit of relay is the ability, again, thinking about components, you get to co locate and encapsulate the data request within a component.

And if you have the tooling set up, you have. One component over here, which fetches, your latest notifications. You have one over here that fetches your messages and your inbox. And those things are isolated in the same way that like a dialogue is isolated from a dropdown and all of the APIs that react gives us lets us author those two components and not have any spooky action at a distance, not rely on anything global.

That's again, the motivation for things like the context API, all these things. So with relay, we get that for data fetching. And then the question is, how can we. Bring this to everybody and making everyone use relay is ~not, was not really, that's ~not really ~like ~viable and it's specific. And so I think that's exactly what server components ended up being.

It says, what are our values in react? What do we think made it successful? What are the things we [00:08:00] care most about and react? It's composability. It's this kind of functional style, declarative style of coding. How can we declaratively. Provide a way to get data and in a way that doesn't break composition in a way that is maximally Inclusive of everybody, regardless of their stack, their backend, ~what, ~the way they're hitting their API.

And it's basically this RSC serialization format where you have a component. That's a server component. It's going to get turned into a client component tree and that serialization, that is that maximum abstraction. So I think that's how I think about that part.

~Yeah. ~Yeah. I think it is ~it's ~tricky to conceptualize something that would be even like any more abstracted before you're just like, Oh, like what? Now ~we're just talking~ we're just talking about rest or Jason or something again, right? ~It's ~It feels like we're almost as close as we can get and maybe it's okay that those are tied.

It's tied to the framework. That's just the way we do it.

right. And there's still possibilities here where. Outside of the abstraction, you're doing a rest call. You're making a database request. You're reading something from a file system or an SQLite [00:09:00] database. But what you output is ~this kind of ~the server component. And then as long as you can give me a server component, I can do the rest.

It's just if I were to use D3 in a client component, we have the boundaries like use effect and I can go to town with all my imperative APIs. JavaScript APIs that react knows nothing about, but if I can put them in use effect now, all of a sudden I'm in that box, I'm declarative. I can rerun I'm safe for re rendering and I get all the benefits of composing my custom D3 component with any other react component I install, like a modal.

From radix. And if we're abiding by the rules, we get all this behavior for free. It falls out for free. And so that's how I see server components too. In theory, you can generate a server component using ~any, ~anything, but if you can get the result of that into a server component, then we can just hand it off and get all these benefits.

~Yeah. ~Yeah. Very cool. Do you think that like react is the kind of the best of both worlds now in that it has all this work being done to give us these ~like ~lower level abstractions, which are [00:10:00] useful. These. Primitive abstractions, which are useful and let us do these fundamental things.

But there's also such it's such a whale, like there's all these ecosystem, this ecosystem being built around it, where if you want to step in at a higher level and just build your blog, like whatever, like you name it, build something off the shelf. Those are being built in tandem. Is there like in your, is your opinion that like react is just flourishing in a way that these ~other like ~other frameworks really aren't.

At the moment,

I actually, my opinion here is it's more of a medium or longer term bet, ~but. ~And I think if you were to go back, it's similar to, if you go back 10 years when React came out and they're talking about the design principles and why we should use JSX and then, effects come out and those are confusing and you compare again, the kinds of things a normal app developer would need to do using just reacts primitives versus something like an angular that has a Much easier API surface area batteries included.

Back then it would [00:11:00] be, no, this is not the easiest tool. It's not the best tool. If a team starting an app, they shouldn't have to learn a programming language just to get it. And they're just making a lot of work for themselves. But I think the bet that react made back then is that what these primitives enable.

Is eventually you're going to have something like a radix UI library. And once we have portal API and context API, and all of those things that put all of the features within the boundary today, as a user of react, I can install radix, render dialogue and get so much with the easiest possible.

API ever, I can render a modal and it looks like rendering an A, a PT tag, an HDML. So I think the bet is similar where today, because the stuff is early if you tried to make a blog with just this stuff or even with some of the frameworks that are using it now, and you compare it to the experience of making it with another framework that's.

Again, not focused on rounding out these primitives, but just providing these higher level things. You're going to get smashed because there's a lot to learn [00:12:00] here. But the bet I think is in three, five, six years, the way it looks to integrate authentication, with Auth0 or Stripe. And if they all have all of these service providers have server components, or your team has a server component library for accessing and changing data, it's going to feel as easy ~as it ~As writing that modal component does today.

And ~that's, what's ~that's the bet. That's, ~what's ~really exciting.

Yeah. ~Cool. Cool. ~Let's like kind of dig into a little bit under the hood here, or, as much as we can in our 30 minutes or so what about these abstractions is so powerful that we get these cool tools like Radix you mentioned like Prisma these other things that are these kind of little bursts of productivity that having these like fundamental primitives empowers, like why are these primitives essential?

And this kind of tying in with the previous question too, about whether this is the best or it's, flourishing moment, this is what my talk was about. So the talk was called incomplete react. And the argument was. That we [00:13:00] are as a react community often focus on composition, on making sure everything's airtight, and that comes at the expense of convenience, right?

There's a trade off composition is a value, but it's not an inherent good. When you make something composable, you make it harder to use in certain cases. But we saw eventually when we rounded up the primitives on the front end, we got radix modal dialogue. So now we say you look at a react app and the funnest parts, the best parts are putting together these UI components.

And then when it comes to fetching and saving data or integrating with services, you just look at your app. And this is where you leave the paradigm. You go make a fetch request. You have to make an API endpoint. You start writing all this imperative code, which does not feel like writing react at all. Server components and server actions are the, the missing piece there because they let us express these things declaratively within the react model.

And so that's what the talk was about. It's a call to action. Now that we have these new primitives, [00:14:00] yes, it's fun to learn them and use them and learn how they work, but the goal should be just like, I don't have to know how to create a portal. Or wire up context or set up accessibility things with dialogue.

I just get radix and it does all of it for me. What if I had a Prisma form component and because of server components and server actions, I can start dropping a Prisma form and it knows that I have a model called user because Prisma knows that my schema has a user model with an ID called ID, and that's the first name that's required.

And now I can just drop in like a Prisma form for my user. And it's going to render. Not only is it going to do the front end part where it renders an input that's required because it's required, it can show an error if the email is already taken, but when I render it, it knows how to find that user if I wanted to edit it from the database and when I hit save, it knows how to save the action.

So that's the idea behind the talk. And if you look at rails, they. Because they started out with more opinions, they already know all that [00:15:00] information from the modeling. So they have a form for helper and like Laravel and Django, all these backend frameworks have all that. And it's incredibly easy to use.

But it doesn't compose with all of the things. So that's how we can complete react. And that's how we can get these frameworks that are more complete and help us with all the things app developers need to do. We get something that's automatically connected to the database. We do get that conceptual compression.

I can render a user from the database, but if I want to show it in a nice autocomplete dropdown from radix, I can compose that as well. So yeah,

~Nice. Why do you think, like, ~why do you think these new primitive server components, et cetera, ~like~ why are these the thing that are empowering this? Because I think we could easily conceptualize like old react working this way. Say I've got a database file as part of my build step, it like spits out some kind of schema file that then I can feed into a front end thingy that knows how to render a form.

Like why didn't this work before?~ And it's easier now. Yeah.~

I think it's because react never made an opinion about this. And so many people have done this sort of thing, but [00:16:00] it's never been one. It's never been blessed, but two, It was not clear how that API should look in a way that still feels like react. So I think it wasn't clear before relay, before thinking about suspense and data fetching, that I can render a component called a user table.

And if I squint, I see a rails controller that fetches the users. I see a view that's rendering a table. And so some people might say that's obvious. Like you have a component and that's a declarative version of the imperative steps of fetching the data from the database and then rendering some UI, but the magic is really this RSC serialization format.

And that's what happens behind the scenes when you go from the server component tree to the client tree. So I think it just took a while. They had a lot of ideas and they tried a lot of things. ~Yeah. ~But this again, back to your point of this is sufficiently general.

Everyone's going to be rendering react components. So if you're in a tool that renders react components, then [00:17:00] any provider that gives you something that can render a server component ~that, that's ~that's it. And so that's just where they landed. And it could have been a lot of different things.

But yeah, we just never had anything in react, next had get server side props. So you could imagine like importing a Prisma thing that auto generates to get server side props for this, but that was tied to a route, for a URL reacts, never had a URL. Again, the idea is, I think that makes it clear as where these primitives come from is what is the unit of abstraction and it is the component.

So we have to have something that works at the component level. And The fact that you have we had this whole isomorphic components for a while where they run on both the server and the client. I think the novel thing about server components is that they only run on the server, which is what lets them have a direct connection to your database.

And now we don't have to make assumptions about where the data is coming from. What capabilities are Prisma can ship you something. Stripe can ship you something and you don't need a web hook or ~you don't need, ~you don't need that integration. On the server because the server component again is inside the [00:18:00] boundary.

So I think it just took a while for them to get there, but I do think it is novel as an abstraction for sharing server code. ~And~ and also the ~fix ~fits in with the component model. 

Yeah. ~How do you how do you see, ~I've got two questions I want to ask and I don't want to lose the thread on either. Let's start here. ~Like I'm, do you see much in the way of we talked about, ~or we were talking earlier about how if you're just trying to write a blog or something right now,~ how Like~ it's, this is, you don't probably don't need a lot of this stuff.

Then I would go ~pull it~ pull a tool off the shelf and it'll be your blog. And I think a lot of the beauty there was in ~like ~how easy or the simplicity and where one might run into problems if they're not using a simple tool is like not so much in the getting the thing to run, but it's like getting the thing to deploy and update.

It's like the stuff at the periphery. Do you think that will ever become like super my vocabulary is failing

As streamlined as like rails

Exactly. Like ~it's very easy. ~It's very easy to just spin up a front end only thingy and like connect to some backend as a service and okay, I don't really have to think about this anymore.

Is that ever going to be the case with react server components?

~I think so. ~I think I definitely think so. ~Um, ~remix, even before server components came out, remix was, put a lot of these pieces together. [00:19:00] And next has had this get server side props for a while. But a lot of folks who use next would use providers. And you would have the front end deployed separately from the back end.

I like how remix when they came out, they were like, no, you can just create like a SQL database. And you start it off and then you fetch your data. And the experience is really nice. It's in one page and you can push that up to fly. And it feels very similar to that rails, new get push Heroku master.

I have a full stack app with everything here. I can run it locally. I can run tests against it. So I absolutely think with server components now~ server components make that even, ~they make it even more possible for providers like, or even a Prisma or a drizzle to provide you with. The kinds of components that could do the things that rails could do without needing to know if you're in a remix app, which in which case we needed to run a loader, or if you're in a next app, in which case we need to run, get server side props, server components are react wide.

They're, official react. So I could be in any framework that uses server components, [00:20:00] bring in a Prisma thing, and I can get that out of the box experience. So that again, and that was called the call to action in the talk, which is. It's fun to do all this and explore all these APIs, ~but there's this whole middle class of developers.~

~It's like the middle class. We're not making like rendering engines for 3d. I'm just making waiting for it to catch up here. It looks like there's a little bit of lag.~

~I can hear you fine still for what it's~

~Okay. You can hear me~

~Yeah. Yeah.~

So there's this whole middle class of developers who just need to add features to their app and they just need to build features and. They want to be told that they need constraints. They need more constraints and they needed to fall into that pit of success.

And just if you're writing use effect by yourself, you're probably not going to fall in that pit of success, but if you use React query or SWR, you will, and so now the call to action with the talk is let's try to create some of these higher level abstractions that make it easier to do the kinds of things that app developers want to.

And I really hope that is where the community goes because people shouldn't have to learn all the details just to pull a simple blog off the way they do today. 

~Yeah. Do you think it'll be a bit of a struggle to or say you're. Not ~say you're writing services for developers. Like you want to be in this kind of tooling layer, ~like will there, ~I could see there being some hesitancy to jump all in, say you're a small company, you're trying to decide where to start.

On like react server [00:21:00] components, cause it feels very specific to the ecosystem. This kind of goes back to my first question, right? It's why let's just make an API, like a traditional API versus ~like ~wrapping everything in this layer that only some subset of people will be able to consume.

Do you think that will lead to any slowness in kind of uptake here?

Yeah I do think right now most people are not using server components cause they're, they're not even in a stable version of react. I think it's beta just came out, so it's definitely early, but I saw clerk just put out a new version of APIs. They provide that kind of low level.

Rest API like experience that you can use with anything, but they just released some components. I think it's clerk elements and I think it's powered by this stuff where you just get to render, clerk dot sign in and it's going to feel ~again ~a lot like. Playing with radix components, just piecing these Lego blocks together.

So I think they're jumping in on it. And it's definitely going to be the adoption's going to depend on whether server components become [00:22:00] widely used, but again, react doesn't add APIs to the core library that much. And whenever they've done it, even if there's been pushback, ~they've, I think ~they've basically always got it right.

I think their track record is really good. There was pushback from the beginning. There was pushback on hooks and these days, ~like ~it's just the best, so I think they put a lot of thought into these. And so it's just a question of that time of adoption. But I do think it's exciting because it's the first time we've had this.

Ability to bring in the data fetching and data persisting components from an ecosystem, from a third party into any framework. Yeah, it's just, ~it's a, ~it's hard to make predictions, right? But that is~ that's ~the hope. That's the goal. I, that's certainly what I want to see. So

~no, it's, ~I think it's a cool time to be watching it and experiencing it and

~super cool. ~Super exciting. Yeah. I've been playing with it inside projects and I got to tell you, it's like some of the most fun I've been having playing with this new stuff just again, How much fun I have when I'm in a purely client part of an app and just playing with these amazing third party components and libraries that we have in React and now being able to do it [00:23:00] across the network and having it still feel as fun and just like playing it's amazing.

Nice. Do you think where are you at right now? I think it is cool and it's novel and then I think it Could be very powerful. Like we're saying, but like, when do you think we'll be at the this is a stake your startup front end to this.

Like, when are we at the point where we try this as your V1, like ~make this the, ~come in at this layer of the web stack abstraction.

That's a good question. I really don't like to make predictions a lot and I'm like old and I am slow to adopt things. So server components have been out for like over a year now. ~And I. ~And I've obviously I keep up with everything and kind of vicariously lived through other people who try it out, but only recently have I really been using it in earnest on some admin parts of our website and like shipping it to production.

And yeah it's a blast. It's awesome. But there's, it's new and early. So personally, if I was starting a new startup today, a new SaaS app, I wouldn't use this stuff because again, it's not even an unstable version of react. And yeah, it's, so [00:24:00] that's tough but they've the react team has thrown away ~entire. ~Entire decisions implementations of things because they realized there was a better solution. So it's more of a research project at that level. And now that it's getting blessed We just have to wait and see. But right now, no, I would not do that right now because it's just so early, 

but I guess the people do want to explore, ~get their feet wet a little bit, ~get their feet wet a little bit. Where would you advise them to jump in? What would be some good places to check

Yeah. The hard thing with react server components is that they require this whole bundler integration step. Next the next app directory is definitely the farthest along, but next also is its own set of opinions about how to build things. And Remix is experimenting with how to add server components as well.

There's some minimal server component frameworks like Waku, which is from the guy who does some of the state management libraries like Zestand and Voltaio and stuff. But I've been playing with Next because ~you can ~you can just focus on the core pieces and understand a lot about it.

And [00:25:00] the setup's very good. And a lot of the folks who are on react work at work and contribute to next. So ~that's, I think ~that's the easiest way to get going. And I think for learning this stuff, I do using a database of your own, as opposed to a hosted backend service, cause you can just see, so I like using next and then either, my SQL Postgres or even SQLite, and you can put all that on fly and have it all like that rails Heroku experience.

And I like that a lot. So

Cool. I'm curious, ~what's your~ we've talked about the future a lot already, but what's your vision? Where do we think this will be, in the future? In the coming months. Do you ~think, I ~think we'll see a lot more adoption. Do you think we're still in that like early phase?

~I think, so Redwood also, ~Redwood is another framework that recently switched over to server components. I haven't had a chance to play with that yet, but that's a great sign. Next has them and the team at Remix is looking on how to integrate them. So I think in the next six months to a year, we'll have a lot of options.

I think it's good for us to have lots of options because these frameworks are designed for different things. But server components being that [00:26:00] common abstraction is really cool. And I think that the fact that we just saw clerk release this new API, I think we're going to see a lot of other companies put their hand in and give a shot at what would it look like for folks to be able to use Stripe or the CMS or this all service just through server components.

So I think in the next six to 12 months, it's good, especially with the release of react 19, we're going to see a lot of that. So that's going to be fun.

Yeah. ~I'm curious. ~I'm really curious. I'm like, like an auth service. ~I'd have to ~I'd have to ponder on that a little bit and see how that feels. Cause some things like are easy to conceptualize, like Stripe, like an auth services, like it's so stratified in any like sizable app.

Like it, it runs through a lot. We use auths, like one uses Auth0 and you can The identity piece of it can be abstracted already, but it's really interesting to say, okay, we'll also do the full we'll give you a component, like that can just do this on the backend for you and give you the things you need to, authenticate your app.

Yep. I'm also very curious about this, the off stuff is tough because like you said it's okay if [00:27:00] you have Stripe because you check out, one in one user flow of

~yeah. ~Yeah. It's a simple

it's isolated. It's fine if it takes a little bit longer, if it depends, has an external dependency, a lot of folks with off setups like to have their user alongside their data.

And so maybe you could use these providers to take care of, the Google sign in, getting in the key, but then saving the key locally, and then you can still have components that they provide that know how to find the current user. It makes me think of like devise and rails, which is.

A way you're still doing off yourself, but you're not hand rolling it. They've taken away a lot of the complexity of the details, how to hash a password, you don't have to know that stuff. And what they give you is a current user function that you can call anywhere. So what would that look like with server components?

~Maybe you can, ~maybe you can wrap a part of your tree in require requires the current user to be a role admin. And that component, maybe it makes a fetch to a service, but maybe you have everything locally. And so again, it's still [00:28:00] abstracting in a way, but you're still working locally with your user information, but that would still be a win, right?

Because we don't have to go and write a bunch of code in an API route. It's just encapsulated within the component boundary. It composes with our trees. And same thing for actions too. This action requires some characteristics of the, some permissions for the current user. So I think there's a lot of interesting things here that

~Yeah. ~Yeah. I feel like we could just get down in the weeds on specific use cases for like hours here if we wanted to, but we should try to be as succinct as we can. Is there anything else you want to cover here, I guess on this front any takeaways from your talk that ~you'd like to, ~you'd like to drive home?

I think I would like to, for people to, oh, people in JavaScript and especially React do like their options. They like their flexibility. They like picking and choosing which parts of the stack that they have. They have opinions about Drizzle versus Prisma. And that is true for every part of your, whether I should use Zod for validation or Valobot, I think that ~we're over~ we're [00:29:00] overdue in our community for some more opinionated. Setups and they're not opinionated and they're not scaffolding your project and just saying, here's how you use it. They are true abstractions. The way active model abstracts away your database handler, your connection and the way you validate things in rails. You don't care about all those things. So I think.

It's because we have all these primitives now that cover the whole stack. I would love to just see some experiments with some really high level, pleasant APIs that get somebody from zero to that 20th floor a lot faster. And we don't have to care about all the decisions at every level because they package it together.

So that's what I'd like to see. Just some leadership and ~of, ~Setups where people, you don't, it doesn't matter. Our apps are the same, again, DHH is like one of my programming heroes and I grew up on rails, but he had to argue [00:30:00] for this a lot in conferences that your app is not a snowflake and I know you're used to naming your foreign keys user capital ID, name them user underscore ID.

This difference doesn't matter. And in fact, if we just make a decision and go all in, look at what we get from the shared conventions around this. So that's what I'm excited to see. And what I would want to see folks experimenting with, just some leadership and from experience extracted from real code, here's how you set it up.

And you don't have to worry about which tools you pick and choose, because look how fast I can render a form that lets me create a post and it has validations showing up rich error messages in my UI. If you can let developers do that, they're not going to sit there and argue about ~Priszl versus ~Drizzle versus Prisma, 

~Go solve and ~go solve like real problems

exactly.

~Exactly.~

You can go over keys. Cool. I feel like that's as good of a wrapping point as any. Nice. Yeah. Thank you so much for coming on and chatting with me, Sam. Is there anything you'd implore listeners to ~just ~check out where people

Yeah. I think that the talks are still being prepared from react Miami. So [00:31:00] you can keep a lookout for that. And I'm also going to be speaking at react conf in two weeks ~in ~in Nevada. So that'll be more walking through some of these new APIs. And also there's a lot of cool stuff coming to react.

That is going to apply to all front end and backend react. So transitions and actions, optimistic. And deferred value use action state, basically actions and transitions are another big part of react 19. And they're going to work both in a server component app, but also for the many client apps, SPAs that are out there, they're going to bring a lot of benefits.

So I'm excited for those as well. So if you want to check out that talk in two weeks at react comp, that'll be something to look out for.

Nice. ~Cool. ~Again, thank you for coming on and chatting with me, Sam. We got totally off the rails here, but I always appreciate talking to people who are like passionate and into stuff. So yeah, it's been a pleasure

Absolutely, man. It was a blast.

for sure. For sure. Have a good one.

All right. Thanks.