JavaScript in the Background

Web App Lifecycle

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
JavaScript in the Background

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

The "Web App Lifecycle" 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 the possible situations that impact a web application's life cycle and what happens on mobile OS life cycles. Unlike the desktop OS, where applications continue running in the background, on a mobile OS, applications are paused and do not consume resources.


Transcript from the "Web App Lifecycle" Lesson

>> Let's talk a little bit about the web app lifecycle, okay? Things that sometimes we don't think about when we are web developers. So let's talk about some possibilities. The user goes to a new tab. So, my tab is not on the screen anymore. User goes to a new window.

Can be a browser window or another window from the OS. The user minimizes the window. It can be also PWA, by the way, not just the browser. It can be an installed PWA window, so the user minimizes the window, the user closes the window with the X or with the red button, it depends on the OS.

The users closes the browser or the PWA standalone window. So all these are different situations that might impact what happens with our JavaScript code. Before actually getting into the answer of what's going on, I have a question for you. What happens on mobile operating systems with app's lifecycle in general?

So on Android, on iOS, do you have a close button? Have you ever seen an app with an exit menu or a close app menu? No, so it's like technically we never close apps. As web developer, typically we don't think too much about that. And what happens with that?

So let me get out of the presentation for a second. And I have here an iOS simulator. And I wanna show you something. Here, let me decrease the size a little bit, like so. So, how many of you on iOS or Android are actually doing this many times per day?

Like closing your app, swiping up or swiping right. So I have here a couple of yeses, and a couple of no. And for those of you saying yes, why are you doing it?
>> Clear the clutter.
>> Clear the clutter. What else? And why? Why do you care about that?

>> If I'm switching between app contexts, I like to have fewer things in front of-
>> Okay, or it's a mental organization. Cool, what else?
>> I don't close them but there is people say that it helps battery life but it doesn't actually.
>> It saves battery life.

Yeah, there are other people thinking that it will save battery life and it's not true, it's exactly the opposite of that. And that has to do with the life cycle of a mobile operating system with their apps. And our web apps are actually within that lifecycle. They can be a tab in the browser or they can be any standalone PWA.

It doesn't matter. It's actually the same. We are actually within that OS. So let's try to understand how that works. So, going back here, on a desktop operating system, it can be Linux, Windows, Mac OS, Chrome OS, typically when you are inside one app, so that's the orange one.

That's your app that is running, but you may have others. So that's the active app. The orange one is the active app. So you may have other apps that are also running. And they're all running, even if they are in the background or minimized or hidden somehow. If you press out tab, you change your active app, but your previous app, it's obviously running.

it's in the background but running, that's the next step operating system in general. When mobile appeared, we as users, we thought that was the case also for mobile. And that's why a lot of people are actually closing apps because they think that they're consuming resources. But that's not how they typically work.

On mobile operating systems this is a general idea, there are some exceptions but in general, you have one app that is running, the active app. And the other apps that you see in the multitask manager, are paused or suspended, different names to this. So they're not executing code.

And what you see in that Multitask manager is just screenshots of that app, not really like the current UI for the app, it's a screenshot. If you change your app, now you have another app that is active and your previous app goes to suspended mode. And there is no close, so users don't close apps.

So of course, this model has a problem, the memory is limited and we can't keep 100 apps open forever. So at one point the OS will need more memory for the current active app and it will actually kill some of the background apps. That process has different names, it depends on the OS, but it's actually pretty similar on Android and iOS.

On Android, it's a little bit more complex because we don't have just the concept of the app, we also have the concepts of an activity. But we are not going to get so deep on that today. But anyway, if the OS is actually killing your app, or destroying your app, or disposing your app, your app, it still appears as there.

So it's not removing the app from the list. You still see the screenshot. Because on mobile operating system task managers, what you see is actually some kind of navigation history. It's not really a task manager like in the OS tab. It's not the same. So having that in mind, now going back to web apps and JavaScript, we can be on any of these situations.

So our content can be actually in memory and running. Our content can be actually in memory and not running. That's the paused state on that diagram, or our content cannot be in memory at all. But for the user, it's still there. We see the screenshot so the user thinks that the content is still there, but it's not.

So, when we are doing web apps or websites in the browser, or when doing PWAs, we are going to see this in action. And we should care about this, again, to improve the user experience. Because what happens when the user goes back to our PWA or web app that was actually disposed?

The app will start from scratch. But the user was expecting something different because the screenshot was showing us something different. So that's why we need to understand the situation and do something about that.

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