JavaScript in the Background

The Background

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
JavaScript in the Background

Check out a free preview of the full JavaScript in the Background course

The "The Background" Lesson is part of the full, JavaScript in the Background course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano discusses an introduction to the background, including what's considered background for code execution and a diagram displaying the process of ios code execution. Examples of why to care about the background, including improving user experience, saving resources, stopping timers, and aborting pending requests, are also covered in this segment.


Transcript from the "The Background" Lesson

>> Okay so JavaScript in the background. When I ask about the background, people typically thinks about something like this, it's like a mist. So no one really sees what's going on, no one is really clear about what's going on about the background. In fact, we need to reveal the mystery because there is a mystery behind background JavaScript.

So what's going on, what happens, what happens when you close your app, when you minimize your app? So it's not so clear and we as web developers, typically, we never care too much about that. Coz yeah, the website is there and the website is gone and it's not so simple, it's not so boolean.

In classic web development, so I've been in the web space for more than 25 years. So in classic web development, actually you were opening the browser or the user was opening the browser and then something was there. So your actual JavaScript code was active and then at one point the user was closing the browser or closing the tab or closing the window and that's all.

So for our mindset, JavaScript means the user has that website, that web uploaded in the browser. But if that idea is still valid, because there are so many situations out there that sometimes we don't think about and that will improve user experience, performance, and also battery usage on users' devices.

So first, what's background? How can we define background? What do you think? Does anyone has an idea or definition, what's background?
>> Separate from the main thread.
>> Separate from the main thread, okay, what else do you think?
>> When the tab is not the one in the foreground in your browser.

>> When the tab is not in the foreground, okay, what else? As you can see that we have two definitions that are completely different. So he was talking about the thread, you were talking about, like OS, Windows.
>> Or when the browser is not in the foreground.
>> Or the browser is not in the foreground.

So yeah, we're going to, it can be within the browser itself. Like a background tab, or it can be within the OS like the browser is actually not in the foreground. And what about if we close the browser? What happens with our code? I mean the simple answer is like yeah, it's killed.

Okay, but it's not so simple. So in fact, we don't have a definition of what background means for web apps. So I mean, if we go for example, to the W3C, we don't have a definition. In fact, there are many definitions. In different specs, you will find many different definitions of what background means, which is a problem.

So because it's not completely clear what background is. So there are many concepts around. For example, the W3C, sometimes it's talking about threading. Okay, as you said, so a thread or web worker seems to be working in the background but from an OS perspective, is that the background or is that the thread?

So it's not simple what background means. That's the first thing that I wanna mention here, it's not actually simple. And if we go to the W3C talking about the specs, there are many concepts that are actually close to the idea of a background. For example, when you hide or minimize, it can be the tab or it can be actually the browser.

And typically we think that yeah, things are in memory and with execution rights. So my website, my JavaScript code, my context, my global context is still in memory. And because the browser is still there, the tab is still there, we think that yeah, we might have execution rights.

So if I have a timer, or if I have a like an event loop, is it still working? Then there are other ideas such as suspend or freeze. That in this case, my global context is still in memory but maybe I don't have execution rights, so I'm completely frozen.

And then it's the other idea or names or verbs that we can find in different specs is that what happens if we close, if OS kills or if the browser discards my web content that now it's not in memory anymore. Okay, so we will try to understand all these situations to actually get a simpler definition for us for background execution.

So, but I wanna maybe emphasize right now, that most of the time when we are talking about the background, we are mostly talking about being in the foreground or being in the background. And that has no direct relationship with threading. But it's true that sometimes we talk about threading when we say, okay, I want to execute this in the background.

But that means that in this case, in the case of JavaScript, you create the web worker. And if you go to the web worker spec, you will never see a different like a mentioned to the background work when talking about thread. Anyway, so we will try to simplify it, for us, because, yeah, the workshop's called JavaScript in the background, so we need to actually get some kind of a definition.

So let's say that for now or for us today, the background is when the user stops or pauses the usage of the web app. It can be for many reasons. Many reasons, and we will see a lot of different reasons. But that means that the user made a decision, the user is not using the web app anymore.

It can be temporarily or forever, I don't know. Actually, the process is really complex, we're not going to get into this diagram or to understand that. By the way, that's the diagram on iOS What happens with a web app or a PWA on iOS? All the possibilities, no worries, we will simplify this but just to give you an idea all the possibilities that we have in terms of background execution or foreground execution of your code.

So, we will understand what happened on most situations, how to handle it properly and how to increase the opportunity to execute code. Why do we wanna execute code? Many reasons we will see a couple okay. So why should we care about this? Well, first, to improve user experience, probably you have seen this in action.

You go to a website, you get out of the website and you minimize the window, you go somewhere else. You come back to the website and maybe the website is outdated, the website refreshes itself. The website was still thinking that you were there for an hour, and maybe you have a timer or even it can be a game, and the game was still playing while in the background.

And those are user experience problems that we can solve if we actually understand what's going on and how to improve user experience. We can also save resources. That means devices resources, that's memory, server resources because for example we can close socket connections, we can stop sending data to the server that we won't use for example, okay, that by default, maybe this is still happening.

So you're wasting your server's resources, not just users resources, and that means also battery. So we can stop timers. If you have a timer that is updating the UI every minute or every 10 seconds, you should start thinking about, okay, on some situations we may wanna stop the timer for several reasons that we will see in a minute.

And also to avoid pending requests. Because sometimes the problem is that we end up with some kind of broken transactions. Because what happens if you start a fetch to the server? So you wanna send data to the server, in the middle of that operation, the user let's say press the Home Screen button on the phone.

What happens with that pending request? Is it still going? Is it abort? We don't have control of that and actually there is no simple answer to that. Because it depends on the browser, it depends on OS. So maybe we wanna get control of what's going on those situations.

So that's why we care about JavaScript in the background, and we should care. Push notification is probably one of the things that most people want right now but because Apple is on finally. So actually I gave more than 20 Web Push workshops but those workshops were between 2018 and 2020.

So, the pandemic was also Apple saying no to Web Push. So no one cared about web push for a while for the last few years. And now that interest is coming back, because Safari supporting Web Push. Okay, we'll talk about that later. And also iOS support for Web Push is coming next year.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now