JavaScript Isn’t Slow – It’s Just Scheduled Wrong

Hey, everyone. I'm Srilakna. I'm a JavaScript engineer. And today I'm going to talk about a very interesting topic, JavaScript isn't slow, it's just scheduled wrong. I know the title is a bit dramatic, but soon we will find out why I've said that.

So I have prepared a small demo to introduce myself. So let me go at the demo part. I'm very excited for that. So here's my demo. On clicking on one or no more, you will see a short introduction of myself. And this test responsiveness and counter is for the later demo purpose.

So let me click on the button. Wait, what happened? The counter froze for a moment, right? OK, let me do it again. One or no more. Test responsiveness button is not clickable for a moment. What is happening? I was not prepared for that. OK, let me calm myself down and try to fix this. I can do this. So I will start with checking at the console tab if there is any error or not. So let me do that at first. Console and I'm refreshing. One or no more. Test responsiveness. No, there is no error in the console. So I don't have any network call. So I'm skipping the network tab too. This is something related to lag. So I think performance tab can help us. So let me go at the performance tab and. Again, start recording.

Test responsiveness. OK, stop. OK, we can see a very long yellow mountain. I know what is this for? Actually, I have a synchronous heavy computation, but actually used chunking for that so that it doesn't block the main thread. But this doesn't work, actually, somehow. These are the compute chunk method. And I can see this is, I think, the button click for test responsiveness. Let me check. So. Yes, function call. Yes, this is the test responsiveness button click. And I was actually expecting this button to be registered somewhere in between the compute chunk, in between two compute chunks. But this is not actually happened.

Entire block of JavaScript, heavy JavaScript was executed completely. Then this registered and the set interval for the counter is getting registered. And I know, I think I know why is this happening. OK, so before I explain this to you people, let me quickly summarize what is happening in here. So heavy computation block the entire main thread, though I have used chunking to prevent that from happening. And second is a user click, which should have the highest priority. That is not getting properly registered. That is registered after the entire heavy execution is done. And from this performance visualization, we can clearly see one thing that something is wrong with JavaScript scheduling and task prioritization.

Before we move far with this debugging, we should remember two important things about JavaScript that JavaScript is single threaded, means JavaScript uses one thread, single thread to perform tasks, logic, UI of desk and JavaScript uses cooperative scheduling. Means if JavaScript is currently executing something and I go to JavaScript telling like, please execute my task, JavaScript will tell me let me finish my task first, then I will schedule or execute yours. This is actually the basic concept of cooperative scheduling. And when we are talking about cooperative scheduling, let us quickly check how the priority model that JavaScript uses behind. So at the very first is do not yield. This is reserved for the synchronous codes that this runs fully to completion has the highest priority. Next is the next highest priority has micro tasks.

Next is the next highest priority has micro tasks. These are promise callbacks, mutation observers. This run next. After that, the third highest priority is request animation frame. Callbacks that run just before the next three pins. It has the third highest priority. After that, interframe tasks, normal tasks like timer functions, fetch callbacks, this kind of task falls under this category. This runs at ordinary priority. And at the very last is request idle callback. This has the lowest priority, means when the thread is in the idle state, only then this kind of task will get executed. So this is the hierarchical structure of web priorities.

Even though I've used chunking to prevent this heavy task getting blocked, the main thread as JavaScript is single threaded and uses cooperative scheduling. JavaScript is like complete the entire execution of the heavy task first, and then it will check for the next highest prioritized task. We developers clearly have no control to tell JavaScript that after you will complete this chunk, after you will complete executing a particular chunk, please execute this user click, and then you can continue with the next chunk. This inflexibility is the problem with JavaScript. And this is not how fast JavaScript is, but how inflexible the JavaScript scheduling model has been.

There are options like set timeout and request idle callback, but they have limitations. Set timeout is just a timer function without task prioritization or interruption capabilities. Request idle callback runs only when the thread is in idle mode, which may not happen during constant user interaction, leading to unpredictability. Dependence on these options is unreliable due to their constraints. These insights highlight the challenges in task prioritization and interruption within JavaScript's scheduling model.

So no set timeout can't. Then request idle callback. We have seen the priority hierarchy. It runs when the thread is in idle mode. Think about the situation. If the user is constantly interacting with the browser, then there is no idle mode for the thread. So the task will never run. So complete unpredictability. So these two options, we cannot depend on these two. So this is actually a real scheduling problem and we need a real solution for this.

No workarounds like using web workers when that is not even needed or showing a sync of it at everything. No, a real solution. Well, if you would have asked me this some years ago, I would say no. But today, yes, we have the answer. JavaScript has released a brand new family of scheduler APIs. And today we are going to talk about the most important one and most prioritized one. That is post task.

So what is post task? It is a promise based scheduling API that lets you queue your work with a specific priority. And this priority influences how browsers, event loops schedules it. So this is how the syntax it is. We will see about this syntax a few moments later. Another important thing is currently this is available in Chromium based browsers. Polyfill exists though. And Safari and Firefox, non Chromium based browsers are also tracking this. This is a breadth of scheduler API.

So next important thing is how it works internally. So it uses a global task queue. So first question, what is task queue? Task queue is a queue where tasks means JavaScript function you want the browser to run. Wait for data. And when we use scheduler.postTask, you are inserting a task into one of these queues.

And each task queue has a specific priority level from the syntax. We have a glimpse of the priority. So there are three kinds of priorities. User blocking, user visible and background. User blocking has the highest priority and reserve for user clicks and important tasks. Next is user visible with medium priority and default for post task. Background task is lowest priority for non-visual and heavy computation tasks.

Another important thing is when you post a task, it inherits the priority of the queue you placed it in. A task in the background queue is treated as low priority and yields to more important work. This gives a clear understanding of how the post task API works. The syntax of the post task API is quick and implementing it practically is the next step in the process.

And a task, as I said, in the background queue is treated as a low priority and will yield to more important work. So we clearly have an understanding of how this post task API works. And this is the syntax of the post task API, just a quick syntax. Let me implement them in my code, enough of the theoretical part.

So what I will do, this is my compute chunk function. Here, I have this long synchronous block of heavy computation. I will wrap this compute chunk with the scheduler API as it is a promise-based function. So I use a sink of it and enable the appropriate button for this.

Yes, this is what I was expecting, and it is working just as I expected. No UI lag, no frozen screen. Let me show you how this is getting placed in the main thread. First, let me refresh it again and click on this. This responsiveness stops. Now, we are seeing multiple chunks, and I'll explain what is happening here. Every compute chunk is wrapped with this post task priority, and we will see the interaction button. Click somewhere in here. Let me check if the click function is called. Yes, this is the event.

This responsiveness stop. OK, so now we are seeing, actually, there are multiple of chunks. And I'll explain what is happening in here. So this is every compute chunk is wrapped with this post task priority. And we will see the interaction button. Click somewhere in here.

Yes. In here. So. Let me check. Even click function called. Yes, this is the event. So what is happening here as we have wrapped the compute chunk with this post task with priority background, it is treating them as a lowest priority task. So when it first started the compute chunking and then when the user click enters, then it gives user click the space of its own.

And after the processing of the user click, then it again starts the compute chunks functions or computing the chunks, individual chunks. And yes, we have prevented the UI freeze and lagging. So we are at the very end of our session and we made JavaScript fast again. See, JavaScript is an inherently slow. Its default scheduling is just rigid.