Abracadabra: The Vanishing Network

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

The network that stands between our server and the client is what causes the most complexity in our development process. Whether it be the initial UI we generate on the server, the API calls we make as the user navigates around, or the form submissions our user makes, keeping the application responsive and up-to-date is a massive chore.

What would it be like if all of that complexity just disappeared? Freaking great, that's what it would be like. And React Server Components and Actions are what's making that possible. In this talk we'll look into how that's happening and how we can take advantage of this amazing developer experience to deliver even better user experiences.

This talk has been presented at React Summit US 2024, check out the latest edition of this React Conference.

FAQ

The shift from multi-page apps to single-page apps was driven by the desire to improve user experience by avoiding full-page refreshes and reducing template duplication between the server and client.

Pespa, or the progressively enhanced single-page app architecture, involves using frameworks like Remix to combine the benefits of server-side rendering with client-side enhancements for improved user experience.

The speaker recommends using Playwright for end-to-end testing and focuses on integration tests as part of their testing strategy, aligning with the testing trophy philosophy.

The trade-off involves dealing with some complexity from using compiler directives, but it simplifies the integration of server and client logic, potentially reducing network-related code.

The speaker prefers Remix because it aligns with their preferred methodology for building apps, offering a different approach to handling server-side rendering and client-side functionality.

The speaker suggests optimizing for change by making it easy to refactor and adapt code over time rather than over-abstracting logic into separate files.

Progressive enhancement is important for ensuring that applications work for users with varying levels of JavaScript support, enhancing the user experience while maintaining backward compatibility.

The speaker took two weeks to add a checkbox due to the complexity of managing network operations and dealing with a large, complex codebase rather than the UI itself, which was simple.

Modern React with server components improves the process by allowing developers to write server-only logic that can be referenced in client-side code without duplicating logic, thus reducing network code complexity.

Kent C. Dodds
Kent C. Dodds
32 min
19 Nov, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
I am so excited to share my software development experience. The talk focuses on React and the Vanishing Network, aiming to make network management disappear. It starts with the multi-page app paradigm and moves towards enhancing user experience and transitioning to single-page app architecture. The talk discusses eliminating duplication, transitioning to a JSON API, and utilizing React and user actions. It explores progressive enhancement with Remix, moving to modern React with server components, and enhancing server-client communication and UI. It also covers server-client code separation, Epic React version two, AI plugins, Next.js, trade-offs, testing, SQL queries, and optimizing for change.
Available in Español: Abracadabra: La Red Desaparecida

1. Introduction to React and the Vanishing Network

Short description:

I am so excited to be here and share my software development experience. I had an internship where I had to add a checkbox to an app. The code was complex, but the UI was easy. The job was tough due to network management. I want to make the network disappear and discuss it in this talk. It's based on a free workshop called React and the Vanishing Network.

I am so excited to be here, and I've got so much to share with you, so I'm thrilled that we don't have to do this. We just did that. So we're going to get right into story time.

When I was just getting into software development, I had an internship at a company called Domo, and we built an app that was a business intelligence app. This was BI before AI was too popular. And watch your eyes. This is the only bright slide that I have for you, but it's going to blind you. And now I can see you.

So this is the app, and I was asked as the intern to add a checkbox. It wasn't actually this checkbox because the UI looks completely different now than it did then, but we're going to imagine. I was asked to add that checkbox. Here's the code for that. It was a backbone model and view. We're going to look at this in detail. So that's our model. And then here's a bit from our view. No, just kidding. We're not going to look at that. And it actually isn't the code, either. That was ChatGBT. But it was a backbone stuff. It was a 1,000 line model, a 2,000 line base view, and a 1,000 line view that extended the base view. That's what I had to work with to add this checkbox. It took me all of, like, five minutes to add the UI for that.

But I want to know, just shout it out because I can't see if you raise your hands. How long do you think it took me to add this feature? Two sprints? A day? Two hours? Five months, OK. It took me two weeks. And I'm like the intern trying to prove myself, and I did. Yeah, I proved that I am incompetent, I guess. It was just so sad. Why do you think it took so long? Shout this out. Complexity. OK, so in general, complexity. Yeah, there was a lot of code. What specifically makes this job so complex? JavaScript. Yeah, you're not wrong. It's network management. The loading the data and doing the mutation. Adding the UI was like super fast. That was not hard. It's just an HTML template in my backbone view, but managing that network, man, that was tough. And that's what made it take two weeks. So I want to make the network completely vanish, completely disappear. And so that's why we're going to see what is happening to our network code in our applications.

The rest of my talk is based on a workshop that is completely free. You can go through the entire thing yourself. And that's what we're going to go through here. It's the React and the Vanishing Network. You can check this out later. We're going to be moving kind of quick through this.

