Forem: Felix Gerschau

JavaScript Event Loop And Call Stack Explained

Felix Gerschau — Mon, 05 Oct 2020 09:36:45 +0000

Originally published on my blog: JavaScript Event Loop And Call Stack Explained

My goal with this article is to teach you how JavaScript works in the browser. Even though I've been working with JavaScript my whole career, I didn't get how these things work until recently.

I still forget how this works from time to time. That's why I wrote this article. I hope it will make you understand these concepts as well.

I want to make this article as easy to understand as possible. If you have any open questions, please send me an email or leave a comment. I will try to help you and improve the article with your feedback.

How JavaScript works in the browser

Before I dive into the explanation of each topic, I want you to have a look at this high-level overview that I created, which is an abstraction of how JavaScript interacts with the browser.

Don't worry if you don't know what all of the terms mean. I will cover each of them in this section.

Note how most of the things in the graphic aren't part of the JavaScript language itself. Web APIs, the callback queue, and the event loop are all features that the browser provides.

A representation of NodeJS would look similar, but in this article, I'll focus on how JavaScript works in the browser.

Call stack

You've probably already heard that JavaScript is single-threaded. But what does this mean?

JavaScript can do one single thing at a time because it has only one call stack.

The call stack is a mechanism that helps the JavaScript interpreter to keep track of the functions that a script calls.

Every time a script or function calls a function, it's added to the top of the call stack.
Every time the function exits, the interpreter removes it from the call stack.

A function either exits through a return statement or by reaching the end of the scope.

Every time a function calls another function, it's added to the top of the stack, on top of the calling function.

The order in which the stack processes each function call is following the LIFO principle (Last In, First Out).

The steps of the previous example are the following:

The file loads and the main function is being called, which stands for the execution of the entire file. This function is added to the call stack.
main calls calculation(), which is why it is added to the top of the call stack.
calculation() calls addThree(), which again is added to the call stack.
addThree calls addTwo, which is added to the call stack.

...

addOne doesn't call any other functions. When it exits, it is removed from the call stack.
With the result of addOne, addTwo exits as well and is being removed from the call stack.
addThree is being removed as well.
calculation calls addTwo, which adds it to the call stack.
addTwo calls addOne and adds it to the call stack.
addOne exits and is being removed from the call stack.
addTwo exits and is being removed from the call stack.
calculation can exit now with the result of addThree and addTwo and is being removed from the call stack.
There are no further statements or function calls in the file, so main exits as well and is being removed from the call stack.

I called the context that executes our code main, but this is not how the official name of the function. In the error messages that you can find in the browser's console, the name of this function is anonymous.

Uncaught RangeError: Maximum call stack size exceeded

You probably know the call stack from debugging your code. Uncaught RangeError: Maximum call stack size exceeded is one of the errors you might encounter. Below we can see a snapshot of the callstack when the error occured.

Follow the stack trace of this error message. It represents the functions calls that led to this error. In this case, the error was in the function b, which has been called by a (which has been called by b and so on).

If you see this specific error message on your screen, one of your function has called too many functions. The maximum call stack size ranges from 10 to 50 thousand calls, so if you exceed that, it's most likely that you have an infinite loop in your code.

The browser prevents your code from freezing the whole page by limiting the call stack.

I re-created the error with the following code. A way to prevent this is by either not using recursive functions in the first place, or by providing a base case, which makes your function exit at some point.

function a() {
    b();
}

function b() {
    a();
}

a();

In summary, the call stack keeps track of the function calls in your code. It follows the LIFO principle (Last In, First Out), which means it always processes the call that is on top of the stack first.

JavaScript only has one call stack, which is why it can only do one thing at a time.

Heap

The JavaScript heap is where objects are stored when we define functions or variables.

Since it doesn't affect the call stack and the event loop, it would be out of the scope of this article to explain how JavaScript's memory allocation works.

I plan to write a blog post on this topic. If you haven't already, make sure to subscribe to my newsletter to get notified when it's out.

Web APIs

Above, I said that JavaScript can only do one thing at a time.

While this is true for the JavaScript language itself, you can still do things concurrently in the browser. As the title already suggests, this is possible through the APIs that browsers provide.

