Wait, React Is Multi-Threaded?

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

We already know, ""if some task takes time, promisify it!"". But some tasks can be computation heavy and can take time to complete, so making them async is of no use since those have to be anyway get picked. Solution? Simple, multithreading! Yeah I know that React and in turn javascript is single-threaded but what if I told you that our life was a lie ever since? Enter web workers! Key takeaways of the talk: 1. An example of a simple product search showing why async js or concurrent mode cannot work. 2. Demystifying web workers. 3. How they make this magic happen under the hood? 4. The Question of life - Aren't they same as concurrent mode? 5. Comparing the same Product list app using web workers, diving deep into the performance. 6. How one can easily misuse web workers and how to avoid it.

This talk has been presented at React Day Berlin 2022, check out the latest edition of this React Conference.

FAQ

Nikhil discussed performance design systems at scale, multi-threading capabilities in React, and how these can improve user experience and application responsiveness.

A good user experience enhances product usage, reduces user frustration by providing seamless interaction with the application, and is crucial for business success as it retains users and prevents them from leaving due to poor performance.

The main focus of Nikhil's talk was on whether React can be multi-threaded and how multi-threading can be utilized to improve application responsiveness and overall user experience.

Implementing web workers involves managing complex communication between threads using message passing, handling coordination among multiple workers, and ensuring efficient resource management, which can add to the development overhead and complexity.

Web workers are particularly useful for CPU-intensive tasks such as image processing, large data computations, and handling complex algorithms like virtual DOM diffing in React, without blocking the user interface.

Web workers allow tasks to be handled in parallel using separate threads, keeping the main thread unblocked. This parallel processing prevents the application from becoming unresponsive, thus enhancing user experience by allowing continuous interaction even during heavy computations.

Concurrent mode in React breaks down tasks into manageable chunks that allow React to pause and resume rendering as needed, which enhances responsiveness. Web workers, on the other hand, handle tasks in separate threads entirely, allowing for true parallel processing without affecting the main thread.

Nikhil Sharma
Nikhil Sharma
22 min
05 Dec, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
This Talk explores the use of web workers in React to improve user experience and performance. It discusses the limitations of JavaScript rendering and how web workers can offload tasks to separate threads. The Talk also highlights the benefits of using concurrent mode in React and introduces the UseWebWorkerHook library for simplifying the creation of web workers. It emphasizes the considerations when using web workers and concludes with a mention of Postman's hiring and new feature release.
Available in Español: Espera, ¿React es Multi-Hilo?

1. Introduction and Background

Short description:

I'm Nikhil, an engineer at Postman, specializing in design systems and performance at scale. Let's connect on Twitter and GitHub.

Hey, everyone. Thanks for the amazing introduction. Super glad and pumped at the same time to be here virtually at React Berlin and be able to share my thoughts with all of you. As you might have got the introduction again, I'm Nikhil, and I work as an engineer at Postman. I mostly handle stuff around design systems, Postman on the web, and Postman's desktop platform. So if you want to talk to me about performance design systems at scale in general, I love to talk about those, by the way. So come say hi. I would love to connect on Twitter, on GitHub. I think you would be able to see the relevant tags, how you can connect with me. So we'd love to have a chat.

2. React Multi-Threading and User Experience

Short description:

In this session, I'll be answering the question of whether React can be multi-threaded and how it can improve user experience. Slow loading and non-responsive applications can lead to users leaving. Let's understand the problem through a demo and analyze the root cause of the issue, which involves the event loop and long-running tasks.

Okay. So before diving into the presentation, I would like to just give a brief overview of what I'm going to talk about here. So in this session, I'll be trying to answer like a very simple question, which is, can React be multi-threaded or can it not? So does it have those multi-threading capabilities and if it does, how it can help us with improving Okay. I'm going to start with the talk with one of the very noble statements, which is user experience is important, right? So what good user experience actually means is it is very delightful for users to actually use different parts of their applications, like different features with a very seamless experience. They don't have to hunt for like how to do something. They don't have to wait for stuff, stuff like that. Right? So user experience is always beneficial for your product and for generating business for it, right? Because users are always happy if your product is all seamless.