2. Exploring the Multi-Page App Paradigm

Short description:

So we're starting with the multi-page app paradigm. We generate HTML, get a count from the database, and render it. We make a form to update the count, handle the route, convert form data, update the count, and redirect. There's minimal network code, but we moved on for better user experience. Clicking on the button causes a full page refresh, hindering quick increments for keyboard users.

So I checked it before, and you should be able to see that. If not, I am so sorry. I did my best. But yeah, we're going to start with the multi-page app paradigm where we all started. So we've got this simple app serving from the slash.

We're going to generate some HTML. So let's get a count from our database. We're going to render that count out here. And here, let's save that and make sure that we're in a good spot. Boom. Count zero. Magic. The web still works. Always bet on the web.

Now we're going to make a form so that we can update this. And so we're posting to update count. And then we have these buttons that can have a name and a value. Did you know that? That's a cool thing. So whichever one we click is what's going to be sent to the back end. So that's cool. Now if I try to click on one of those, it's not going to work because we're going to that route and we're not handling that route. So let's handle that route now. We're going to handle a post to update count. We've got our form data. We're going to convert that into a number because that goes over as a string. We're going to update the count, change it, buy that change, and then redirect because we're doing post redirect get. If you don't know what that means, then ask your elders. And we're going to decrement and increment. There we are. Awesome. It works. OK, so let's take a look at the network code. Where is the network code in here? Well, there's not actually a lot. But there is some. Some code related to the network. We've got this slash here. That's the URL. It's very much attached to the network. Our action is being defined here. So that's kind of network code too. Even our method that's related to the network. And then, of course, handling that and doing the redirect. All of that is sort of related to the network. Or pretty close. But there's really not a whole lot of network code in here. And this is why a lot of people who built apps using the multi-page app architecture really lament the way that we do things now because it really is that simple. But there's a reason we moved on from this. And the reason is user experience. So we want to have a much better user experience because right now what we're getting is a full page refresh every time we click on this. And so if I wanted to increment really quickly and I was a keyboard user, I'm going to tap, tap, increment, tap, tap, increment, tap, tap, increment.

3. Adding JavaScript for Client Functionality

Short description:

We're adding JavaScript on the client to preserve functionality. We bring in the UI index file and add an alert. We handle network code errors and ensure JavaScript loads. We add an event listener for DOM content loaded and an event handler for form submission, preventing full page refresh.

So I need to preserve that. And you could do some sort of autofocus and use maybe a cookie or something, which would, I guess, be fine. But I think it would be nicer to just have some JavaScript on the client that does this. But we want to preserve the current functionality because we're imagining we're in 2006 era where some clients maybe didn't have JavaScript on the client.

So let's start by adding some JavaScript on the client. First, I'm going to say script module and bring in our UI index file. So come over here, UI index, here we are. Let's do an alert, you done been hacked. I actually did this once and shipped it. And I was very embarrassed. So yeah, let's make sure that works. It's not. And the reason it's not working is because we have some more network code we need to handle. Right here, we're getting a 404. So we need to handle that. Now typically you're going to have a CDN for this stuff now. But back then, well, maybe not necessarily. There we go. You done been hacked. All right, very good. So now we've got JavaScript loading in the browser. We're going to add an event listener for the DOM content loaded event. So once we've loaded, now we know we can go get our form. And inside of here, we're going to add an event handler, form.addEventListener for the submit event. We'll prevent the default behavior, because the default is to do with that full page refresh. And we don't want that anymore. We're going to turn the form into some form data.

4. Adding Progressive Enhancement to the Form

Short description:

We manually handle adding the button clicked to the form data. Fetch the form action and method, and update count information. Preserve both HTML and JSON behaviors. Implement progressive enhancement by adding a pending state for the form.

But one thing that we're preventing with this default is this piece right here that takes whichever button you clicked and adds that to the form data. So we need to do that ourselves. So we're going to say if event.submitter, then we're going to append the event submitter. This is the button that was submitted. Submitter.name and submit its value. There we go. So this is us doing the browser's job. But there's a reason. We have to justify this for ourselves. And now we don't need to worry about the number change here. We're going to say fetch the form action, whatever that is configured to, and the form method. Because again, the form still does matter. We care about progressive enhancement. So it's got all of that information.

