Living on the Edge

Rate this content
Bookmark

React 18 introduces new APIs for rendering applications asynchronously on the server, enabling a simpler model for architecting and shipping user interfaces. When deployed on edge networking platforms like Cloudflare Workers, we can get dramatic performance and user experience improvements in our applications. In this talk, Sunil will demo and walk through this new model of writing React applications, with some insight into the implications for data fetching, styling, and overall direction of the React ecosystem.

36 min
22 Oct, 2021

Video Summary and Transcription

The Talk discusses the future of React and introduces new APIs, including streaming rendering and server components. React Suspense allows for asynchronous loading of components and data fetching. The use of serverless computing, specifically Cloudflare Workers, is explored as a way to improve performance. The Talk emphasizes the potential for simplifying the React ecosystem and the excitement about the new API.

1. Introduction and Personal Story

Short description:

I look forward to disappointing everybody here. It has been two years since I have been up on the stage. I've missed you all so much. I finished 500 days smoke-free. I quit smoking. This has been my GitHub avatar for the last 10 years. It doesn't really represent me anymore. A friend of mine did suggest a minor modification and I will be uploading it later today. This was actually made by Siddharth Kshetrapal. He's not here today because his visa got screwed. But I think that's a good modification. And that's my story so far.

I look forward to disappointing everybody here. It has been a while. It has been two years since I have been up on the stage. My name is Sunil Pai, I work at Cloudflare on the workers team. I used to be on the React team. They got rid of me pretty quickly.

And we have React stuff to talk about, but before I do that, I do want to start by saying I've missed you all so much. This is so weird. I met a bunch of people at the speaker's dinner yesterday. It's nice swapping stories, doing the same awkward hugs. There's the bro hug, there's the 200 hug, there's the fist bump, there's the weird elbow thing and I think it's time to retire that. But things have changed for me. As you can see, I get way better haircuts now. I dress a little nicer and especially for the occasion, shout out to Tom Dale. I hope I'm doing you proud. I've been eating better, exercising better, but the thing that I am most proud of and I'm sharing it with all my personal friends here is two days ago, I finished 500 days smoke-free. I quit smoking. Which is a good thing. So happy. I'm very proud of it. This is the thing that I've been telling everyone. It does leave me with one complication. This has been my GitHub avatar for the last 10 years. Ever since I've had one. It's cool. I used Photoshop back in the day when I had a pirated copy. But it doesn't really represent me anymore. But a friend of mine did suggest a minor modification and I will be uploading it later today. I think it's pretty good. This was actually made by Siddharth Kshetrapal. He's not here today because his visa got screwed. It sucks, but look forward to his talk. But I think that's a good modification. And that's my story so far. Cool.

2. Introduction to the Talk

Short description:

This talk is about the future of React and introduces some new APIs. It's in beta and will be improved over the next year. It's an important release that is often overlooked in favor of other features. It will have a significant impact on our future development.

Let's get to the talk. Three things you should know about the talk I'm doing right now. It's kind of boring. We'll be talking about a couple of APIs, but if all goes well, you probably won't have to use it. Things will just happen. And that's nice. That's kind of a nice thing about React. Like all the improvements are slightly incremental. Nobody has to do any massive rewrites. You can leave old code as it is. This talk is a beta talk. Much like the actual APIs and the fact that React 18 is on the horizon, but there's going to be about a year, two years of experimentation usually when these things come out. Much like that, this talk itself is also in beta. This is the first time that I've put it together, what we're talking about, and it also means that maybe over the next year, I'll be improving the talk. So if you spot any mistakes, sorry about that, but it will get better. But this talk itself is in beta. The talk is also about the future. I don't usually do API talks, I like talking about the work I've done, but this, I think, is exciting enough that it's part of the React release that no one is really noticing. Everyone is talking about the cool hotness, which is server components and concurrent and all that, but I feel like this actually is way more defining for all the things we're going to be doing in the future. So those are the three things.

3. How the Internet Works

Short description:

Let's jump straight into it. How does the Internet work? I'm going to be talking about it as a conversation between a browser and the actual website. This is an Internet Explorer. It's talking to UGLE.com. You ask it a question. What can you tell me about the Amazon rain forest? The search engine goes back to its services and gathers information from various teams. There's a photos team, a flight service, news about the rain forest, and even a video service. The search engine presents the information along with some ads. This is how it works. You start a conversation with a server and it presents the data in HTML as a website.