And to also talk about it in the in the extension to it, right, there was a survey that was conducted and it showed various reasons of why users leave, like they quit using an application. So if you see in these various reasons, one of the top reasons that was, was slow loading, which is like 88% users actually felt like they don't want to use your product if it is loading very slow, but we don't want to talk about it in our session. What do you want to focus more on in this is this yellow circle that you see that is 73% users not using an application or leaving that because of it being non-responsive or being a lot more janky. And we know that user experience is always beneficial to your users, as I mentioned, right? So you know, in this case, if you fall into any of these categories and user experience is not that good, right, your users might be like doing rage quits or like they might not want to use that application itself. So you don't want to use those to have such an experience, right? You always want them to be happy. And this is what like you want to talk about in our talk.

So let's try to understand the problem real quick and show you what exactly is a type of problem that I'm talking about. So if I go to the demo, you'll see this very nice small application, which shows you a nice spinner of React that is spinning in just to just to like show you when like give a glimpse of like when our application becomes unresponsive. So there's this large list of items that I have, and it's nothing fancy in it. There's just some items, I want to sort them. And I've initially like kept the logic of sorting to be like super slow, which is like bubble sort in this case, and which is intended to show you the experience of like a bad and janky UX, of doing like a task which is very big. So if I click on this button, that is the old way of doing it, I'm going to perform a sorting on this very large list of items. And since that item is going to take too much time, let's see what happens to the user experience into that app, right? So I click on this button. Now my app is all frozen up. I can't do anything. I click on I can't click on the buttons. And this is very bad. So after some time and this is done, now the spinner again gets to its spinning state, which is like for some point of time, my application was all stuck. So this is actually the problem.

Now let's try to do a root cause analysis of what went wrong, and what could have been improved when you were building this type of an experience. So let's look at a very simple diagram, which shows the current working of our event loop side. What our loop consists of is your JavaScript code, your event loop is like a stack, or not exactly a stack, it just takes in certain amount of operations, be it like some JavaScript functions, be it some other events, like mouse events, click events, and it just starts catering to them one by one, right? And if there is some event that is super big, in that case our event loop is all jacked up. And your users can't do anything else because of this very long running task, right? And since your event loop is all busy, and your JavaScript is taking too much time to free itself, your UI is going to appear to be all frozen up, and your users can't do anything until the time this big event is all done or not.

3. JavaScript Rendering and Web Workers

Short description:

To improve user experience, it is important to ensure that JavaScript runs and renders frames within the allotted time. If JavaScript takes longer, subsequent frames may be skipped, resulting in a janky experience. To address this, web workers can be used to offload larger tasks to separate threads, allowing the main thread to remain unblocked. By creating a worker instance and sending messages to the worker thread, tasks can be executed in parallel, improving performance.

So that is the exact problem, is this very big event that is coming in. Now, to back my statement up, let's do a quick math of how all of this aligns in a central place, right? So if you see that spinner in our demo that we showed, right? If you want to get it done to be 60 frames per second, that means we would have a thousand milliseconds to render 60 frames, right? That's the math. And it means that you have 16 milliseconds for your JavaScript to run per frame.

Now, to talk more realistically, browsers usually take up four or six milliseconds out of this 16 millisecond time, which is their internal tasks, composition, painting, understanding how to parse HTML, JavaScript and stuff like that. So roughly if you talk about it, your JavaScript actually has only 10 to 12 milliseconds or less to run and render that frame in a constant time and avoid lag.