And then if the response is OK, then let's get the JSON of the response. We'll have our API return us an object that has the count. And then we can update the count information for that. And then we can have an error or something. And we'll take care of this piece in a second. Let's just come back here and add all of our IDs to handle this indirection. So we've got our ID for the count. We have the counter form. So we should be good, except we are still missing some of the progressive enhancement pieces in here. So when we are calling this update call, we're doing it with the fetch request. It's still form data, so that's all fine. But we're expecting it to return JSON in this case. But the browser, by default, it's not going to do the JSON stuff. And we need to preserve both behaviors. And so we're going to have to have some kind of condition here. First, we're going to need to get the updated count. And then if the accept header from the request includes text HTML, that means it's doing a full page refresh. We'll keep the old behavior. Otherwise, we're going to return the JSON. Great. Progressive enhancement for the win. Old stuff still should work. And new stuff indeed is working. And now, I've got focus management. That's nice. And to take it even further, now that we've got this, we can actually give a pending state to this stuff. So let's come over here to our form. We'll wrap these buttons in a div. And then come over here and grab those buttons. Counter buttons right there. And we'll set the opacity to 0.6, because I'm not a designer. And then we'll set that back to 1. But have you ever seen a pending UI that just never went away? Not in my code, you haven't. So we're going to add a try catch right in here. We actually don't care about the error right now, because we're going to pretend that this isn't real, because it's not. And then we'll move this to the final.

5. Enhancing User Experience and Transitioning to SPA

Short description:

Enhancing the user experience with localized pending UI. Increased complexity and maintenance with additional code. The problem of inconsistent behavior in updating the count. Transition from Pempa architecture to SPA architecture.

So even if there's an error of some kind, we're at least going to set the opacity back to 1. Sweet. So let's go over here to our network. We'll simulate a slow 4G connection and see, hey, look. Now I've got pending UI that is more localized to the part of the UI that is relevant to the user. We're not just looking at the favicon spinner. So we have actually enhanced the user experience, not just made it worse. But again, this talk isn't about that.

What did this do to our code? Well, it wrecked it. It kind of wrecked it. So now we've got some additional complexity in here to handle the JSON response. We have a lot of indirection here between our template and the JavaScript that hooks up to our template. We've got this event prevent default right here, which honestly we are not doing as well as the browser does to handle race conditions and errors and different things like that. But yeah, that is like, we need to do this. It's not like we're doing this for no reason. And then of course, we have to maintain all this nonsense, all this code. And then here's the real kicker.

A user comes around and says, hey, project manager, I need this to not be a colon. I want it to be an exclamation point. And so they tell you to do that. And you do it. And you're like, yeah, look. It is now an exclamation point. That's great. And so then you ship this to production. And the user comes and uses it. They're like, hey, I'm going to increment my count. Wait. It changed to a colon. What? What happened? Well, oh, right. I'm updating the count right here. So I have to update that in two places. And I still see apps that are built with this architecture that have this problem. And it drives me bonkers. Hate it. Hate it so much. So this is unfortunate.

And this was the primary reason that we went from what I'm calling the Pempa architecture, the progressively enhanced multi-page app, to the SPA architecture, single-page app. So let's come over to this next phase of software development I'm calling early React days. And actually, the backbone app that I worked on, that was SPA as well. We were pretty early days in that. So with the SPA world, we do things a little bit different. Now we say, hey, you know what? Instead of generating our HTML document from the server and having that duplication problem, we're not going to have a duplication problem. We're going to delete this. We're going to make this a count endpoint. And now it's just a JSON API. And instead we'll have all of that stuff in an index HTML on a CDN. Magic. Super great.

6. Eliminating Duplication and Transition to JSON API

Short description:

Eliminating duplication and progressive enhancement. Transitioning to a JSON API. Serving the public index HTML and handling 404s with a client-side router.

Super great. And now we don't have to worry about duplication, because it's all going to live inside of our components. So would you take a look at that? Amazing. This is so great. It's React, except I'm not using JSX. This is all pure vanilla JavaScript stuff. And so that's why we have this create element as h, and why we're going to be dealing with that in here. But we're not going to work in that too much, so don't worry about that.

So now we've gotten rid of all that duplication. We can get rid of, also, the progressive enhancement. We don't care about progressive enhancement. It doesn't matter anymore, right? So we're going to change this to a JSON API. We're going to call this our JSON body. And we'll take that change. We'll get rid of all this. Look at all this complexity. We're just totally deleting from our code base. That is great. And then, of course, we do need to serve the public index HTML, so we'll serve the public directory. Oh, yeah. And in this world, 404s don't exist. We just handle everything else and just serve the index HTML because we've got a client-side router. So yeah, 404s don't matter. Don't matter. We don't care about 404s. OK, great.

7. React Code and User Actions

Short description:

Switching on the action type. Using the use effect hook and dispatching fetch start. Update count function for user input. Handling initial loading state and improving user experience.

