Opt in Design – The New Era of React Frameworks

All right, hello, everyone. Hope you all are enjoying the conference. Sad I'm joining you all virtually for this one, but I have a great talk lined up, so I'm hoping that we can make up for it.

My name is Ben Holmes, and I'm going to be talking about opt-in design, which I am boldly dubbing a new era in web development, new trends that I've noticed. So to clarify what is opt-in design, it's not a UI design talk, although graphic design is clearly my passion. It's also not a systems design talk. We're not going to be talking about Kubernetes clusters or anything like that. It's an API design talk, so learning what good defaults mean when you're building a tool or you're using a framework of choice and both finding and building those tools so that we can build the best apps for our users.

So a little extended intro, I'm a core maintainer at Astro.build, so I've been working in open source for a bit and getting paid to do it, which is very rare to do. I'm also the chief whiteboard officer at Astro as well. Unofficial title, of course, but if you've ever seen some videos of a vertical whiteboard online, I do a lot of educational content, might've been me and you can find an archive right over there. And I'm a champion of content formats. So Markdown, MDX, Markdoc, if you've ever used any of those, I love them and I work on maintaining all of those in the Astro framework. So you might see me around the support forums.

So in order to walk you through the journey of building an app for the first time and introducing what opt-in design is, I'm going to talk about, you know, a classic example of how you might've built an app in 2015, 2016 era with create React app. That's where I got started with component systems might've been your learning journey as well. So when you start, you read that blog post from whomever and you're building your hello world for the first time. And you're reaching for tools like React and React dom. You're using a router like React router and you're reaching for some CSS and JS option like style components. So you can co-locate everything. It was pretty nice to use as a developer, but you can see our little, a kilobyte meter at the bottom is going to start ticking up. There's definitely a base cost to using these tools. Then you want to add in more features as your application develops a signup form. For example, in reaction, there's a lot of form libraries that you could use here. Maybe it was for mech back in the earlier days and you're going to be preventing the default behavior of the browser. So you can drive the whole thing with Java script, which of course means larger bundle But you stick with that dev experience that you were kind of told, or you're trying, is a good idea. And then it progresses a little bit further. Now we have a full e-commerce flow, and we want to add a cart bubble to say how many items are in your cart, like the number 2 or something like that. And you need to persist that in storage, maybe you're using Redux to duplicate server state inside of your client, so you don't have to deal with flashes as it's fetching things for the first time, and you're using client-side storage, maybe local storage or something like that. Again, we're going to take up our JavaScript meter a little bit further, because as we add new features, they all have to be replicated in the React bundle, in the React flow.

And then you get your performance audit when you've reached a certain state, and you wonder why you have a 39 on your Lighthouse score. And you were following the blog post. You were doing what the community said was a good idea. But that is the consequence of using a SPA. You're assuming all this reactivity, and you might have to walk things backwards and dig through the React dev tools in order to figure out how you can scrape up those Lighthouse metrics again. And that is the pain of an opt-out system.

So talking about opt-out, what does that really mean? Well, first off, looking at the Create React app library, framework, whatever you want to call it, it has a happy path where they manage a big old web config for you. And if you ever need to modify that or bundle your app in a different way, you need to opt-out, which is using the eject seat, literally just hitting a button and managing it all yourself. Which of course, is a very scary thing to do, which is why many people just stick with Create React app and whatever it gives you, and they avoid opting out of any of the opinions.

We also have style components, where the happy path is using JavaScript first to drive the experience. function in order to drive variables into your CSS, and you can opt-out of any of the client side JavaScript that shifts with your styles by using CSS variables or alternatives instead. And it kind of feels like you're going against the grain, you got to do extra work to get more performance, so it kind of hurts that you have to be knowledgeable about the concerns before you can address them. And opt-out panes of React context. This is the easiest one to understand, honestly, where you're storing state higher up, which is very convenient if you're storing the cart at the top of your application so everyone knows how many items are in the cart. But it's going to be very expensive if that cart ever changes, because as you know, anywhere down the React tree that relies on that state is going to re-render, so you need to opt-out with usememo across anywhere in the app that has intense calculations, which isn't a very fun experience. That, again, is performance auditing. It's not the happy path. We can sum that up into an opt-out ethos. You assume a goal, which is a highly interactive app, and you lower the developer friction to get there, but you need to bundle the best toolbox up front in order to get them there, hiding complexity, and then asking developers to deal with the complexity monster later once they do that performance audit and have to figure out what they could do differently. I want to flip that mindset with the more modern frameworks that we have today. ASTRO is, of course, my favorite example, unbiased opinion as an employee. It's a great way to do opt-in design. We'll start with our Hello World again. In this case, you don't have to cobble together a bunch of tools. You can use ASTRO and static templating in order to just write the Hello World and display it to the user. Zero kilobytes of JavaScript. You're just using HTML and CSS to get there. Then we add that complexity, the signup form, but we can be a little bit smarter about how we do it. Now that it's a static app or maybe a server-driven app, you could use a plain old POST request to an endpoint. Maybe prevent default.