Let's take a look at how we make an API request, for instance. If we executed the code within the JavaScript interpreter, we wouldn't be able to do anything else until we get a response from the server.

It would pretty much make web applications unusable.

As a solution to this, web browsers give us APIs that we can call in our JavaScript code. The execution, however, is handled by the platform itself, which is why it won't block the call stack.

Another advantage of web APIs is that they are written in lower-level code (like C), which allows them to do things that simply aren't possible in plain JavaScript.

They enable you to make AJAX requests or manipulate the DOM, but also a range of other things, like geo-tracking, accessing local storage, service workers, and more.

If you're interested in what new APIs we can expect to surface in the future, check out my article on project Fugu, a cross-company effort, brought to life by Google, that intents to bring more native features to the web platform.

Callback queue

With the features of web APIs, we're now able to do things concurrently outside of the JavaScript interpreter. But what happens if we want our JavaScript code to react to the result of a Web API, like an AJAX request for instance?

That's where callbacks come into play. Through them, web APIs allow us to run code after the execution of the API call has finished.

What is a callback?

A callback is a function that's passed as an argument to another function. The callback will usually be executed after the code has finished.

You can create callback functions yourself by writing functions that accept a function as an argument. Functions like that are also known as higher-order functions. Note that callbacks aren't by default asynchronous.

Let's have a look at an example:

const a = () => console.log('a');
const b = () => setTimeout(() => console.log('b'), 100);
const c = () => console.log('c');

a();
b();
c();

setTimeout adds a timeout of x ms before the callback will be executed.

You can probably already think of what the output will look like.

setTimeout is being executed concurrently while the JS interpreter continues to execute the next statements.

When the timeout has passed and the call stack is empty again, the callback function that has been passed to setTimeout will be executed.

The final output will look like this:

a
c
b

But what about the callback queue?

Now, after setTimeout finishes its execution, it doesn't immediately call the callback function. But why's that?

Remember that JavaScript can only do one thing at a time?

The callback we passed as an argument to setTimeout is written in JavaScript. Thus, the JavaScript interpreter needs to run the code, which means that it needs to use the call stack, which again means that we have to wait until the call stack is empty in order to execute the callback.

You can observe this behavior in the following animation, which is visualizing the execution of the code we saw above.

Calling setTimeout triggers the execution of the web API, which adds the callback to the callback queue.
The event loop then takes the callback from the queue and adds it to the stack as soon as it's empty.

Multiple things are going on here at the same time. Follow the path that the execution of setTimeout takes, and in another run, focus on what the call stack does.

Unlike the call stack, the callback queue follows the FIFO order (First In, First Out), meaning that the calls are processed in the same order they've been added to the queue.

Event loop

The JavaScript event loop takes the first call in the callback queue and adds it to the call stack as soon as it's empty.

JavaScript code is being run in a run-to-completion manner, meaning that if the call stack is currently executing some code, the event loop is blocked and won't add any calls from the queue until the stack is empty again.

That's why it's important not to block the call stack by running computation-intensive tasks.

If you execute too much code or clog up your callback queue, your website will become unresponsive, because it's not able to execute any new JavaScript code.

Event handlers, like onscroll, add more tasks to the callback queue when triggered. That's why you should debounce these callbacks, meaning they will only be executed every x ms.

See it for yourself

Add the following code to your browser console. As you scroll, you can observe how often the callback prints scroll.
window.onscroll = () => console.log('scroll');

setTimeout(fn, 0) or setImmediate()

We can take the above-described behavior to our advantage if we want to execute some tasks without blocking the main thread for too long.

Putting your asynchronous code in a callback and setting setTimeout to 0ms will allow the browser to do things like updating the DOM before continuing with the execution of the callback.

Job queue and asynchronous code

In the overview that I showed in the beginning, I was leaving out one additional feature that's important to know.

In addition to the callback queue, there's another queue that exclusively accepts promises‚Äîthe job queue.

Promises: A quick recap

EcmaScript 2015 (or ES6) first introduced promises, even though it has been available before in Babel.

Promises are another way of handling asynchronous code, other than using callbacks. They allow you to easily chain asynchronous functions without ending up in what's called callback hell or pyramid of doom.