Let's jump straight into it. Standard interview question for all web developers, right? How does the Internet work? When they ask you that question, really the question is, hey, let's say you type in ReactAdvanced.com into your browser. What happens? And there are a number of ways to talk about it. You can go into it in a lot of detail, you can talk about it at a broader level. I'm going to be talking about it as a conversation between a browser and the actual website.

Let's dive into it. This is an Internet Explorer. So the E stands for Internet, a classic. That's the only browser I've known. And it's talking to UGLE.com. Convenient that they're both an E, I think. And you ask it a question. What can you tell me about the Amazon rain forest? You type in Amazon rain forest in search. And search engine says OK, hold up. I got you. I'll let you know. And it goes back to its services, and it says hey, team, all y'all, what do we have for pi that we can tell him about the Amazon rain forest? So maybe there's a photos team that says OK, here are all these photos I have about the Amazon rain forest. Take this. The search engine is like, OK, cool. That's fine. That works. There's a flight service. Imagine that, a search engine giving you flight tickets. I think that would be a killer service. Nobody else is doing it, of course. And it says hey, maybe pi would like to fly to the Amazon rain forest this weekend. Here are tickets. Of course, I think it starts in December. It's going to be a little while away, but here are tickets further. There's news about the Amazon rain forest, because it's not in a great state right now. It's being burned to the ground and being raised. And there's news about it if you want to read it and get more depressed about the state of the world. But, of course, there's a little video service as well. And it says, hey, here are some videos. If you would like a seven-hour stream of just lush greenery, we got that, too. Awesome. So then the search engine comes back and says, okay, I got stuff for you. Here it is. Let me present it to you. I forgot. I forgot there are going to be eight ads before you get to any of the content. It says, okay, fine. Here are a bunch of ads. Possibly from another site that sounds like the Amazon rain forest. And here's a bunch of content. Not bad. So this is how it works. You start a conversation with a server. It gets a bunch of data. Presents it in HTML as a website.

4. Implementing in React and the Idea of Streaming

Short description:

If we had to implement this in React as a React component, it would involve making an app component with a header, a footer, and five components for ads, images, videos, news, and flights. However, there are tradeoffs with this model. Requests for data cannot be co-located with the component that asks for it, especially on the server. This leads to hacks and the need for separate frameworks. We can do better. Let's talk about the idea of streaming, where data can be sent down as soon as it's ready, even before everything else.

So if we had to implement this in React as a React component, what would it look like? Well, you make a component. Let's call it an app component. You can see the code. It's fine. You can see the slides later. You'll make an app component. Which has a header, a footer, and you'll write five components for your ads, images, videos, news, flights, which takes a bunch of data and renders it. You'll pass it into something. So you'll fetch the data before you render the component. You're like, hey, give me all the ads for Amazon rainforest, give me the images and videos. Get all of it, and then render to string. This is what happens on the server. Usually a metaframework like an ExJS takes care of this, but you say get the data and render it into it. Sure? Okay. This is how it works. It's not great. There are some tradeoffs with this model that you might have noticed. One is that you can't really co-locate the requests, say, get data with the actual component that asks for it, particularly on the server. You could probably do this on the client side, but on the server, because it's a one shot thing, you can't put them together, you've got to get all the data first and render it, or you have to do, like, other stuff. It blocks the whole page on the data. Can you imagine, like, you won't be able to see any of the photos until all the videos have also been fetched, or if one of them is slower, the other ones are blocked. It needs to get all the data before it actually renders it done. Which is why you end up doing hacks, right? Like, it's great, there's a whole ecosystem of frameworks out there that your ExJS or and fetching libraries like Apollo and Relay and a whole bunch of GraphQL stuff. But let's admit to ourselves, like, it is kind of hacky that you have to build something separate that's not inside React itself to do these things. In the beginning, it was fine because it involved experimentation, but now you have to stitch up a whole thing and use a meta framework to do it. It's just a little ew. Like, it's not perfect. Right? Like, you feel a little uncomfortable with the situation. You always have to make trade-offs. Do you do all your compilation when you build the page? What if it's a site with a hundred thousand pages? Do you have to do it dynamically? It's kind of weird. But this is the state in 2021. It's kind of fine. I mean, many multi-million dollar startups and companies have been made around this API and other things, of course. Of course, it's the website that got you the money. I don't think we should be fine with this. We can do better. This is a community that is built on experimentation and innovation. So let's take a little bit of a... Let's keep that aside for a minute and talk about a feature that the internet has. It's an idea called streaming. The idea is that you should be able to send data down as soon as it's ready, even before you have everything else. I don't want to get into too many technical details about it. you can Google chunk transfer encoding for HTTP 1.1 and there's something else for HTTP 2. There's a whole bunch of specs. I'll try to explain it as simply as I can. So let's take the same website and turn it on the side. Imagine coming from that side to that side. No. Yeah. That side to that side.