So now I'm in my beautiful React code, and I can switch on the action type. The fetch start, we're also going to have an update start because sometimes those are going to be a little different. Whoops, right here. And we'll have our, no, come on. There we go. Update success. I could not do this this fast without AI, by the way. Man, I couldn't actually code without AI. This entire time, I have not been a coder. It's only until we got AI that I finally started being able to code. Oh, it's amazing.

So here now, we're going to use our use effect. You've got to be really careful of those infinite loops of use effect. But we're going to be careful. It's fine. So we're going to dispatch a fetch start. Let's probably add this try a catch here. There we go. We'll get our response, response JSON. That's going to have a count on it. Perfect. Dispatch our error. We've got this fetch count, and then a co-worker comes to us and says, hey, you are not awaiting this. So I'm going to add an await here. Oh wait, what the heck? And so they're going to be all confused, right? So this is what you do. If you don't care about the promise resolution, you type void. And now the people looking at it are like, oh, they didn't miss the await. They just meant to not care about it. Pro tip.

Alright, sweet. So then we're going to come down here, have an update count function. So a function called update count. And it's going to look pretty similar to what we had. But this is what we're going to call whenever the user wants to update the count. So let's take a look. It's right down here. Update count minus one and one. Oh yeah, we deleted the form. Why do we have a form? I just have to do prevent default. No. I don't want to do that. Do not disturb just turned off. Oh great. We'll see how this goes. And so then we just have on clicks on the buttons. Why do I need anything else?

So then we'll say if the state is loading, so like we're initially loading the page. I don't have anything from the server, so we've got to show something to the user. Otherwise, they're just looking at a white screen. So that's not good. Maybe I would put that in my public index HTML, and eventually we figured out static site generation.

8. React Era and Pespa Architecture

Short description:

Rendering loading and error states. Troubleshooting API and white screen issues. Addressing the challenge of duplicating templates and logic in server-client architecture.

So it's a little bit better, more custom experience here. But if you have a really dynamic app, then there's not much you can do in that anyway. But we're just going to render loading right here. And if there's an error, then we'll render that out. OK, let's see if it works. Refresh, 404 not found. Ooh, I did not save this file. There we go. All right. Oh no. White space character. OK, let's make sure our API is right. We're turning JSON. We've got JSON. Come on over here. And we should be getting JSON in both of those. Uh-oh, that's not good. Well, it's a good thing that I can cheat and just go straight to the solution. There we go. Ha-ha. Oh shoot, and it's a white screen. Sorry. It'll be better in the next one. Great. OK, it's working. And I can go slow 3G on this. We've got our pending state. Everything is good. It's working the way that the user wanted it to work. Except the user, maybe they didn't notice. Maybe they don't care. I ask my wife sometimes, you didn't see all those things jumping around and everything? She's like, I don't know. I don't care. So maybe I care too much about this, but look at this. We got this loading nonsense. What? Before I didn't have that. Now I have to deal with that? I hate that. And then also, look at this nonsense and this nonsense. I didn't have to do that before. What gives? I'm not a fan of that. But I am a fan of not having to duplicate my templates, duplicate my logic from my server and my client. Oh, that's what it was. It was this headers. I forgot to add the application JSON. But there are things that we actually got as developers and indirectly as users by moving in this direction. So was it the right trade-off? I don't know. It was probably a good trade-off. But I think we can do better. And that is where we are currently at and kind of transitioning from is what I call the framework React era. And in the framework React era, we have what I'm literally the only person in the world who calls it the Pespa architecture.

9. Progressive Enhancement with Remix

Short description:

Progressively enhanced single page app architecture with Remix. Server-rendering with Remix framework and React router v7. Building a mini version of Remix. Loader, action, and counter components tied to routes. Accessing the database and using React Query for improved functionality.

It's the progressively enhanced single page app architecture. And this was spearheaded by Remix, the framework React router v7 now. It's very soon going to come out. And it's going to have all the awesome Remix features. You don't have to use it if you don't like server rendering. You don't have to. All those disclaimers. But it's really, really awesome.

So I built a mini version of Remix, my own version of Remix here. You can dive into this later if you're interested. But now, let me turn off this slow network here. Now things are quite a bit different. We have this loader and this action. And here's our counter component. This counter is relative to a route. So now everything is tied to these routes. And I can just say, hey, this route has a loader. And it's going to load. Whoops. Const. There we go. It's going to load the count. We're going to be able to access the database because this only runs on the server. So I can talk to third parties. I can have private keys. Whatever. Because this is on the server. That's nice. And then the framework, not me.

