Abracadabra: 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!

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.

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.