setTimeout(() => {
  console.log('Print this and wait');
  setTimeout(() => {
    console.log('Do something else and wait');
    setTimeout(() => {
      // ...
    }, 100);
  }, 100);
}, 100)

With a but of imagination, you can see how chaining callbacks can end up in a pyramid of doom‚Äîor straight ugly code.

With promises, this code can become much more readable:

// A promise wrapper for setTimeout
const timeout = (time) => new Promise(resolve => setTimeout(resolve, time));
timeout(1000)
  .then(() => {
    console.log('Hi after 1 second');
    return timeout(1000);
  })
  .then(() => {
    console.log('Hi after 2 seconds');
  });

This code looks even more readable with the async/await syntax:

const logDelayedMessages = async () => {
  await timeout(1000);
  console.log('Hi after 1 second');
  await timeout(1000);
  console.log('Hi after 2 seconds');
};

logDelayedMessages();

That was a quick recap on how promises work, but in this article, I won't dive deeper into this topic.
Check out the MDN web docs in case you want to learn more about them.

Where do promises fit in?

Why am I talking about promises here?

Having the bigger picture in mind, promises behave a little differently than callbacks because they have their own queue.

The job queue, also known as the promise queue, has priority over the callback queue, just like a fast-track queue at an amusement park.

The event loop will take calls from the promise queue first, before processing the callback queue.

Let's have a look at an example:

console.log('a');
setTimeout(() => console.log('b'), 0);
new Promise((resolve, reject) => {
  resolve();
})
.then(() => {
  console.log('c');
});
console.log('d');

Taking into consideration your knowledge about how callback queues are working, you might think that the output will be a d b c.

But because the promise queue has priority over the callback queue, c will be printed before b, even though both are asynchronous:

a
d
c
b

Conclusion

I hope you now have a better understanding of what is happening behind the scenes of your JavaScript code. As I already mentioned in the beginning, if you have any questions or feedback please leave a comment.

I've learned this stuff on the internet as well, here are the resources that have helped me grasp this topic:

What the heck is the event loop anyway? | Philip Roberts

The best talk/video out there on this topic. I highly recommend you check it out.

A tools that lets you visualize how your code is being executed.

More artiles you might be interested in:

My 9 favorite topics of "The Pragmatic Programmer"

Reading is a great way of improving your programming skills. In this article, I share my key-takeaways of my favorite programming book.

How to Make your React App a Progressive Web App (PWA)