Oh, and I forgot to mention also React Query is awesome. And if you saw that useEffectSoup and that's in your code, you've got to get it out. You can use React Query right now. And it will solve that problem for you. But it still isn't quite as good as what we're getting to. So there is more that we can do. So we have this useLoaderData that's going to take this loader and it's going to give us our data. In Remix, you actually don't have to provide this. But in my mini framework, you do. And then we have our ability to perform fetch request. But let's make sure that we're actually getting the count instead of to do. So I'll save this. Refresh. Boom. OK, we're loading the count. That's our data loading. Now for mutation, we're going to do all these steps. Awesome. We're going to grab the form data. We're going to grab the change from that. We're going to update the count.

10. Moving to Modern React with Server Components

Short description:

Returning successful mutations, enhancing forms with pending UI, and reducing network-related stuff. Moving from the Pespa architecture to Modern React with React server components. Using async components for server-only code.

And we're going to return a successful mutation. And to call that, that's actually going to hit our counter. I actually didn't do this in my practice. But this should actually work. Increment, decrement, decrement, increment. And that's just a regular form. So we care about progressive enhancement now. But we want to progressively enhance. We want to have that pending UI and all that stuff. So we're going to change this to our fetcher form, which will render just a regular form so that it actually works out of the box by default, but then enhances it more so that we can have this pending UI. So that's nice. We can do that.

And now I get my focus date. We get our pending UI. Everything is really great. And if we were looking at the network code, there's not a lot, but it's still here. First of all, we have to acknowledge that this is all tied to the route. And so we have our route count right here. And that's how we get our data loaded and our action handled. We also have to specify the URL for our action. In Remix or in the web, if you don't specify that, it will just post the current action or to the current URL. So that's technically not there, but we're going to leave that in there. It's mostly gone. Most of our network-related stuff is gone. Our use state, our user reducer, all that stuff is gone. Things are much better.

And I thought that this was the end. I thought we'd made it. It's like a year ago, a year or two ago. I was like, yep, this is it. And then people were like, well, what if I've got a component that I reuse all over the place, like the Like button on X. How would I build something like that? It needs to manage its own data. It needs to manage its own mutation. What do I do about that? And I said, oh, well, you do this full stack component thing, and Remix has these resource routes. It's awesome. But it just wasn't good enough. How do I load that data? You've got to find the nearest loader, the nearest route. It's not a super great experience, and that is why we're moving on. We are moving from the Pespa architecture into what I call Modern React, Modern React with React server components. So let's take a look at this. First, to get the count from the database, I've got to restart the app now. This is going to have 404 not found. We're kind of messed up right now. We'll get to there. So first we're going to get the count from the database. Now, everything in this file is server only. This generates stuff that goes to the client, but the code itself does not. And so that means I can use async components. Maybe one day we'll get async components in the browser, and that'll be a beautiful day. But right now, it's only on the server, and I only want it on the server for this anyway.

11. Enhancing Server-Client Communication and UI

Short description:

Using server-side code to handle server-only functions. Creating a reference for server-side functions to be called by client-side JavaScript. Enhancing the pending UI for slow network connections. Adding code on the client-side using the use client file. Adding a script tag to the Pempa architecture to send code to the browser.

So I can get the count. And then check this out. I've got this update count function also only on the server, and look at where that's going. I'm just putting it in the action. But isn't this generating something that goes to the client? How can I send the action to the client if this is all generating some code and going? My update count is a server only thing. I need to access the database to change the count. I can't send this to the client. This has got private keys and stuff. Well, that's why we add this use server.

And what this allows us to do is it will create a reference for update count. And then that reference will go to the client. And then the client side JavaScript can say, hey, the user's trying to call this function. Could you call that on the server? And the server says, yeah, you can call that on the server. We can do that. So yeah, that's cool. Let's bring in the database, hit refresh, and maybe you need to restart. I think I probably messed something up, so let's just try that again. No, that's not good. Oh, hold on a second. We're a little bit too fast with the pending div. Oh, you know what? I'm in the wrong route. There we go. OK, super. So I can increment, decrement. Everything is going great, and there's not a whole lot of my code that made it to the browser. In fact, none of my code. It's all framework code that made it into the browser. So that's cool. And where's my network code? Here's my data loading. That's not network code. I'm just calling a function. Here's my mutation. Also, not any network code. I'm just calling a function. It disappeared. But wait, you say. Wait a second. We don't have the pending UI. So if I'm on a slow network connection, I'm not getting a nice pending UI here. No, we need to improve that. So the problem with that is that requires some code on the client. And so I'm going to have this file, use client. And it's saying, hey, I want to take this code and send it to the browser. And when we did that before, we had to add a script tag to our Pempa architecture so that we could get this code in the browser. And so let's keep a close eye. Watch where I add the script tag. And we're going to say use form status. We'll get the pending state. Yep, exactly. And come back over here.