Now, let's try to see this small example of how your code actually goes through a browser's pipeline, what exactly is going to happen when your JavaScript is run, when your CSS is run, and when everything is compiled. So all of this, if you see it in one frame, all of this has to be done in 16 milliseconds or less amount of time. So your browser has to run JavaScript, it has to compute what are the styles, what is the CSS for it, it has to render all of the CSS, prepare the DOM, it has to compose everything and parse everything down and show the final result onto your webpage. Now as you keep on adding more JavaScript, be it like, we are not just using vanilla JavaScript right now. Maybe we are using CSS and JS engine like style components, we are using maybe read us or a library called React. Not to mention that React, adding React can add time to your JavaScript running. But the intention behind this example is the more time your JavaScript is going to take, the more time is going to get extended for your browser to catch up with this. Because all of this has to be done in 16 milliseconds. If your JavaScript is taking more time, you are going to surpass that 16 millisecond time limit. And because your subsequent frames are going to also have to catch up, your browser needs to skip some of the frames in between to catch up to the speed of getting this JavaScript done and also catering to the other frames that are coming in. And because of that, as I mentioned, it needs to skip the frames. And that is exactly what a jank is, because you just see a not moving spinner, because it had to skip all the frames to catch up to the speed, right. And that exactly was the problem there.

Now, coming back to the problem, which was there was a very big task that was blocking your event loop, right? Now, if I had to actually get this out of my event loop, right, and prevented from not blocking, my problem would get solved, right? So the other bigger tasks can keep running in some separate context, while my event loop is all free. So any bigger tasks are not blocking my webpages, UX or like it's not blocking or not jarring up the experience. And this is exactly the ideology of a web worker, right? So simple things, simple put, a web workers actually allow us to do work in parallel using separate threads, right? That is like the very simplest analogy. So you can do more amount of stuff in like some parallel context or like parallel threads to avoid your main thread to get blocked, right? And you can give all those bigger tasks to your worker threads.

Now, if I want to show you how this all works up, right? Let's understand the small analogy. There is your React app that is running in a totally different thread. And there is a worker thread that is again, a totally separate context. Now, what happens is we create a worker instance using the new workers, new worker API. And the worker that we get, we attach, we send a message to our worker thread, which is done by worker.postMessage API. So we send it a message that, hey, there is this one big task you need to do. And the worker receives it because we attach an event listener on the worker side, which is self.eventlistener. So make sure that workers do not have access to your window.

4. React Workers and Resource Management

Short description:

React's main thread is not blocked while workers handle the big task. The worker posts a message back to the React app when it's done, and the result is shown on the UI. To free up resources, the worker is terminated.

It only has an access to a global object called this, right? So in the event listener, it listens that, oh, React is telling me to do something. Let me do that work. And in the meantime, React's main thread is not blocked because the whole of the big task is being done by the workers. And if it is done by the time, the worker then posts a message again back to your React app. And your React app again listens back that, oh, now, worker has completed something, and to do something on my UI to show it is maybe done or not. And then the result is shown on the React app. And finally, when everything is done, we also want to free up all users' resources because a worker is also using the user's resources itself to run it as a separate thread, so we do worker.terminate, which is a good practice to do.

5. Concurrent Mode and Web Workers

Short description:

In concurrent mode, React can switch between priority tasks, making it feel like parallelism but actually utilizing context-switching. JavaScript is single-threaded, but web workers can run in separate CPU cores, allowing for multi-threaded-like functionality. However, there are blockers to using web workers easily, such as complex message-passing and coordination between workers. Promises can be a solution, as they allow for easier detection of completion and updating of the UI. One library that can help with this is Commlink.

Now, the million dollar question, isn't it all done by concurrent mode? Because it also handles stuff like doing stuff, which is taking longer time or a similar context like web workers. What does web workers do that is different from this? So if I give you a quick recap of what concurrent mode was, if you imagine there is a product search application where you type something and the list of the product updates based on your search query. It shows that there is a user event, like a type, and there is a render phase where React app has to update your UI based on the search that you did. And that render phase, which is this very big yellow strip, is uninterruptable. Because React did not have the capability to jump to a priority-specific task, which was to handle that user event before doing the rendering part. In the newer concurrent mode, this yellow strip can be broken down, which means React can switch back, pause its rendering, and go to a different priority task, which was a user event. So cater to that, show that the type is working fine, and then resume its rendering back. If you understand this analogy of concurrent mode, the difference that lies in is the paradigm itself, which is concurrent mode on the first hand being context-switching. It is doing the same task, but it's creating sub-tasks out of those, and it's switching between the contexts. So it feels like it is parallelism, but it is actually just context-switching and it's doing the task in a synchronous type fashion.

