Wait, React Is Multi-Threaded?

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. So as you might have, I think, 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 where how you can connect with me. So we'd love to have a chat. 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 the user experience of our applications? Okay. So 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. So a good user experience is always beneficial for your product and for generating business for it. Because users are always happy if your product is all seamless. And to also talk about it in the extension to it, 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 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, which 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. But in the case, if you fall into any of these categories and user experience is not that good, your users might be doing rage quits or they might not want to use that application itself. So you don't want your users to have such an experience. You always want them to be happy. And this is what you want to talk about in a 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 show you and give a glimpse of when our application becomes unresponsive. So there's this large list of items that I have, and it's nothing fancy in it. It's just some items I want to sort them. And I've initially kept the logic of sorting to be super slow, which is like bubble sort in this case, and which is intended to show you the experience of a bad and a janky UX of doing 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. 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. Now after some time and this is done. Now the spinner again gets to its spinning state, which is like for the 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 like, 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 loops. So what an event loop consists of is you have some javascript code, your event loop is like a stack, which is like just taking or like 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. And if there is some event that is super big, right, in that case, our event loop is all jacked up, it 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. 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 like how this is like how like 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 like get it done to be 60 frames per second, that means we would have 1000 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 like more realistically, browsers usually like take up four or six milliseconds out of this 16 millisecond time, which is like their internal task, like composition, painting, understanding like how to pass an html, how to pass a javascript and stuff like that. So roughly, if you talk about it, your javascript actually has only 10 to like 12 milliseconds or less to run and like render that frame in a constant time and avoid lag, right. Now, let's try to see this small example of how your code actually goes through a browser's pipeline, like 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 like see it in like one frame, right, all of this has to be done in 16 milliseconds or less amount of time, right. So you have to run your browser has to run javascript, it has to compute what are the styles or what is the css for it, it has to render all of the css, prepare the DOM, it has to compose everything and like pass everything down and show the final result onto your webpage, right. Now, as you keep on adding more javascript, right, be it like maybe like we are not just using vanilla javascript right now, right, maybe we are using css and JS engine like style components, we are using maybe Redux or a library called react. Not to mention that, you know, react, adding react and you know, add time to your javascript running. But like 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 with 16 milliseconds, right. If your javascript is taking more time, you're going to surpass that 16 millisecond time limit and because your consistent, your subsequent frames are going to also have to catch up, your browser needs to skip some of the frames in between, right, to catch up to the speed of getting the javascript done and also catering to the other frames that are coming in, right. 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, like out of my event loop, right, and prevent it from not blocking, my problem would get solved, right. So the other bigger task can like keep running in like some separate context while my event loop is all free up. So my bigger, like any bigger tasks are not blocking my web pages UX or like it's not blocking or like not jarring up the experience. And this is exactly the ideology of a web worker is, 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 web 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, like we sent 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 have attached, 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. 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 at, oh, now worker has completed something. And now I need to do something on my UI to show that 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 single, like a separate thread, right? So you do worker.terminate, which is like a good practice to do. Now the very million dollar question is like, isn't it all done by concurrent mode? Because it also handles stuff like, you know, doing stuff which is taking longer time or a similar context, like web workers, right? What does web workers do that is different from this? So if I give you a quick recap of what concurrent mode was, right? If you imagine there is a user, if there is a product search application, right, where you type something and the list of the product updates based on your search query. So it shows that there is a user event, like a type, and there is a render phase where your react app has to update your UI based on the search that you did, right? And that render phase, which is this very big yellow strip is uninterruptible because like 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 with us. So in the newer concurrent mode, this yellow strip can be broken down, right? Which means now react can switch back and like pause its rendering and go to a very, like a different priority task, which was a user event. So cater to that, show that the user, like the type is working fine, and then resume its rendering back. So if you understand this analogy of concurrent mode, right? The difference that lies in is the paradigm itself, which is concurrent mode on the first hand being context switching, right? So it is doing the same task, but it is switching between like, like it's creating subtasks out of those and it's switching between the context. So it feels like it is parallelism, but it is actually just context switching and it's doing the task in like a synchronous type fashion. Whereas parallelism in general is not context switching itself. It is like utilizing different resources of your CPU to do different amount of tasks. So in the first example, I'm just doing one task, but actually parallelism can do a number of tasks in parallel, right? Another question that now arises is like, how do you do multi-threaded if it is, even if it's possible, right? 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, right? So a thread is totally different entity and like a CPU core, which can open a thread is like a totally different, it's a totally different ballgame altogether. So you can, you can, you can see like earlier, our browse or like our machines used to be like single core, but right now in the, in the new era of computers, you have like multi-core machines, right? So what we want to do is our react app is running in a totally separate CPU core, right? And our web worker is again, which is like, again, single threaded thing, but it is running inside a totally different CPU core itself, which means a totally different execution context, totally different event loop. And all are working in terms of passing messages to one another to communicate when to, when the work is done, right? So it is single threaded, but like kind of multi-threaded, right? So you get the gist why it is like functioning like a multi-threaded thing. So we are, we are like utilizing users, the resources of like different cores. And we are running these two different worlds altogether out of these cores. So since these bring in like so much to the table, why don't we use it is the next question. So I personally found out that like, there are like a lot of blockers, which like make us not use web workers in like a very easy way. So if you see one of the example is you have a web worker, but you have to like create a missing message passing instances onto it, right? You had to create an, like you have to set up event listeners and your workers and your main react app to like listen onto like passing event listeners onto it, which is like some additional code that I don't like. Instead wouldn't 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 like a lot simpler, right? Another class of problem that I saw is how to know like when the work of a mess, like 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 like it is like very difficult to do, I would say, because it is like these messages are like just fire and forget. So there's no direct way to, you know, get how to update your UI based on whenever this worker is going to get complete. And like, 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 tasks. 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, but 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 would be the solution? Obviously promises, right? Because asynchronous javascript is so easy to detect, like when something is going to get completed. 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. All right. So a few libraries that I want to mention, which is first is Comlink. That is amazing. And there's another amazing library created by Google Chrome Labs themselves. But like another library that I like personally, which is like super helpful when you're creating stuff with react is use web worker hook, which is just simple steps, like two simple steps that you can use to create the same. Right. So you just create a worker by using a use worker hook, 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 this, 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 way. And in here, what I'm doing is the same exact thing, which is creating a worker and pass and like allowing that worker to do the same bubble sort in its own context. So now let's try to see like what happens to the spinner when I try to do that. Right. So I click on this. Now my spinner is not like jank and like all frozen up. So my app is again usable and my users are like all happy. But 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 older way of 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 event that was blocking the main thread. Like we talked about. Right. So that is why the spinner get 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. You would see that now that very big bar is not is gone in the main thread. Right. So 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 jammed 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 improve the user experience in these scenarios. Right. So, yeah, good. Great job on 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 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 is 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 context, like different CPU core. Sorry. So it does not know what the window is, what the other, 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 onto the complexity and it can become super hard to maintain, 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 V10 feature of Postman. I've been like having many people asking me about what the features are going to be. And I know that people are super excited about this V10 release. So if you would want to know more about it, please check out the Postman's blog and take a look at the amazing features coming in. All right. 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 kudos to everybody for making this event a success. So thanks again for having me and enjoy the conference.