12. Server-Client Code Separation and Epic React

Short description:

Moving server code to a separate file for client-side execution. Using use server and use client as network code. Writing an entire application with distributed front-end and back-end code. Introducing Epic React version two and its features.

We'll take that pending div because that code over there needs to go to the client so it's in a separate file. We're going to say pending div there. And then we'll refresh and increment. Hey, sweet. Wait a second. I didn't put a script tag anywhere. So I don't have that network code. This use client is my script tag. That's how that code got to the client. So wait, where's the network code? It's gone.

Maybe this use server and use client can be our network code. Maybe. I suppose some people really don't like these directives. I've grown to love them. But that's it. I can now write an entire application. Of course, there's network code. Like there's something in the browser that's making these fetch requests. Of course. But as a product engineer and even a library developer, maybe I'm building some auth platform or I'm building a payments platform, whatever. And I can create a component that does all of the front end, back end stuff, everything, distributed on NPM. And people can use it without having to integrate it in any funny way. That's huge. That is massive. I'm a big fan of this. Hallelujah.

Yeah, very cool. Very cool. All right. So, whoops. I didn't mean to click that. Sorry. Dark mode. That's better. But yeah, come take a look at Epic React. I just launched version two. It is phenomenal, really, really awesome experience. And you can dive in deeper to this demo and how I built all this stuff with vanilla JavaScript. Even RSCs, vanilla JavaScript. Take a look. Web workers are neat. With that, I just have one last thing to say. You're super. Thank you very much. Woo!

QnA

AI Plugins, Next.js, Trade-offs, and Testing

Short description:

Discussing AI plugins, opinions on Next.js, trade-offs with useClient and useServer methods, and testing with no seam between business data and UI layer.

OK. The most upvoted question is, which AI plugins are you using? Or is it cursor? That's cursor. Yeah. Yeah, it's awesome. I'm also very bullish on Windsurf. I think that they've got some cool stuff going on. And of course, Copilot. They're just like, they're a leap front. Whatever AI thing you're using right now, just probably stick with it. Because eventually, it's going to be as good as the rest. But I love cursor. It's fabulous. Nice.

Next question. You mentioned Remix a lot. What are your opinions on Next.js? Oh man, whoever asked this question probably read a blog post they wrote a while ago. I actually delisted that blog post. Too spicy. But I am not a super fan of Next.js, though I think that they are taking things in a better direction recently. I actually was at Next.js conf, and I've got a lot of friends in that community. But yeah, it's a different way to build apps. I prefer the Remix way. Nice.

Next question. I've come to believe there's always a trade-off. What do you think is with the useClient and useServer methods, what is the trade-off? There are no trade-offs. It's all positive. No, just kidding. I mean, the fact that I could build or implement RSCs with vanilla JavaScript is very encouraging to me. I worry a lot about compiler magic. That's just not the way that I like to build software. I prefer to have something that can be built just raw, and then enhance it with build tools and stuff later. But yeah, it is. There's definitely some complexity there that I think we're going to, you can't really know how it's going to impact things until it has already done that. So I think that the juice is worth the squeeze, but there is a squeeze. Sorry, this is jumping on me here. One sec.

How do you test this with no seam between the business data layer and the UI layer? That's a good question. First, talking about the seam between the business data layer and the UI layer, this may be a controversial take, but I kind of feel like that's an arbitrary line. I know some people are not going to like that, but I think when we're talking about separation of concerns, the concern is that user experience. We're talking about the Like button on X, or the reaction thing on GitHub, or whatever. That concern is the entire user experience. And so we learned that splitting up HTML and JavaScript wasn't as useful as we used to think it was, and putting them together was really useful with JSX. And I kind of feel the same way about business logic. Now, as far as the, and of course, over time you're going to need to share that core logic across lots of different UI pieces, and so yeah, you move it. You just move things around. That's our job as code movers. Eventually AI will take that job too. But I think as far as testing this, I've been using a lot more of Playwright for end-to-end test recently.

AI Testing, SQL Queries, and Optimizing for Change

Short description:

Discussing AI testing, mixing SQL queries and HTML styles, and optimizing for change.

Eventually AI will take that job too. But I think as far as testing this, I've been using a lot more of Playwright for end-to-end test recently. And I have the testing trophy where I say integration tests are where you want to spend most of your time, and a lot of my time is still there. But end-to-end testing has kind of been taking a lot more of my testing trophy. Nice.