Whereas, parallelism in general is not context-switching itself, it is like utilizing different resources of your CPU to do a different amount of tasks. So in the first example, I'm just doing one task. But actually, parallelism can do any number of tasks in parallel. Another question that now arises is, how do you do multi-threaded even if it's possible? Because JavaScript itself is single-threaded, right? How can you do this? So we need to understand thread and CPU as two also different entities to understand that answer better. A thread is a totally different entity. A CPU core, which can open a thread, is a totally different ballgame altogether. So you can see earlier, our machines used to be single core. But right now, in the new era of computers, you have multi-core machines, right? So what we want to do is our React app is running in a totally separate CPU core, right? Our web worker, which is again a single-threaded thing, but it is running inside a totally different CPU core itself. Which means a totally different execution context, and all are working in terms of passing messages to one another to communicate when the work is done. So it is single-threaded, but kind of multi-threaded, right? So you get the gist why it is functioning like a multi-threaded thing. So we are utilizing users' resources of different cores and we are running these two different worlds altogether out of these cores. So since these bring in so much to the table, why don't we use it, is the next question. So I personally found out that there are a lot of blockers which make us not use web workers in an easier way. So if you see, one example is you have a web worker, but you have to create a message-passing instance onto it, right? You have to create an, you have to set up event listeners and your workers and your main React app have to listen onto passing event listeners onto it, which is like some additional code that I don't like. Instead, wouldn't it have been better that you just need to create a function inside your worker and when you create an instance of the worker in the main thread, you just do worker.that function that you created, which is a lot simpler, right? Another class of problem that I saw is how to know when the worker thread is complete or not, like how to know the status, is it still running? Has it started or not? Is it done or not? So that is like totally, it is like very difficult to do, I would say, because it is, these messages are like just fired and forget. So there's no direct way to get how to update your UI based on whenever this worker is going to get complete. And an extension to this problem is actually one of the other key things that I discovered, which is how to coordinate between the web workers, right? Because if you see in this example, there is one worker that is doing one task, there is another worker doing some other task. And then there's a third worker that is actually waiting for the first and the second task to get completed, right? So it is like, it like the complexity brings, like comes in when you are using this sort of architecture and like handling too many web workers around that, right? So what could be the solution obviously promises, right? So because asynchronous JavaScript is so easy to detect like when something is going to get completed, right? So it would be like slightly easier if you could do a POST message to a worker and just await the result, like instead of returning a value, your worker actually gives you a promise. And you can now know that, okay, I know when it is going to get completed. And then I can update my UI based on that, right?

A few libraries that I want to mention, which is first is Commlink.

6. Using UseWebWorkerHook for Improved Performance

Short description:

There's an amazing library called UseWebWorkerHook that simplifies the process of creating a web worker in React. By defining the worker and using the sort worker function, you can offload time-consuming tasks to a separate thread, improving app performance and user experience. The main thread is unblocked, and the spinner no longer freezes. Web workers are useful for CPU-intensive tasks.

That is amazing. There's another amazing library created by Google Chrome Labs themself. But like another library that I like personally, which is like super helpful when you're creating stuff with React, is UseWebWorkerHook, which is just simple steps, or like two simple steps that you can use to create the same, right? So you just create a worker by using a UseWebWorkerHook. Pass it the function like that big function that's going to take a lot of time in case here that I added as bubble sort, right? And it gives you the instance of the worker. It gives you an instance of like a function to kill the worker and all the stuff. And whenever you want to perform it, you just do sort worker, which is the function here that you got. So you do the sort worker and you just pass in the relevant data. And that is it. So you just define the worker and you just use it. And that is all that you need to know.