5. Streaming and React

Short description:

In the streaming method, data is sent out in bits as soon as they become available, improving the user experience. This approach allows for non-blocking loading, where the header, ads, photos, flights, news, videos, and footer are loaded progressively. While streaming is not currently possible in React, it is a concept that can greatly enhance user experience.

Right? In your one shot method, you would send it all in one go, but in the streaming method, you would stretch it out like chewing gum and send out the bits as soon as they come. You would be able to send a header immediately, then the ads as soon as they're ready, and then the photos, flights, news, videos, and then finally the footer. What would it look like as a user when you start loading the site? You would start off with the header, wait a bit, and then the ads pop in, wait a little more, and photos pop in and the flights and news and the videos and then the footer. That's better. At the very least, you're not blocking, like, just the header being loaded, waiting for stuff like content to load, which is fine. And to be fair, I think Google actually does do streaming. But we can't really do this in React land so far, of course, because it's still a one shot. We can do better. Anyone who knows me knows that this is my mantra. The nice thing about being a UX engineer is that there's no upper boundary on how good you can make user experience, right? You can just keep making it better and better. Anyway. So that was streaming. So let's keep that idea to the side. This is a React conference, after all.

6. React Suspense and Loading Order

Short description:

A couple of years ago, React introduced an experimental feature called suspense. It allows for asynchronous loading of components and data fetching. However, it had limitations with rendering to string and server rendering. To overcome this, you can wrap components in a suspense component and provide a fallback, such as a spinner. By marking each component with a suspense boundary, you can control the loading experience. One component that can enhance the loading order is suspense list.

A couple of years ago, there was an experimental feature that was launched at React Conf 2019. Holy shit, that's two years ago. That's a while. Anyway. They announced a feature called suspense. You can mark components as React.lazy and it would load it asynchronously and use suspense to mark a spinner. There's also data fetching. The problem is that never really worked with rendering to string and server rendering. Some people use it for client-side apps, and it's nice. It's a good model. So we'll just quickly dive into it and see what it looks like.

In this model, for the same page flow that we just discussed, you would have, let's say, an ads component that fetches some data inside it and then renders that data. A quick thing to note is that there's a bit of a glitch in the matrix. Notice that there's no await statement, and the way React does this is kind of funky. If you're interested in diving into the details, it throws a promise. It doesn't matter to a developer as you're using it. You just write it like a synchronous code, and you can use it. By the way, I've been using GitHub co-pilot, and I did this and after this, I wrote function all the code for me. You all have been using it? It's kind of scary. It's AI for your code. It fills in your code. Anyway, so you would also have an images component that just takes the search term, figures out what images are there for it, and like spits out the HTML that, well, the DOM tree that would work for it. Similarly for videos and for the ads and so on. And then what you would do is you would revisit your app component and you would wrap all of this with a suspense component and you would give it a fallback. Say a spinner. And the nice thing about the experience for this, when it's a client side app, is that you will have a spinner that waits for all the data to load and then finally renders it. So the experience would be, hey, you would render a header and a footer and a big spinny spinner in the middle. I should choose a better one. It's fine for now. I'll ship it. So it waits for it. Waits for the data and as soon as that's done, it renders the content. That's not bad. But we can do even better. That's the mantra for today, right? Let's say that you can also mark each of the components with a suspense boundary. And let's say for the sake of discussion, each of them have the same spinner. You wrap all of them up. And then the loading experience for it is, hey, it starts off with five spinners. Maybe the flights load first. Not bad. Then after that, maybe the ads load. Then maybe close to each other, the news and the videos load. And then right after that, the photos load. That's not bad, too. At least it doesn't wait for everything. As content comes in, it renders. Still not great. You want to load it at least in order, even if the data resolves. We can do better. One of my favorite components, a component called suspense list.