Are we going back to the days when we mixed SQL queries and HTML styles? I thought the whole idea was separation of concern. We talked about this. I don't think that I will put SQL queries directly in my markup. I feel like that's maybe a little too much. But I mean maybe. Honestly, the problems that were there are different with the tools we have now. And so I'm a little less concerned about that. What you want to optimize for is change. And make it easy for you to make changes over time. This is actually one of my programming principles. I'm right now working on the Epic programming principles that'll come out in a couple weeks. And one of the programming principles is just to optimize for change. And it's very easy for you to just make a file, here are all my SQL queries, or here's all of my business logic over here, and then that becomes an over abstraction. And you're adding features to this that nobody over here needs. It just can become too easy. So I'm excited to see how things go when React makes it so easy to mix these things. Nice.

Cool. Well thank you so much, Kent. This has been amazing. Appreciate that. Thank you all. Thank you.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Simplifying Server Components
React Advanced 2023React Advanced 2023
27 min
Simplifying Server Components
Top Content
Watch video: Simplifying Server Components
React server components simplify server-side rendering and provide a mental model of components as pure functions. Using React as a library for server components allows for building a basic RSC server and connecting it to an SSR server. RSC responses are serialized virtual DOM that offload code from the client and handle interactivity. The client manifest maps serialized placeholders to real components on the client, enabling dynamic rendering. Server components combine the best of classic web development and progressive enhancement, offering the advantage of moving logic from the client to the server.
Exploring React Server Component Fundamentals
React Day Berlin 2023React Day Berlin 2023
21 min
Exploring React Server Component Fundamentals
Top Content
Watch video: Exploring React Server Component Fundamentals
This Talk introduces React Server Components (RSC) and explores their serialization process. It compares RSC to traditional server-side rendering (SSR) and explains how RSC handles promises and integrates client components. The Talk also discusses the RSC manifest and deserialization process. The speaker then introduces the Waku framework, which supports bundling, server, routing, and SSR. The future plans for Waku include integration with client state management libraries.
And Now You Understand React Server Components
React Summit 2024React Summit 2024
27 min
And Now You Understand React Server Components
Top Content
In this Talk, Kent C. Dodds introduces React Server Components (RSCs) and demonstrates how to build them from scratch. He explains the process of integrating RSCs with the UI, switching to RSC and streaming for improved performance, and the benefits of using RSCs with async components. Dodds also discusses enhancements with streaming and server context, client support and loaders, server component rendering and module resolution, handling UI updates and rendering, handling back buttons and caching, and concludes with further resources for diving deeper into the topic.
A Practical Guide for Migrating to Server Components
React Advanced 2023React Advanced 2023
28 min
A Practical Guide for Migrating to Server Components
Top Content
Watch video: A Practical Guide for Migrating to Server Components
React query version five is live and we'll be discussing the migration process to server components using Next.js and React Query. The process involves planning, preparing, and setting up server components, migrating pages, adding layouts, and moving components to the server. We'll also explore the benefits of server components such as reducing JavaScript shipping, enabling powerful caching, and leveraging the features of the app router. Additionally, we'll cover topics like handling authentication, rendering in server components, and the impact on server load and costs.
Server Components: The Epic Tale of Rendering UX
React Summit 2023React Summit 2023
26 min
Server Components: The Epic Tale of Rendering UX
Top Content
Watch video: Server Components: The Epic Tale of Rendering UX
This Talk introduces server components in React, which provide an intermediate format for rendering and offer advantages for both client-side and server-side rendering. Server components reduce bundle size on the client and improve search engine optimization. They abstract the rendering process, allowing for faster rendering and flexibility in choosing where to render components. While server components are still in the experimental stage, Next.js is a good starting point to try them out.
RSCs In Production: 1 Year Later
React Summit 2024React Summit 2024
24 min
RSCs In Production: 1 Year Later
This Talk explores the experience of shipping server components in production and highlights the benefits and challenges of using Server Components in Next.js apps. The Talk discusses the deployment of UploadThing and the use of AppRouter for safe production usage. It delves into the implementation of different layouts, data fetching, and code centralization for improved performance. The Talk also covers the use of server components for performance optimization and latency handling. Additionally, it explores the use of Edge and Lambda for partial pre-rendering and the challenges faced with webpack performance and hydration. Overall, the Talk emphasizes the benefits and challenges of working with Server Components in Next.js applications.

Workshops on related topic

Mastering React Server Components and Server Actions in React 19
React Summit US 2024React Summit US 2024
150 min
Mastering React Server Components and Server Actions in React 19
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Calling all React developers! Join us for an immersive 4-hour workshop diving deep into React Server Components and Server Actions. Discover how these game-changing technologies are revolutionizing web development and learn how to harness their full potential to build lightning-fast, efficient applications.