A full walk-through of how you can make your React app a Progressive Web App (it's easier than it sounds).

Measuring the Performance of JavaScript Functions

Felix Gerschau — Sun, 03 May 2020 10:20:04 +0000

This post was first published on my blog.

Measuring the time it takes to execute a function is always a good idea to prove that some implementation is more performant than the other. It's also a good way to ensure that performance didn't suffer after some change and to track down bottlenecks.

Good performance contributes to good user experience. And a good user experience makes users come back. Like this research for example shows, 88% of online consumers are less likely to return after a poor user experience due to performance issues.

That's why it's important to be able to recognize bottlenecks in your code and measure the improvements. Especially when developing JavaScript for the browser it's important to be aware that every line of JavaScript you write can potentially block the DOM since it's a single-threaded language.

In this article, I will explain how you can measure the performance of your functions and what to do with the results, you get from them.

The functions I mention here are good for debugging JavaScript functions at a low level. If you want to make sure that your application stays fast, even after more features get added, consider the implementation of a performance budget.

Perfomance.now

The performance API provides access to the DOMHighResTimeStamp through its function performance.now(), which returns the time passed since the page loaded in milliseconds, with a precision of up to 5µs (in the fractional).

So in practice you need to take two timestamps, save them in a variable and then rest the second from the first one:

const t0 = performance.now();
for (let i = 0; i < array.length; i++) 
{
  // some code
}
const t1 = performance.now();
console.log(t1 - t0, 'milliseconds');

Output (Chrome):

0.6350000001020817 "milliseconds"

Output (Firefox):

1 milliseconds

Here we can see that the result in Firefox is quite different to Chrome. This is because Firefox, as of version 60, is reducing the precision of the performance API to 2ms. You can find more information about this at the end of this post.

The performance API offers much more functionality than only returning a timestamp. It's able to measure navigation timing, user timing or resource timing.
Check this article out which explains it more in detail.

For our use-case, however, we only want to measure the performance of a single function so a timestamp will be enough.

Isn't that the same as Date.now?

Now you could think, hey, I could also use Date.now for that.

Yes you can, but that has drawbacks.

Date.now returns, in milliseconds, the time passed since the Unix epoch ("1970-01-01T00:00:00Z") and depends on the system clock. This doesn't only mean that it's not as precise, but it's also not always incrementing. Here's how a WebKit engineer (Tony Gentilcore) explains it:

Perhaps less often considered is that Date, based on system time, isn't ideal for real user monitoring either. Most systems run a daemon which regularly synchronizes the time. It is common for the clock to be tweaked a few milliseconds every 15-20 minutes. At that rate about 1% of 10 second intervals measured would be inaccurate.

Console.time

This API is really easy to use. Simply put console.time before and console.timeEnd after the code you want to measure, calling the function with the same string argument. You can use up to 10,000 timers simultaneously on one page.

The precision is the same as of the performance API but this again depends on the browser.

console.time('test');
for (let i = 0; i < array.length; i++) {
  // some code
}
console.timeEnd('test');

This automatically generates a human-readable output like the following:

Output (Chrome):

test: 0.766845703125ms

Output (Firefox):

test: 2ms - timer ended

The outputs here are again very similar to the performance API.

console.time has the advantage that it is easier to use since it doesn't require calculating the difference between two timestamps manually.

Reduced Time Precision

If you measure your function with the APIs mentioned above in different browsers you might notice that the results vary.

This is due to browsers trying to protect users against timing attacks and fingerprinting,
which can be used by hackers to identify users if the timestamp is too accurate.

Browsers like Firefox, for example, try to prevent this by reducing the precision to 2ms (version 60).

Things to Keep in Mind

Now you have the tools you need to measure how fast your JavaScript functions are. But there are some pitfalls that are better to be avoided:

Divide and Conquer

You noticed something is slow when filtering some results but you don't know where the bottleneck is.

Instead of making wild guesses what part of the code is slow, you can use these above-mentioned functions to measure it.

To trace it down first place your console.time statements around the block of code that is slow. Then measure how different parts of them perform. If one is slower than the others, continue there and go deeper every time until you find the bottleneck.

The less code you have between those statements, the less likely it is that you're tracking something you're not interested in.

Be Aware of the Input Values

In a real-world application, the input values of a given function can change a lot. Just measuring the speed of the function for any random value doesn't give us any valuable data we can actually use.

Be sure to run your code with the same input values.

Run the Function Multiple Times

Let's say you have a function that iterates over an array, does some calculations with each of its values and returns an array with the results. You want to find out whether forEach or a simple for loop is more performant.

Those are the functions:

function testForEach(x) {
  console.time('test-forEach');
  const res = [];
  x.forEach((value, index) => {
    res.push(value / 1.2 * 0.1);
  });

  console.timeEnd('test-forEach')
  return res;
}

function testFor(x) {
  console.time('test-for');
  const res = [];
  for (let i = 0; i < x.length; i ++) {
    res.push(x[i] / 1.2 * 0.1);
  }

  console.timeEnd('test-for')
  return res;
}

And you test them like this:

const x = new Array(100000).fill(Math.random());
testForEach(x);
testFor(x);

If you run the above functions in Firefox you'll get an output similar to this:

test-forEach: 27ms - timer ended
test-for: 3ms - timer ended

Looks like forEach is way slower, right?

Let's have a look if we run the same functions twice, using the same input:

testForEach(x);
testForEach(x);
testFor(x);
testFor(x);

test-forEach: 13ms - timer ended
test-forEach: 2ms - timer ended
test-for: 1ms - timer ended
test-for: 3ms - timer ended

If we call the forEach test a second time it performs just as well as the for loop. It's probably not worth using forEach anyway, given the slower initial value.

...and in multiple browsers

If we run the above code in Chrome the result suddenly looks different:

test-forEach: 6.156005859375ms
test-forEach: 8.01416015625ms
test-for: 4.371337890625ms
test-for: 4.31298828125ms

That's because Chrome and Firefox have different JavaScript engines have different kind of performance optimizations. It's good to be aware of these differences.

In this case, Firefox is doing a better job of optimizing the use of forEach with the same input.

for performs better on both engines so it's probably better to stick to the for loop.

This is a good example of why you should measure in multiple engines. If you only measured in Chrome you might have come to the conclusion that forEach is not so bad in comparison to for.

Throttle your CPU

Those values don't seem like much. Be aware that your development machine is usually much faster than the average mobile phone that your website is being viewed on.

To get a feeling of how this looks like, browsers have a feature that lets you throttle your CPU performance.

With this those 10 or 50ms quickly become 500ms.

Measure Relative Performance

These raw results actually don't only depend on your hardware but also on the current load on your CPU and your JavaScript thread. Try to focus on the relative improvement of your measurements since these numbers can look very different the next time you restart your computer.

Conclusion

In this article, we have seen some JavaScript APIs we can use to measure performance and then how to use them in the "real world". For simple measurements, I find that it's easier to use console.time.

I feel like many frontend developers don't give enough thought to performance on a daily basis, even though it has a direct impact on revenue.

How do you make sure that you don't forget about performance in daily business? Feel free to send me an email or tweet with your ideas!

How to communicate with Service Workers

Felix Gerschau — Sat, 22 Feb 2020 11:24:40 +0000

First published on my blog

MessageChannel, Broadcast API and Client API compared

Service Workers are great. They allow web developers to implement native-like features that before were exclusive to native applications. Such features are for example push notifications or background syncs for offline capabilities.

They are the core of progressive web apps. But after setting them up it seems to be difficult to do more complex things that involve interaction with your web application.

In this post, I'll showcase the options that are available and compare them in the end.

Service Workers vs Web Workers

If you look up the API of Service Workers you will see that Web Workers and Service Workers actually have very similar interfaces. But despite their similarities, their intent and capabilities are very different:

Service Workers can intercept requests and replace them with items from their own cache, thus they behave like a proxy server. They offer offline capabilities to web applications.
They can be used across multiple tabs and even continue to be alive when all tabs are closed.
Web workers, on the other hand, have a different purpose. They offer multi-threading to the single-threaded JavaScript language and are used for performing computation heavy tasks that should not interfere with the responsiveness of the UI.
They are limited to only one tab.

Both of them have in common that they don't have access to the DOM and communicate using the postMessage API. You can think of them as Web Workers with expanded capabilities.

If you want to learn more about these two, check out this talk which, event though is a little old, gives a good overview of this topic. Being 2020, the browser support of Service Workers has improved a lot.

How to talk to Service Workers

Select the Service Worker you want to send a message to

For any origin, it is possible to have multiple Service Workers. The following returns the active Service Worker that currently controls the page:

navigator.serviceWorker.controller

If you want to access other Service Workers you can access them through the registration interface, which gives you access to Service Workers in the following states:

ServiceWorkerRegistration.installing
ServiceWorkerRegistration.waiting - This Service Worker is installed but not active yet
ServiceWorkerRegistration.active - This Service Worker is controlling the current page

You can get access to the registration interface in a few different ways. One of them is calling navigator.serviceWorker.ready.
This returns a promise that resolves with a registration:

navigator.serviceWorker.ready.then((registration) => {
  // At this point, a Service Worker is controlling the current page
});

Have a look at this article if you want to learn more about the lifecycle
of Service Workers.

Send the message

As I already mentioned, Service Workers communicate through the postMessage API. This doesn't only allow them to exchange data with the JavaScript main thread, but it's also possible to send messages from one Service Worker to another.

// app.js - Somewhere in your web app
navigator.serviceWorker.controller.postMessage({
  type: 'MESSAGE_IDENTIFIER',
});

// service-worker.js
// On the Service Worker side we have to listen to the message event
self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'MESSAGE_IDENTIFIER') {
    // do something
  }
});