Maybe don't. It's up to you. You could use a lightweight library like Zod in order to validate on the client and get that nice experience where you're typing out an invalid email. Then you make it valid again and it instantly gives you that feedback that you're good. You still want that in your JavaScript bundle. Nobody don't need React to get there. We only take up our JavaScript a little bit, but we still get the same experience.

Then you want to add your cart bubble again. How many items are in the cart? Maybe you want to do this in a client-driven way with client state. You can opt-in to using a client-side framework with Astro. It's a CLI option, Astro add React, that will install the dependencies and bundle React into whatever pages need it. It'll avoid React on pages that don't. Then you can use a lighter weight option, like nanostores, to store that global state. You don't have to deal with as many re-rendering concerns. That will bump up the client-side JS just to the level of React and React-DOM, but it's not adding anything unnecessary on top of it. You chose that path, and you're able to reach for a tool like the Astro CLI to get you there.

We have an alternative to that. If you wanted to make it a server-driven experience, you could opt in to server rendering instead. Astro has a number of adapters for this. Astro add node would configure your app to be a node server, endpoint by endpoint. You can choose which pages are pre-rendered, and then maybe use session storage and middleware to keep track of the user. That takes the client JS back down, and gives you roughly the same experience with some more server state to manage. Now, when you get to the performance audit, you remember why HTML runs on 3 billion devices. I'm joking here, it's poking fun at Java. But yeah, starting with HTML and progressing from there is a better idea than starting from JavaScript and working your way back to server rendering. It's just nice to start with the server, because that's what's going to compute things a little bit faster and avoid client-side stuff. So now let's sum this up into some opt-in design principles. First, you want to find the lowest common denominator of your tool. You also want to make complexity easy to add, only when intended. And you want to stay user-first with the API design, not developer-first.

These are three principles that guided how Astro was built, and I'm gonna dig into each of these in depth. So the first one, find the lowest common denominator. What's the simplest use case for the tool that you're using? For a Create React app, the simplest one is ship some HTML without any state, that's a hello world. You want to be smart and not have a car with opt-in wheels, for example. You don't want a framework that doesn't help you do anything at all, and you have to add a plugin to render HTML. But as long as you understand what the smallest use case is for your target audience, you can get there.

Also, you want to make complexity easy to add, only when intended. Don't start with a kitchen sink like a Create React app that you have to eject out of. Instead, you want to add really simple switches to opt into things that are more complex, like Astro's CLI, to add React when you want to add interactivity. Lastly, you want to stay user-first as you're building a tool, or you want to choose tools that are user-first. Developer experience does matter, but it needs to be guided by what the user experience is once it ships. So you want the low-complexity baseline for the base of the experience, the LCD, and an is opting into re-renders, which means fewer CPU cycles, better performance. And performance isn't the only user metric you can talk about. You can also measure the security of an application, for example. And I have a little Deno flag to show you there. So whole world of examples that I can reach for here to explain it. Deno, as I mentioned, it brings opt-in to permissions. Whenever you're running a CLI task, it may need to reach out into the world and access things on your system. And it shouldn't be able to do that willy-nilly. You should be able to say, I want to allow network access. I want to let you read from my file system. I want to let you access my environment variables. But without these flags, you're not allowed to do that. It's crazy when you log process dot env and node, and you realize just how much it has access to. It would be nice if we can make that opt-in instead. So how does this address our three principles? Well, first off, this is the lowest common denominator. The simplest thing you can build with DNO is just a CLI tool, maybe a text adventure game, without any IO. And then you can add complexity with simple flags that describe what's added. So no foot guns here. And it is user-first.