All right. So enough of the knowledge, and let's get back to the same old demo that you were talking about. So in here, now what I'll do is I will use this newer button which says new wave. And in here, what I'm doing is the same exact thing, which is creating a worker and pass and allowing that worker to do the same bubble sort in its own context. So now let's try to see what happens to the spinner when I try to do that. So I click on this. Now my spinner is not like jank and all frozen up. So my app is again usable and my users are like all happy. In the meantime, I was also able to do this very big task itself. And if you want to also check this by performance, I, like, let's try to do this again and see the performance track of it, right? So if I open this performance tab, I click on the folder where we are doing things, which is when my app gets jammed up because of doing things synchronously. And if I close it down, you'll see that the main thread is actually spending the time, like if I open it here. So you'll see that there is like a very big 5.69 seconds even that was blocking the main thread similarly that we talked about, right? So that is why the spinner gets like got all frozen up. But in the other case, if I do the same with again, starting the profiling and clicking on the web, the use worker way of doing things, we should actually see that our main thread should be all unblocked, right? So if I close this down again, and we see the profiling now. We would see that now that very big bar is not is gone in the main thread, right? And if I close it down, you would see that now the worker thread actually has that very big bar. So that's why a spinner was not all janked up, right? Because the worker thread is catering to that bigger task. All right. So with this, I think we seem to have achieved something onto this thing and like improve the user experience in these scenarios. Right? So yeah, kudos, great job on to that. So a few more things to just mention it down. So there are a few instances that where you can use web workers, which is exactly where you need to do some CPU intensive tasks.

7. Web Workers and Considerations

Short description:

You can assign a worker to do all the computation stuff of like what Node has been updated or not, what is the updated tree. Anytime you see something that is taking too much time and is going to block your event loop onto this we should revert to the web worker strategy. Be cautious in choosing between web workers and other options. Tasks like network calls and DOM manipulation may not require web workers. Web workers do not have access to the document object or local storage. Adding more web workers can increase complexity and maintenance efforts. Lastly, Postman is hiring and releasing the WeTen feature. Visit the careers website and check out the blog for more information.

And you don't want to block your UI onto that, as I mentioned, right. Which is, for example, virtual DOM diffing that React does, right? You can assign a worker to do all the computation stuff of like what Node has been updated or not, what is the updated tree. So all those calculations can be given down to the web worker. Similar this maybe for image manipulation and processing and for canvas drawing. So the gist is the same. Anytime you see something that is taking too much time and is going to block your event loop onto this we should revert to the web worker strategy.

And which is again, a word of caution, which is we need to be wise in terms of choosing between those two things, right? So if you see tasks like which are IO bound, right, which are like maybe network calls and other stuff, you don't need to use web workers in those cases, right? Because those are already async and it just adds onto the complexity. Similarly, like if you go to DOM manipulation and you want to add it to a web worker, a web worker does not have access to your document object, right? Like again, the reason being different CPU, different contexts, like different CPU cores, so it does not know what the window is, what's the other world doing? It does not know about that. And similarly for local storage, because again, it does not have access to that API. And last but not the least, it's not like super, you would need to be like super cautious if you want to use web workers, right? Because when you grow and like you keep on adding web workers, it just adds on to the complexity and it can become super hard to maintain them down, right? So you need to be super cautious if you want to go with this approach or not. So that should be the decision to make.

All right, so with this, I would like to end my talk and I hope you guys were able to get some insights out of it. Last but not the least, we are doing some amazing stuff at Postman itself. So we are hiring and if you would want to be a part of our amazing journey, please visit out the careers website and I think we'd be glad to have you on board. And as I mentioned about interesting, we had been working super hard to release the WeTen feature of Postman. I been having many people asking me about what the features are going to be. And I know the people are super excited about this WeTen release. So if you'd want to know more about it, please check out the Postman's blog and take a look at the amazing features coming in. Alright. So with this I finally now end my talk. So I would like to thank everybody, the organizers, the community for organizing this amazing event and having me here. It was super amazing to be here. And last, but not the least, the amazing audience. So a kudos to everybody for making this event a success.

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

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
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 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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 Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
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.