A use case for this one-way communication would be to call skipWaiting in the waiting Service Worker, which will then pass on to become active and control the page. This is already implemented in the Service Worker that is shipped with Create-React-App. I used this technique for showing an update notification in a progressive web app, which I explain in this post.

But what if you want to send a message back to the Window context or even to other Service Workers?

Service Worker - Client communication

There are a few ways of sending messages to the client(s) of a Service Worker:

Broadcast Channel API, which allows communication
between browsing contexts. This API allows communication between contexts without a reference.
This is currently supported for Chrome, Firefox, and Opera. Set's up a many to many broadcast communication.
MessageChannel API
It can be used to set up a 1-to-1 communication between the Window and the Service Worker context.
The Clients interface of the Service Worker
It can be used for broadcasting to one or more clients of the Service Worker.

I'll give you a short example of each of them and then compare them to each other to see which one might be the best for your use case.

I didn't include FetchEvent.respondWith()
since this only applies to fetch events and is currently not supported by Safari.

Using the MessageChannel API

As the name already tells us, the MessageChannel API sets up a channel through which messages can be sent.

The implementation can be boiled down to 3 steps.

Set up event listeners on both sides for the 'message' event
Establish the connection to the Service Worker by sending the port and storing it in the Service Worker.
Reply to the client with the stored port