7. Streaming Rendering with React

Short description:

Now you can group together suspense components and specify the order in which they should load. This improves the user experience by loading content in a desired sequence. However, this approach leads to a fully client-side rendered app, which has tradeoffs in terms of HTML generation and load performance. To address this, React introduces an API called render to readable stream, allowing for streaming rendering with React.

Now, mark that out with the green. You can see the code later. But you can actually group together suspense components. And you can say, hey, reveal these as in a forward order. You can also make it backwards. You can make it all together. It's a lot of fun. Feel free to try it out.

Anyway, you can say, hey, make sure that the ads load first. At least they render first, even if the data for the others loads later. Just so we're clear, the data for all of them is happening at the same time. Make sure the first one is rendered. And then I group the other four and set another suspense list. Nested suspense list. That's cool. And say that I want those forwards as well. Okay. So what does the experience for that look like? Again, we start off with about five spinners. There might be data so the ads load in. Some content might have actually loaded for the others, but we have marked that it needs to load in this order. The photos load. And the next one loads really quickly, so your flights and news and the videos load. That's a much better user experience.

But the problem of course here is that this is now a fully client-side rendered app, right? So we have these two tradeoffs. One, we can either generate all the HTML on the server side but you have this janky programming model and you have to make sure you have hacks or a whole bunch of optimizations. That doesn't really gel well with the React model. Or you can do it completely client-side and have ostensibly a better user experience once all the JavaScript loads but load performance is worse. It takes a long time for the JavaScript to load and then the requests have to go from the browser. So you got to do one or the other. Right? The mantra. We can do better.

So this is the one API that I've been talking about. It takes render to string, which we've been using for the last five years and it's been fine. And it replaces it with render to readable stream. So we can now do streaming rendering with React. I just want to recap how good this is. All right? So let's just recap. So we're gonna look at the same thing we looked at right before this. Traditional streaming looks like this. It stretches it out like chewing gum or a rubber band, I guess, whatever. And starts loading things one after the other. So the header would load. Then the ads would load. Photos. And like all these blank spaces. Which is fine. But it's loading. Right? And videos and the footer. So this is what we could get if we had used traditional streaming. Which we can't, just so we're clear.

8. Server Components and Improved User Experience

Short description:

You can have a superior user experience without JavaScript on your page. It sends that shell ahead and starts sneaking in little hidden divs with the content inside it. The spinners work without the JavaScript bundle on the page and in an order that you can decide. The new server features, once you replace render to string with render to readable stream, suspense just works. React.lazy, all that. You get to do loading patterns without your JavaScript bundle on the page. The spinners work without the JavaScript bundle on the page and in an order that you can decide.

And possibly how Google already does it. But with render to readable stream. You can start off with the spinners. Wait a little bit. The ads load. The photos. The flights. The news. The videos. And here's the kicker. That entire experience happens before any of your JavaScript loads. This entire experience is happening down the HTML. You can have a superior user experience without JavaScript on your page.

So how does it actually do this? It's kind of cool. I have one slide to show you this, but really you should dive into it after this talk. So what it does is it sends that shell ahead. And it knows that because that's the component model that we've done. But as soon as the page is over, it starts sneaking in little hidden divs with the content inside it. It's not fancy as it is. It's quite a hack. And as soon as each of these bits load in, it's like one line of JavaScript. One function call that just says, hey, take this div and replace the spinner with this content. There's no React on the page, nothing. You can even remove it and you still get the same experience. So that's pretty dope, I think. And this is pretty fundamental to the rest of the React. So... Innovation that we'll probably see over the next year. Server components, the new hotness built on this tech. Any ideas that you have for new CSS and JS libraries, because it's been a while since we've had a new one. Might as well make 12 more over the next year. You might want to make sure that it works well with the streaming rendering model. You could... Data fetching now becomes way more interesting, right? Now, instead of, like, the hydration step being one blob of data that you just inject in there, and you can do it piece by piece if you want. Lots of fun stuff.