You know, we're caring about security vulnerabilities, opt-in, whenever security needs to be addressed. And the user understands what is being allowed. And also we can talk about server components.

You know, it's a hotness in React. Also in Astro. It brings opt-in to client-side JS, which of course is not a root evil or anything. It's just something that you want to be mindful about and only reach for when you need it.

So in this example, I have an Astro template. Static HTML is the default. And if you want to reach for client-side interactivity, you can import a component built in any framework, including React, maybe solid, maybe view, maybe Svelte. And you can opt-in to client-side JavaScript using a client directive. This is saying load JavaScript when the component's visible on the page. And again, lowest common denominator, static home page, nice default to have. Added complexity. Yes, the client directive is how you opt-in to client-side JavaScript, with granular control for when the JavaScript is loaded, like when it's visible. And this of course is user first. We care about those core web vitals. We know HTML is a good starting point. That's where we're going to start you when you're building your app as well. And it also brings opt-in to streaming.

So React server components are a little spicier, they have more going on for server rendering your application. You notice in this example, we'll have a live code demo to dig into this a little bit more. But you know, it starts with static HTML, like our Astro example, and it also allows you to stream information from a server without much client-side JavaScript to render it on the page. So in this example, maybe we have an Albums component. This Albums component fetches from a database, grabs some albums, and displays them to the user. But maybe it relies on a third-party API that takes time. You know, we can't speed up this third-party client, it takes a second to load, but we still want to show the user something. So it's not just a spinner in their browser for one to two seconds that they can't control. So we load up our Albums component, call that third-party API, and we use React Suspense to show a placeholder and stream in the information when it's available. And we're not doing this with client-side loading spinners and if else's, we're letting React handle it and Next.js is the framework on top that's able to manage it for us.

So yeah, this assumes the lowest denominator, which is, again, server rendering everything without spinners, so our heading is not gonna be inside of the spinner, we can just ship that straightaway. And it's additive complexity. Of course, streaming is more complex than not streaming. So the default is don't stream it, just block and wait for all the server stuff to be done. And if you want to opt in to spinners, which can have layout shift, understand the risk, you can add a suspense boundary to say what fallback you want to show while that server's resolving. And of course, that is user first, we care about the layout shift, we want to avoid that as much as we can. But when it's necessary, when we can't control it, let's reach for suspense. Let's try to give you some feedback straight away, it just feels a bit snappier.

So I obviously can't do this in person. So I can't see your hands. But I'm assuming this has happened to you at some point in your react journey, where you call on use effects, you forget your dependency array. And things happen. You don't need a performance audit to know that there's probably something wrong going on here. And that's because of reacts reactivity model.

So I'm gonna breeze through this pretty quickly. Let's compare react and solid here. So solid is a declarative JavaScript framework fast UIs, maximum control over reactivity. It's a new hotness. It's from fireship, the second best YouTuber that quoted this second best because I'm on the platform. Okay?

So let me show you an example of how we can bring opt in to the component level, which you may not have seen before I have two components here, one built in, react, and one built in solid, you'll notice that at first glance. They look almost the same, but there is one subtle difference that I've highlighted right here. So we're building a shopping cart, right? We have our quantity, which is how many things are in the cart. We have our price, which is based on how many things are there. And then we have some unrelated server side fetches to resolve. Like getting the product images and getting the shipping text. So a few things going on that all display info about the product. And we can write this with JSX as you would expect. But the one interesting part is this dependency that we're drawing here. Price depends on quantity, so it needs to recompute anytime quantity changes. And if we pull up how these are written, React and Solid, I have working demos right here. You can see when you click on the React example it's going to update the price every time quantity updates. But it's also going to rerun product images and shipping text because you need to care about useEffect and useMemo and all these other things to prevent other stuff from recalculating behind the scenes which you might need to reach for developer tools to even figure out is going on. I made it really obvious here, but it might not be so obvious in your app. So React assumed you want everything to re-render. That's the simplest mental model, so they went with this approach here. Which it can be a little scary. It's a little foot gunny. Now Solid takes the opposite approach.