A fourth step could be added if we want to close the connection by calling port.close() in the Service Worker.

In practice that looks something like this:

// app.js - somewhere in our main app
const messageChannel = new MessageChannel();

// First we initialize the channel by sending
// the port to the Service Worker (this also
// transfers the ownership of the port)
navigator.serviceWorker.controller.postMessage({
  type: 'INIT_PORT',
}, [messageChannel.port2]);

// Listen to the response
messageChannel.port1.onmessage = (event) => {
  // Print the result
  console.log(event.data.payload);
};

// Then we send our first message
navigator.serviceWorker.controller.postMessage({
  type: 'INCREASE_COUNT',
});

// service-worker.js
let getVersionPort;
let count = 0;
self.addEventListener("message", event => {
  if (event.data && event.data.type === 'INIT_PORT') {
    getVersionPort = event.ports[0];
  }

  if (event.data && event.data.type === 'INCREASE_COUNT') {
    getVersionPort.postMessage({ payload: ++count });
  }
}

Using the Broadcast API

The Broadcast API is very similar to the MessageChannel but it takes away the need to pass the port to the Service Worker.

In this example, we see that we just need to set up a channel on both sides with the same name count-channel.

We could add the same code to other WebWorkers or Service Workers who will receive all those messages then as well.

Here we see the same example from above but with the Broadcast API:

// app.js
// Set up channel
const broadcast = new BroadcastChannel('count-channel');

// Listen to the response
broadcast.onmessage = (event) => {
  console.log(event.data.payload);
};

// Send first request
broadcast.postMessage({
  type: 'INCREASE_COUNT',
});

// service-worker.js
// Set up channel with same name as in app.js
const broadcast = new BroadcastChannel('count-channel');
broadcast.onmessage = (event) => {
  if (event.data && event.data.type === 'INCREASE_COUNT') {
    broadcast.postMessage({ payload: ++count });
  }
};

Using the Client API

The Client API also doesn't require to pass a reference to the channel.

On the client-side, we listen to the response of the service worker and in the Service Worker we select the client we want to send the response to with the filter options that the self.clients.matchAll function provides us.

// app.js
// Listen to the response
navigator.serviceWorker.onmessage = (event) => {
  if (event.data && event.data.type === 'REPLY_COUNT_CLIENTS') {
    setCount(event.data.count);
  }
};

// Send first request
navigator.serviceWorker.controller.postMessage({
  type: 'INCREASE_COUNT_CLIENTS',
});

// service-worker.js
// Listen to the request
self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'INCREASE_COUNT') {
    // Select who we want to respond to
    self.clients.matchAll({
      includeUncontrolled: true,
      type: 'window',
    }).then((clients) => {
      if (clients && clients.length) {
        // Send a response - the clients
        // array is ordered by last focused
        clients[0].postMessage({
          type: 'REPLY_COUNT',
          count: ++count,
        });
      }
    });
  }
});

Conclusion

The postMessage API offers a simple and flexible interface that allows us to send messages to Service Workers.

The Broadcast Channel API is the easiest-to-use option to respond to the client, but unfortunately, does not have very good browser support.

From the remaining two I like the Client API better since this doesn't require passing a reference to the Service Worker.