Anyway, so just to recap. So the new server features that we have, once you replace render to string with just one line, which is render to readable stream, suspense just works. This is a huge deal. It's not worked for the last two years, which is why a lot of people haven't even used it in React apps, but now, it just works. React.lazy, all that. You get to do loading patterns, again, without your JavaScript bundle on the page, just works. Like, you can use suspense list and suspense boundaries. Very cool. This is my favorite thing. The spinners work, actually, without the JavaScript bundle on the page and in an order that you can decide. Which is honestly I feel like all frameworks should steal this idea. And, of course, they steal from React all the time and say... Oh, we're already better. You ship before React does, which is like... Do you see why they didn't want me on the team anymore? But then there's like a bonus feature.

9. Running Your Own Server and Serverless Computing

Short description:

The page can start racing your JavaScript bundle with the server streaming. React tells the page it's now a client-side app and takes over for faster loading. Running your own server is necessary for these performance benefits. Two major choices are Node.JS or serverless computing with AWS Lambda or Vercel. However, serverless computing does not support streaming.

And I actually didn't include it in here because I didn't think I would have time. So the page can actually start racing your JavaScript bundle with the server streaming. So in the beginning, when you start up, it starts streaming down all these server... All this HTML. But you can also start loading the JavaScript. Usually the first time you're visiting the page, the JavaScript bundle might take a little longer to load. But the second time you visit the page, it's cached. Which means the JavaScript bundle loads immediately. At this point, React tells the page, this is not a server rendered page anymore, it's now a client side app. And immediately takes over so it can load even faster than the server rendered page. Wild feature. Just love it. So it can actually raise client and server side very cool. So these are all cool features. But there are tradeoffs. That's the other thing I say. None of this is actually free. What you need to do now is you need to run your own server. Some of you might have been using something like a create React app or something that was client side only. But if you want these performance benefits and a better programming model, just happy you're users, really, you now need to invest into a server. So you have two major choices to do this. One is Node.JS. Love Node. It took me from a toy JavaScript UX developer and made me effectively a full stack developer. Love it. Didn't have to change much. Just plain JavaScript. Shout out to stuff. It was a pretty great day, about ten years ago. But what you do is you either like have to rent hardware, a VPS or one of those things with a host like Heroku, Distill Ocean, I don't know, I haven't done it in years. I assume there are others on the market. Relax, it's just a dry cough. I'm fine. Yeah. So you pick one of these machines, and you then have to, like, set it up. You have to, like, set up process monitors, like, the moment it dies, you need to do a restart and monitoring. It's fine, I guess. I'm excited about stuff like fly.io. I know it tries to give you heavy metal on the edge, fix a bunch of cities and you can pick it and deploy your code onto it. Shout out to Ken, he deployed his site onto it, and it's a really fast, really great service. They're doing some very cool stuff. They seem to have hired a bunch of interesting people. But it still isn't trivial trivial. Like, you still kind of have to deal with your server. Or you do what's called serverless computing. Right? Which is your AWS Lambda or Vercel. Which is fine. But the problem is that they don't actually support streaming. The API ostensibly does. But what it does is kind of buffers it and only once it's done does it send the content down the pipe.

10. Serverless Computing and CloudFlare Workers

Short description:

You can choose to load your content early, but node is not ideal for the Lambda use case. There is a new breed of serverless computing options, including workers, edge compute, demo deploy, and Gatsby Cloud. More options are expected to emerge. CloudFlare workers offer a standard-based runtime with support for fetch and other web standard APIs, making it simple to use with React.

Which kind of ruins the effect that you want. You want it to load early. That's choice one. That's choice one. You can do that today. I bet some of you have your stuff up on node. It's not a bad choice. Also node isn't really built for the Lambda use case. Which is the suicide use case. It takes something like 200ms. Last I checked. I could be wrong about these numbers. It takes 100 to 200 milliseconds just to startup. You can look for a cold start time and you'll see people talking about it, I guess.