Explore the world of React Server Components, seamlessly blending server-side rendering with client-side interactivity for unmatched performance and user experience. Dive into React Server Actions to see how they combine client-side interactivity with server-side logic, making it easier to develop interactive applications without traditional API constraints.

Get hands-on experience with practical exercises, real-world examples, and expert guidance on implementing these technologies into your projects. Learn essential topics such as the differences between Server and Client Components, optimizing data fetching, passing data effectively, and maximizing performance with new React hooks like useActionState, useFormStatus and useOptimistic.

Whether you're new to React or a seasoned pro, this workshop will equip you with the knowledge and tools to elevate your web development skills. Stay ahead of the curve and master the cutting-edge technology of React 19. Don't miss out - sign up now and unleash the full power of React!
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
Workshop
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
The Gateway to Backend: A Frontend Developer's Guide to Full-Stack Development
React Summit US 2023React Summit US 2023
160 min
The Gateway to Backend: A Frontend Developer's Guide to Full-Stack Development
Top Content
WorkshopFree
Amy Dutton
Amy Dutton
This workshop will guide you through the product development life cycle of creating a real-world web application. You will learn about React Server Components, building a design system within Storybook, and using frontend development to approach becoming a full-stack developer. The workshop will cover increasing confidence in your application with unit tests and implementing authentication and authorization. You'll have the opportunity to work through product features and examine a real-world RedwoodJS project, gaining valuable experience in real-world product development. RedwoodJS makes it simple to approach full-stack development, and this workshop will give you the skills you need to create your own real-world web applications.
Advanced Application Deployment Patterns with React Server Components (feat. a DIY RSC Framework)
React Summit US 2023React Summit US 2023
104 min
Advanced Application Deployment Patterns with React Server Components (feat. a DIY RSC Framework)
Top Content
Workshop
 Greg Brimble
Greg Brimble
The developer ecosystem is always moving fast and this year has proved no exception. React Server Components can offer a significant improvement to developer experience and to application performance. But I think it's fair to say that this new server-first paradigm can be tricky to wrap your head around!In the first half of this workshop, we'll explore React Server Components from the ground-up: building our own mini meta-framework to help us understand how RSCs work. We'll discover exactly what is produced by an RSC build and we'll connect those pieces together to form a full application.Next, we'll deploy it! Cloudflare have also had a busy year too — Smart Placement, in particular, is a new technology that we've developed which fits the RSC model perfectly. We'll explore why that makes sense for our workshop app, and we'll actually deploy it onto the Cloudflare Developer Platform.Finally, we'll build out our app a little further, using D1 (our serverless SQL database) to really show off the React Server Component's power when combined with Smart Placement.You should come away from this workshop with a greater understanding of how React Server Components work (both behind-the-scenes and also how you as a developer can use them day-to-day), as well as insight into some of the new deployment patterns that are now possible after recent innovations in the platform space.
Building Reusable Server Components in NextJS
React Summit US 2023React Summit US 2023
88 min
Building Reusable Server Components in NextJS
Top Content
Workshop
Will Bishop
Mettin Parzinski
2 authors
React continues to evolve their beta capability, React Server Components, and they're continuing to further develop them in partnership with frameworks like NextJS.In this workshop, attendees will learn what React Server Components are, how to effectively build and use them in NextJS, and focus on one of the major advantages of React/NextJS: reusability through components.We will also cover related beta technologies enabled by the `app` directory, such as nested layouts and server actions (alpha/experimental capability).Join us for this hands-on, 120 minute workshop!Technologies:
React, JavaScript/Typescript, NextJS, Miro
React Server Components Unleashed: A Deep Dive into Next-Gen Web Development
React Day Berlin 2023React Day Berlin 2023
149 min
React Server Components Unleashed: A Deep Dive into Next-Gen Web Development
Workshop
Maurice de Beijer
Maurice de Beijer
Get ready to supercharge your web development skills with React Server Components! In this immersive, 3-hour workshop, we'll unlock the full potential of this revolutionary technology and explore how it's transforming the way developers build lightning-fast, efficient web applications.
Join us as we delve into the exciting world of React Server Components, which seamlessly blend server-side rendering with client-side interactivity for unparalleled performance and user experience. You'll gain hands-on experience through practical exercises, real-world examples, and expert guidance on how to harness the power of Server Components in your own projects.
Throughout the workshop, we'll cover essential topics, including:- Understanding the differences between Server and Client Components- Implementing Server Components to optimize data fetching and reduce JavaScript bundle size- Integrating Server and Client Components for a seamless user experience- Strategies for effectively passing data between components and managing state- Tips and best practices for maximizing the performance benefits of React Server Components