Instead of re-running the whole component any time state changes, it's just going to re-run the part of the page that cares about that state. It's just going to re-render the quantity every time quantity updates. And it won't update product images and shipping text, yay, but it won't even update price. You have to be very specific about what parts of the page re-render.

So in Solid, for example, if you want to declare dependencies, like price depends on quantity, you can just create an execution function. And, the Solid Compiler is smart enough to say, alright, this is a function now, I'm going to trace the dependencies inside of this function, quantity, and I'm going to re-run that function any time one of those dependencies changes. So not even a dependency array, so it's just smart. Now that we've made this function, we can see that Solid will update price. But unlike the React problem, we're not going to reload anything else that doesn't depend on quantity, because again, you opt into reactivity with functions. So that's how the whole framework works, and it's a really nice primitive. And, we'll see this in modern examples like Svelte, and Vue, and Angular, they all are based on this model of where the initial state is going to be run once, and then we only rerun wherever state is used. So we rerun the JSX element right here instead of rerunning your function top to bottom as you would in React. Cool little trick, cool little mental model.

And Svelte does the same thing. Using the dollar sign operator, and this is changing in future versions, apparently to a state operator, that will rerun price whenever quantity changes. Same sort of flag to say, hey compiler, look at the dependencies, re-render this stuff whenever those dependencies change. They all kind of work like this, and we're converging on a model of signals in order to manage this.

So, lastly I'll leave you with a little demo, looks like I have about two minutes, but I'll you know, speed run this, see what we can get to. It's on a repo called simple-rsc. So if after the talk, you want to try out this tool, even contribute improvements to it, I definitely welcome it. But it's a basic benchmark that shows you how React Server Components work outside of Next.js. So you can understand the mental model of Server Components, what they really do. So, I have that code pulled up right here, we're going to zoom in for you all just a little bit. And we can see we have our server root, this is just a page that's rendering, don't worry too much about that. And we're just rendering the static text, abramix. I built this with Dan Abramov on Stream. It's a Spotify clone, so Abramov, Abramix. I thought it was funny, okay? I thought it was funny. But yeah. It's just rendering this static text right here.

And if we pop over to our browser, which I'll go ahead and do right here, we can see our static text rendering to the page. And also a dev panel that shows you what information is being sent over to Wire to show this. So in React, these are very truncated server messages that tell React, construct an H1 with the child abramix. And we're not shipping a component to the client to do this, we're literally just streaming in HTML as soon as it's available.

And you can even server render that up front, so you don't have to wait for the server stream to come down. And we can get a little bit more complex if we want to by doing some server side fetching and seeing what that gives us. So I have an album component here that fetches from a dummy database and it renders a little search box with client-side JavaScript to search for albums in that list to re-fetch everything from the server. So I'm just gonna pass down this query here, don't worry too much about that. But we're just rendering an albums component to the page that's gonna do all of our server fetching and if we head back, oh that's the actual Spotify, if we head back to our browser we can see all of that coming into view.

So you can see it is blocking. We're now waiting a solid second for the database to load and for everything to be available because that's the default in React. Just block on everything so that there's no layout shift and we can show you that information. And it'll stream in just the info about the albums that we need on the page. This is kind of why it's like a modern GraphQL if you really think about it, where you don't have to be smart about what data you're codifying as JSON. It's just going to send down HTML. So as long as you're smart about fetching from a database, rendering what you need, you don't have to worry about sending stuff you don't. It's going to stream exactly what's necessary for the page. And if we decide, you know what, that one second wait is a bit long, I don't really want to wait for that, we can add a suspense boundary in here to unblock our heading. To show the heading straight away, and then show a little placeholder while the albums are loading into view. So we can see that, and I'll refresh a few times to show you what's going on. We can see Abramix streams from the server straight away. Then we show our loading spinner while the database loads, and then the server streams in the rest of the information a bit later. And React is smart enough to resolve that onto the page based on how you structure your component tree. Cool, little trick. Definitely excited about the future of React, and just making everything driven by the server, but keeping it in JSX. It's something Astro's been doing for a while, and I think React is codifying it in a really nice way. All right, so that's what I wanted to leave you with. Check out the demo if you want. And if you want to, you know, show your support to Astro and other opt-in frameworks, you can join the Astro Discord, astro.build slash chat, and you can find me everywhere at bhomestev if you enjoy my teaching style for some reason. All right.