The choice too is this new breed of serverless computing that's happening across the world. My employer has something called workers. Fastly has something called edge compute. If anyone has used it, let me know. It's hard to use it right now, but I hear great things about it. The new kid on the block is demo. They have something called demo deploy. Shopify has something interesting. They have their own framework for deploying Shopify components. And I think someone speaking about it later in the conference. I'm super looking forward to it. Very exciting work. Gatsby I think now runs. Gatsby used to be a static site generator, but they're not so much, but they're not openly admitting it, and they run something called Gatsby Cloud. It's cool, by the way. It's called DST. I think Siddhartha is here. He'll be talking about it later. And there are more. There are going to be more. There will be a lot more people who will be... I expect more people to try this out. And there are some usual patterns. I would like to talk about CloudFlare workers. I picked them. Pay me for this. It's kind of nice. So CloudFlare workers. It's a standard-based runtime. You can do stuff like fetch, regular request response, a whole bunch of web standard APIs. No DOM APIs, but you don't need that on the server side. You have React there, of course. Which is nice. The code is super simple. You don't have to spin up and say a port. No.

11. Cloudflare Network and Data Persistence

Short description:

You just export a function called fetch that responds to a request and returns a response. It's the biggest network right now, with deals with 10,000 partners. Cloudflare can handle 10 to 50 requests per second, allowing for fast website loading. Workers provide a key-value store for data persistence, replicated across the entire network. Durable objects are JavaScript objects that can move between data centers, optimizing WebSocket connections based on user location.

You just export a function called fetch that responds to a request and returns a response. Super nice. It's across 250 cities across the world. 250 cities, like it's a small number and a big number. It's the biggest network I think right now. And they have deals with something like 10,000 partners or some shit like that. The employees aren't told where in the cities the actual data center is, by the way. So we like joking amongst ourselves that it's either underneath the tube, or it's in the air traffic tower in Heathrow. Because that's where you get best reception. It's either that or the BT tower. We're not sure. But massive network across the world. And the numbers are kind of wild. Because they have such a great network, they're within about 20 milliseconds of 80% of the connected world. And within 50 milliseconds of 95% of the like internet connected world. And to show you how fast that is, I want you all to try something with me. Okay? All right? I want you to blink as fast as you can. Okay? And we'll see how fast you can do it per second. Okay, ready? I'm like the blinking meme dude, right? Anyway. So I can do about 3 to 5 times a second. But Cloudflare can do about 10 to 50 requests in the same amount of time. Which means if you actually write your site well, you can load your whole website in like a second, maybe two. It's really fast. It's like scary how fast it is. And what I really like about stuff like Workers and the other runtimes is that they all have like zero startup time. There's none of this cold startup time or anything like that. It just starts up. You can start it, React starts up, take some data, throw it down the thing. But it's not just good enough to have a runtime that runs your JavaScript. You also need some kind of persistence. Because we have JavaScript here, but your database is halfway across the world, still not great. So, Workers also provides a little key value store, which is just hey, for this key, store this data. You can fetch it where you want. Which is also replicated across the entire network, which means the runtime and the data is, well, on the top of BDTar. And we also have this sci-fi thing called durable objects, which is just the coolest thing I've heard of. They're literally JavaScript objects that can move from data center to data center, depending on who's asking for it. It's wild. What that means is, let's say I... And you can use it for, like, WebSockets and synchronization and stuff. Which means that, let's say I'm talking to a friend in, let's say, San Francisco. I don't know anything about American geography. But let's say that New York is between London and San Francisco. Maybe. Let's say. Somewhere midway. Probably somewhere in the... I don't know. So the durable object that we use to, like, establish a WebSocket connection between each other could potentially, like, migrate to New York so that we get the best data to talk amongst each other. And then let's say a third person joins us from China, in which case, like, maybe the object figures are the centroid of these three locations. It's all very sci-fi.

12. The Future of React and the Ecosystem

Short description:

This is a big reset moment for React. It's a moment to start removing the fatigue and simplifying the parts that we have needed just to have a competent stack. There's potential for us to do more, exploring streaming as a model, lightweight libraries, and the ability to talk to APIs like durable objects and KB stores. Let's start thinking about what this means for React and the ecosystem.

This is, like, we're trying to figure out what the database story around it here is. But it's a very novel invention and we're dying to see what people build with it. And there's so much more.

