React 18 Keynote

[Music] hello and welcome to react conf 2021 it's been a little longer than usual since our last conference we have some exciting announcements and a great lineup of speakers from all around the world my name is andrew clark i'm an engineer on the react team over the years i've helped build features like hooks and suspense but before i started working on react full-time i was an open source contributor so one of my favorite parts of the job is getting to work with all the incredible people in the react community programmers designers hackers artists students and teachers many of whom we'll hear from today as you might expect some of the presentations though not all of them will be quite technical going in depth on topics like performance and application architecture but as we watch these presentations i want us to remember that the point of react is not to showcase impressive feats of engineering ultimately the technical work we do only matters if it's in the service of building great user experiences react has become the tool developers pick to build ambitious user experiences everything from static web pages to rich interactive applications it's used by teams building apps with hundreds of millions of users and by individual developers working to build the next big thing but what i found even more personally gratifying is react's impact beyond traditional programmers react has also become a hit among designers some design tools have built-in support for react for example framer has a feature where you can export your designs as jsx and paste them directly into your react application when i see tools like this i have two reactions the first is this is amazing there was a time when i could have scarcely imagined something like this might exist my second reaction is it doesn't feel that surprising it feels like an inevitable progression of what react has always been because the inspiration for react's apis are rooted in design principles not programming while i myself am not a designer i got my start as a web developer at a design agency the designers i worked with created beautiful mock-ups and prototypes and it was my job to translate them into real working user interfaces i loved working with designers but as some of you may know from experience the communication between designer and developer isn't always seamless a big reason for this was because in those days the tools and software patterns that i used to build the ui were very different from the concepts the designers were using to design the ui the designer spoke in terms of patterns and variants meanwhile i spent a lot of my time doing things like debugging weird inconsistencies in the ui and navigating through complex event chains i was working with tools and programming concepts that felt far removed from the user experiences i was trying to pull into reality it's like the designers and i were speaking different languages and when designers and programmers speak different languages the user experience gets lost in translation then i learned about react and what immediately captured my interest wasn't any particular api or implementation detail it was simply the idea that you could build an entire user interface using nothing but components react didn't really invent components designers had been using them in their tools for decades but what react did was it made components a mainstream part of ui development react proved that components weren't just a great way to design user interfaces you could use them to build user interfaces too with react designers and developers speak the same language when you use react it feels like you were directly authoring the user experience that is the true power of react it's not about the technology it's about what the technology enables sometimes developer experience is framed in opposition to user experience as if by optimizing for one you necessarily sacrifice the other and there are certainly examples where this has been true but we believe that developer experience and user experience are not a choice truly great developer experience does not sacrifice user experience it enables it it shifts our expectations of what's possible apps that could have once only been built by a team of seasoned software engineers can now be built by say a designer with limited programming background or maybe one day no programming background at all so throughout the conference when you hear shaun day talk about streaming server rendering when you hear shruti talk about new features in react-18 when you hear schwinn talk about our research into compilers or when you hear daishi talk about integrating with external stores just remember that all our work is ultimately in service of one thing our north star to make it easier to build great user experiences later in this presentation we'll share an update on react 18 our next major release but before we do that i want to take a look at one of react 18's most anticipated features suspense the basic idea of suspense is that it allows you to read data over the network as easily as you read props or state but i think that really undersells what suspense is suspense expands our notion of what a component can be what seems like a small idea on the surface has big implications on the way we build applications some of you have heard of suspense already but i know many of you are hearing about suspense for the first time so in a few moments my colleague juan will give a brief overview of suspense and how it impacts both developers and end users we showed off an initial prototype of suspense all the way back in 2018 and we released a basic version of suspense that same year however the basic version has some key limitations the only officially supported use case is dynamically loading code with an api called react lazy and it can only be used on the client not during server rendering but our vision for suspense has always been about much more than loading code on the client it's about improving the loading experience for all the kinds of data in your application on both the client and the server we spent the past several years using suspense to build real user-facing applications during our development we've consulted not only with engineers but with designers and user experience researchers and we've used this to refine the suspense model while the core idea of suspense hasn't changed since our original demos many of the details have evolved let's hear from juan to learn more thanks andrew i'm juan and i'm an engineer formerly working on relay and now working on react developer tooling so when we think about react one of the nice properties that makes the react model so good is that you can usually read components from top to bottom to understand what they're doing maybe they take some data massage it in some way and return some jsx it's declarative and it feels reactive but when we introduce asynchronous code this starts to break down and we can't read this code from top to bottom anymore now we have to mentally jump around the code to understand what it's doing for instance here we need some state and then at some point in the future we'll fetch some data inside of our effect and then at some other point after that's fetched we'll update that state which will cause a re-render but what if the page id changes at some point while all of this is happening so there's a lot of jumping around and it's really easy to make mistakes and introduce bugs like race conditions when writing this type of code which is why in practice a lot of people probably don't write code like this manually and instead they probably use a data fetching library and there's a lot of great libraries for this for example apollo uses wr or react query just to name a few which provide apis that might look something similar to this a hook which is easy to use and handles this complexity for us so here we get back a piece of data and a boolean indicating whether that data is being fetched and this is nice because now we can go back to reading this code from top to bottom in a reactive way and we can understand what is happening without having to make these jumps or keep track of time in our heads although this is really good we think this can still be improved it might not be noticeable at first because this is how we've usually written asynchronous code in the past but we think that we are mixing two concerns here that don't need to be together the first one is reading the data such as getting the items here and the second one is specifying a loading state such as returning the spinner these things may look like they have to be in the same place but we actually think that they belong in two different places in our code and so why is that well we think there are there are two problems you run into when we mix these two concerns together the first one is it becomes harder to add or remove data inside arbitrary components because every time you do so you're kind of forced to figure out what to do with the loading state for that new data so for instance should we return a spinner here or should we just render null it's not always immediately clear what we should do here and this adds overhead to our workflows because we have to be making these these decisions every time we add or remove a piece of data the second problem is kind of the inverse if we want to change how our loading states are displayed then we'll have to modify the code that fetches that data which might involve moving a lot of code around so for example if we read some data in two different components but now we want them to have a single combined loading state now we have to move and combine those data queries further up in a parent component for example may be using something like promise.all in order to actually combine these loading states this kind of makes it unnecessarily hard to adjust the visual appearance of loading the data and we think that the solution for this is to separate these two concerns so first in the component that reads the data we don't really change much the only thing that changes is that there is no is loading boolean anymore the only thing we get back from our data fetching library is the data itself you can still read this code from top to bottom but you don't need to think about the loading state at all it's as if we're reading this data synchronously and it doesn't really matter to us whether it's actually synchronous or asynchronous in reality it might be asynchronous and under the hood our data fetching library will inform react if that's the case but what about the loading state well we think the right place for the loading state is actually inside the jsx specifically inside one of the parent components instead of putting the logic for handling the loading state inside the component that reads the data we believe that a better way is to wrap it with a special parent component that tells react hey here's a placeholder or a fallback or just whatever piece of ui to show when something in the jsx below us is not ready yet and this isn't a programming concept this actually goes back to what andrew said that design inspires a lot of react concepts and this is similar to skeletons and loading states that designers use in their language you have a piece of ui and you have a fallback for when that piece of ui is not available and so the key point here is that we think that the right place for the loading state is inside the jsx and this is exactly what the susp suspense component is a react component that lets you specify in a declarative way right inside your jsx that when a part of the ui is not ready we want to show something different in the meantime and so now that we've separated reading the data from where you specify the loading indicator this has really positive effects on our workflows for one going back to our example this makes it a lot easier to add a new data dependency to a component that didn't have one before because now we only need to read the data that we want here and we don't have to think about the loading state at all instead this new data access will automatically be hooked up to a loading state specified by the nearest parent suspense component inversely if our design changes and we want to change the visual appearance of our loading screens we can do that without thinking about which component reads which data for example if we initially have this header and list wrapped in the suspense component then this skeleton will show when either of them are fetching data and then when they're both done fetching they will pop in together at once but then if we decide that actually we want the header to pop separately and we want the list to have its own placeholder that is more specific like for example an animated glimmer then we can wrap that list in the suspense component right in our jsx and we don't have to change any of the code that reads the data for the list because right now we're just working on the visual appearance and then even if that list changes and is updated to something else like a special list and we need to use more components in between that's still okay this loading state will still continue to work and will show the placeholder as long as the list in the jsx underneath it isn't ready yet so this makes it easier to adjust the loading sequences in our app and it's also easier for designers to work with because if they want to change the appearance of the loading screens or how they are grouped they don't have to change any of the data fetching code they just have to add or remove suspense components in the jsx and this simple design-centric idea of decoupling these concerns and making the loading states a bit more declarative by moving them from somewhere buried inside our code to somewhere insider jsx also has some really interesting technological implications one of them is that it lets us treat other asynchronous dependencies in a similar way we want to treat data that means we're not limited to using suspense just for data it could be used to control the loading states for any type of asynchronous resource we need to load for example we can use it for loading javascript bundles for code splitting as some of you might know code splitting is a common optimization web apps used to dynamically load javascript bundles as we need them instead of loading one big js bundle up front and like andrew mentioned this is already this already works with suspense today because this was the first use case we implemented and released for suspense back in 2018 so today you can use react.lazy and suspense to specify loading states when downloading javascript for your components and so this was the use case we started with but it's such a generic concept that now that react knows where your loading states are in the jsx it can do a lot with that information for example something new in react 18 is that suspense now works on the server which means that it can be used for code splitting on the server but it also enables a new feature called streaming server rendering in which react can use the information of where our loading states are in the jsx in order to stream down html from the server what this means is that react can first send down the html of the placeholders if the whole content isn't immediately ready and then send down the html of the actual content once it becomes available and we're going to hear a lot more about how this all works in chande's talk later in the conference and of course the main motivation for suspense was for data fetching and this is something that took us the longest time to figure out like andrew mentioned we've spent the past several years using suspense to build real user-facing applications and a big part of this was building the first suspense integration into relay which is our data fetching library and using relay to put our model of suspense to the test through this work we iterated fix and refine our model of suspense for data fetching and the version of suspense that will be included in react 18 will reflect these improvements so data fetching with suspense will be supported with relay on day one of the react 18 release but we know that a lot of people don't use relay and the thing that we realize while implementing and iterating on suspense in relay is that it's actually pretty hard for library authors to implement suspense today so that's why we're currently working on a few low-level apis in react itself such as a built-in suspense cache that will make it much easier to integrate suspense into data fetching libraries so there won't be generic support for most libraries on day one of the react 18 release but we're already collaborating with other data libraries in the community like apollo usswr and react query and we hope to make this widely available in the ecosystem soon after the 18 release back to you andrew thanks juan we think suspense could have a transformational impact on the way we write and design applications but as with the original release of react shifts like that don't happen overnight they can take months or years to fully realize our next major release react 18 is the first step toward that vision now let's hear from lauren about react 18. hi i'm lauren the new engineering manager supporting react and i'm humbled to be able to share their work and progress with you on react 18. like previous major releases react 18 includes out of the box improvements that you can start using on day one this includes automatic update batching for better rendering performance and use id a hook for generating unique ids that are consistent across server and client and can be passed to aria attributes for accessibility react-18 is also the first release to include some long-awaited new features such as start transition and use deferred value and as juan explained earlier support for suspense on the server you hear lots more about react 18 later today from shruti we'll give a demo of how these new features impact application developers many of our new features are made possible by a low-level behind the scenes technology called concurrent rendering we've talked about concurrent rendering in previous conferences those talks tended to be very research heavy focusing on technical details and react itself but we haven't always done a good job describing how concurrent features impact the end user here's what you need to know concurrent rendering is a behind the scenes capability that we've added to react itself it's a technical foundation on top of which we build features you care about like suspense it unlocks entirely new features that weren't possible before like pre-rendering screens ahead of time before they're shown to the user now this might all sound like science fiction but in practice you don't need to think about it when you're writing components as always you focus on what you want your app to feel like and react takes care of how to deliver that experience we've been working on the features in react 18 for years and admittedly it's taken a little bit longer than expected to prepare them for a stable release the reason is that we've taken extra time to make sure the upgrade path meets our high standards for gradual adoption and with react 18 we have an upgrade strategy that delivers on this promise on day one of grading to react 18 your app will work pretty much exactly as it did before with a level of a migration effort comparable to previous releases once you've upgraded you'll be able to immediately start using new features in specific parts of your app in our testing we've upgraded thousands of components to react 18. what we found is that nearly all of them just work with our new features without any changes however some of them may require some additional migration effort although the changes are usually small you'll still have the ability to make them at your own pace the new rendering behavior in react 18 is only enabled in the parts of your app that use new features in past years you may have heard of something called concurrent moan that was an old strategy where all of your components would have started using concurrent rendering as soon as you upgrade after hearing your feedback we're excited to share that concurrent mode is nowhere to be found in react 18. it's replaced by a gradual adoption strategy where you can adopt concurrent rendering at your own pace in other words there is no concurrent mode there are only concurrent features a lot of care and attention has gone into this release not just from the react team but from leaders across our community when we released the react 18 alpha earlier this year we also announced the formation of the react 18 working group a panel of experts developers library authors and educators with the goal of preparing the release for the wider ecosystem the react 18 working group has been a huge success one of our experts acontra will give us a look at some of the many improvements they've made this year thanks to their contributions we're closer than ever to bringing react 18 to you a few weeks ago we released a public beta of react 18 to invite additional feedback from the community today after years of research and months of refinements we're proud to announce that a release candidate of react 18 is now available a release candidate means that pending additional feedback this is the exact copy of react we will ship to a stable version to make that happen we're asking for one final round of testing whether you're an application developer a library maintainer a student a teacher a programmer or a designer we invite you to try to release candidate and let us know your experience if all it goes according to plan we expect to promote the release candidate to a final release early next year now back to andrew thanks lauren we believe the new features in react 18 have the potential to kick off a generational shift in the way we build applications and the behind the scenes capabilities we've added will power the next era of react innovations by upgrading to react 18 you'll unlock not only the features we've talked about today but all the exciting features yet to come one of those features is an experimental project we announced last year server components server components build on top of suspense and takes it to the next level yet again expanding our notion of what a component can be not only can components read data across the network they can live on the server and read data directly from your backend data layers with server components you can build apps that seamlessly span across server and client we think this offers a much simpler programming model for building full-featured applications while at the same time dramatically reducing the amount of code sent to the client you can learn more about server components by visiting our website and by watching the deep dive we shared earlier this year server components are still a work in progress so they won't be included in the stable build of react-18 however although we can't recommend server components for general use we've already seen significant investment from partner teams who are building platforms on top of our server components technology for example later in the program you'll hear about hydrogen shopify's new platform for building custom storefronts using react and server components we're also working closely with for cell who recently added alpha support for server components to next js because they rely on an experimental build of react we can't guarantee the same stability as our regular releases but if you're interested you can use these frameworks to try the server components preview today the server components preview is available now in our experimental release channel and we hope to ship a stable version of server components in a future 18 miner release we're excited about all the momentum behind server components so to facilitate the community's ongoing research and development today we're forming the server components working group check out the react blog for more information finally let's hear from rick for an update on react native thanks andrew as we've discussed today react 18 brings new concurrent features like suspense to the web but many of the original ideas that led to those features were directly inspired by our experience building apps for ios and android we know that today many of you think of react native as separate from react if you're a react web developer you don't necessarily consider yourself a react native developer too and that's understandable when we launched react initially it was only available for the web so we just called it react when we launched mobile a few years later we needed a different name for the library so we call it react native but we actually think of these as the same and that thinking is what led directly to concurrent rendering in react 18. in fact concurrent rendering was originally inspired by problems found in react native as we shipped more products in react native we started to see ways we were failing to meet the expectation of users on mobile platforms in our research we discovered a fundamental flaw in the threading model for react native on web javascript is single threaded but native platforms run on multiple threads that means in order to deliver the best user experience on mobile platforms we needed a model that would allow us to coordinate work between multiple native threads we knew to be on the same level as other native frameworks we needed to add concurrency to react concurrent rendering would allow us to interrupt work on one thread and switch to another or run multiple rendering tasks in parallel this would enable us to take full advantage of the native platform and better meet the expectation of users on mobile we also knew that concurrent rendering had tremendous benefits even on the web native platforms usually include a task scheduler to manage work across multiple threads since the web is single threaded there hasn't been a need for a scheduler based on our work with concurrent rendering though we were able to help define a scheduler for the web and over the last two years we've worked with browser vendors to integrate it into the web platform as the post task api scheduling gives us a new browser tool to create more fluid user experiences on web by breaking rendering up into multiple tasks in this way we're bringing good ideas from native and upstreaming them to the web when we started thinking about concurrent rendering we originally thought of it as just a way to improve performance and responsiveness but as we started researching web features like code splitting data fetching streaming server side rendering and server components it turned out that all of these features could be built a lot more naturally on top of concurrent rendering so we designed suspense which takes advantage of concurrent rendering to load data in the background without blocking the user on top of suspense we were able to build all of the concurrent features shown here today this was completely unexpected we probably would have never thought to build concurrent rendering on the web on its own but building concurrent rendering forced us to think of react in a different way and that gave us a new programming model with new and unexpected capabilities the next step will bring suspense to react native which i'll speak about in a bit but when we do suspense will be an example of something we built for web that will influence native platforms in the future in this way we're also to bring good ideas from the web to native so we bring good ideas from native and upstream them to the web and at the same time we bring good ideas from web to native but those are not the only platforms that influence each other for example on android the memory constraints forced us to design an optimization to flatten views before committing them to the tree we never built this optimization for ios because it doesn't have the same memory constraints but by using the same react runtime we were able to turn this optimization on for ios by just flipping a switch we likely would have never built this for ios alone but our investment on android was able to benefit our investment on ios and this isn't limited to mobile later today we'll have a talk from eric and stephen about react native desktop where they'll share how improving startup time on mobile led to huge gains in startup performance on desktop going even further we're even adding platforms like vr where memory constraints force us to manage memory more effectively on all platforms as you can see we're not building react for individual platforms and we're not building to the lowest common denominator we're building react together using the best parts of every platform each platform contributes their own constraints and their own user experience expectations so by solving those problems for every platform it benefits each platform this is what we mean by our many platform vision react will get better on each platform individually by improving every platform holistically this means that react is more than a library react is a paradigm for building user interfaces no matter how you learn react that knowledge will transfer to build high quality apps on every platform learn once right anywhere that's what react is so where is react native today react native currently cannot support concurrent rendering in react 18. as mentioned earlier there are just technical limitations to the react native architecture that fundamentally cannot support concurrency on the web react is always synchronous so we needed a way to split it up to make it asynchronous but react native was originally written to always be asynchronous we found that we need to make it synchronous in order for the react runtime to have direct control of the threading model for use cases like gestures and layout measurement that benefit from concurrency so while it's counter intuitive we've been rewriting react native to be synchronous so that it's possible for it to be concurrent and we've been hard at work at this effort for the last couple of years currently the new architecture has rolled out to a hundred percent of services in the facebook app which includes over a thousand screens we're also excited to share that we've launched react 18 on all of those surfaces proving that the new react native architecture supports concurrent rendering and react 18. this means when the new architecture for react native lands you'll be able to use react 18 with it automatically this is an exciting milestone but we still have some work to do on the new architecture before it's ready to share react 18 will ship with the new react native architecture next year back to you andrew thanks rick we're excited to bring react 18 to react native expand react to even more platforms and to make it possible to build cross-platform apps without compromise because the past and future of react is about rejecting false choices you don't have to choose between tools that are intuitive to designers and usable by programmers with components you can directly author the user experience you don't have to choose between server driven apps that load fast and client driven apps that are rich and responsive with server components and suspense your apps will seamlessly span client and server and one day you won't have to choose between apps that provide a native feeling experience and apps that run on many platforms with react you'll be able to build best-in-class user experiences on every platform and every device it's an ambitious vision and we have a ways to go but with the help of the react community we think we can achieve it thank you so much for joining us today we have an incredible lineup of speakers you'll hear later from brian vaughn about what's new in react developer tooling from rachel neighbors about the new react documentation and from xuan huang about new research we're doing on optimizing rerenders but before we get to those topics i would like to invite shruti kapoor to demonstrate what upgrading to react 18 feels like in practice

Channel: React Conf 2021

Views: 23,248

Keywords:

Id: FZ0cG47msEk

Length: 33min 48sec (2028 seconds)

Published: Thu Dec 09 2021