And when I say so much more, I mean Cloudflare has a deep portfolio of services, and you should totally go check it out. There are also so many cool things we are building that I'm not allowed to tell you yet. And what you can do is buy me a beer right after the conference and start talking a little bit. But I can't do it on screen! Hey, boss manager! Anyway. Anyway.

So you can go explore more at workers.Cloudflare.com. There's a startup, a CLI you use, and you can start writing JavaScript and it works. It will be getting better soon. But the vision really for workers and I assume all these other run times, right, is I want to stop calling it serverless. What I really like to imagine it as is like it's one server that envelopes the world like a buckyball with your database all surrounded. Anyone taking a photo of this? I look like a maniac, I'm sure. So you can envelop the entire world in this mesh. Right now it's 250 cities. It could be thousands in the future. We might give you some hardware that you can just chuck behind your washing machine and then you can FTP into it and set your website up just like the 90s. It would be great. So edge networks like this are such a good fit for the React streaming model. It's instantaneous. We can give experiences that are way better than anyone's had in the past 30 years. The web is getting old.

So, while there is going to be an incremental story where we improve all these things, what I really think is going to happen is that this is a big reset moment for React. Of course all the popular libraries will still work with the existing model. The team itself is collaborating with CSS and JS library authors, and library authors. They work well. But I think there's potential for us to do more. For example, Node doesn't run on these networks, which means Next.js doesn't run on it. I don't know. Next.js, the folks might make some changes there. But it sure would be nice if we started exploring. If we had to build something from scratch, streaming as a model. data fetching, way more lightweight libraries, and the ability to talk to APIs, like durable objects and KB stores. What could we do? I want to leave you on that note. I want you to start thinking about what this means for React on the ecosystem. A lot of the complaints about React have been, like, bigger bundles, and over-engineering, and JavaScript fatigue. But maybe this is a moment for us to start removing the fatigue, to, like, simplifying removing the parts that we have needed just to be able to have a competent stack. And maybe we could have, like, a different story. I don't know. I'm going to try. I expect everyone else to because I don't usually ship my libraries anymore. But there are folks out there who will look at me and be like I find challenge accepted. And I totally would like to see that. There's some links. Well, you can just literally Google React18 working group and you can find a bunch of details about what I was talking about today, how to upgrade to the new API, guides for library authors for how to upgrade their authors, how you could possibly build a new JavaScript runtime if the next big serverless entrepreneur is in the crowd here somewhere or watching this in the future. There's a whole list of like... Sebastian from the team wrote down a list of things you can do to make it better. And yeah. I look forward to it.

QnA

Excitement about API and Q&A Lair

Short description:

I'm super excited about this very simple API that I expect will redefine the experience for React in the future. My name is Sunil. You can find me 3.1 on Twitter. I'm happy to talk to you after this. Thank you so much. Thank you. Thank you so much, Sunil. Would you step into the Q&A lair?

I'm super excited about this very simple API that I don't expect many people to use by hand but I expect will redefine the experience for React in the future.

My name is Sunil. You can find me 3.1 on Twitter, which is the worst thing to spell out to somebody on the phone when you want to tell them what your email address is. Yes, it's 3.1, all words, no numbers, no dots. You can reach out to me there. I'm happy to talk to you after this. And I'm looking forward to talking to all of you at the conference and grabbing a beer after this. Thank you so much. Thank you. Thank you so much, Sunil. Would you step into the Q&A lair? Oh, you don't even need to bring your own water here. We have water at the Q&A lair. It's quite a special place.

Audience Feedback

Short description:

Hey! How are you? How are you? I'm good. How are you? Not bad. Thanks for a wonderful talk, as always. I am a K-beam user. I do all the stuff. I'm a global K-beam user. I'm a global K-beam user. I'm a globe K-beam user. I'm a K-beam user. I'm a global K-beam user.

Hey! How are you? How are you? I'm good. How are you? Not bad. Thanks for a wonderful talk, as always.

I am a K-beam user. I am a K-beam user. I do all the stuff. I am a K-beam user. I do all the stuff.

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a globe K-beam user. I'm a globe K-beam user. I'm a global K-beam user. I'm a K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.

Global K-beam User

Short description:

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.

Global K-beam User

Short description:

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.

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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn