Snippets

Application lifecycle is a key way that modern operating systems manage resources. On Android, iOS, and recent Windows versions, apps can be started and stopped at any time by the OS. This allows these platforms to streamline and reallocate resources where they best benefit the user.

On the web, there has historically been no such lifecycle, and apps can be kept alive indefinitely. With large numbers of web pages running, critical system resources such as memory, CPU, battery, and network can be oversubscribed, leading to a bad end-user experience.

While the web platform has long had events that related to lifecycle states — like load, unload, and visibilitychange — these events only allow developers to respond to user-initiated lifecycle state changes. For the web to work reliably on low-powered devices (and be more resource conscious in general on all platforms) browsers need a way to proactively reclaim and re-allocate system resources.

In fact, browsers today already do take active measures to conserve resources for pages in background tabs, and many browsers (especially Chrome) would like to do a lot more of this — to lessen their overall resource footprint.

The problem is developers currently have no way to prepare for these types of system-initiated interventions or even know that they’re happening. This means browsers need to be conservative or risk breaking web pages.

The Page Lifecycle API attempts to solve this problem by:

• Introducing and standardizing the concept of lifecycle states on the web.
• Defining new, system-initiated states that allow browsers to limit the resources that can be consumed by hidden or inactive tabs.
• Creating new APIs and events that allow web developers to respond to transitions to and from these new system-initiated states.

This solution provides the predictability web developers need to build applications resilient to system interventions, and it allows browsers to more aggressively optimize system resources, ultimately benefiting all web users.

Attaching an event handler/listener to window or document’s beforeunload event prevents browsers from using in-memory page navigation caches, like Firefox’s Back-Forward cache or WebKit’s Page Cache.

Creates a new empty DocumentFragment into which DOM nodes can be added to build an offscreen DOM tree.

[…]

DocumentFragments are DOM Node objects which are never part of the main DOM tree. The usual use case is to create the document fragment, append elements to the document fragment and then append the document fragment to the DOM tree. In the DOM tree, the document fragment is replaced by all its children.

Since the document fragment is in memory and not part of the main DOM tree, appending children to it does not cause page reflow (computation of element’s position and geometry). Historically, using document fragments could result in better performance.

Many sites and apps have a lot of scripts to execute. Your JavaScript often needs to be run as soon as possible, but at the same time you don’t want it to get in the user’s way. If you send analytics data when the user is scrolling the page, or you append elements to the DOM while they happen to be tapping on the button, your web app can become unresponsive, resulting in a poor user experience.

[…]

The good news is that there’s now an API that can help: requestIdleCallback. In the same way that adopting requestAnimationFrame allowed us to schedule animations properly and maximize our chances of hitting 60fps, requestIdleCallback will schedule work when there is free time at the end of a frame, or when the user is inactive. This means that there’s an opportunity to do your work without getting in the user’s way.

[…]

Why should I use requestIdleCallback?

Scheduling non-essential work yourself is very difficult to do. It’s impossible to figure out exactly how much frame time remains because after requestAnimationFrame callbacks execute there are style calculations, layout, paint, and other browser internals that need to run. A home-rolled solution can’t account for any of those. In order to be sure that a user isn’t interacting in some way you would also need to attach listeners to every kind of interaction event (scroll, touch, click), even if you don’t need them for functionality, just so that you can be absolutely sure that the user isn’t interacting. The browser, on the other hand, knows exactly how much time is available at the end of the frame, and if the user is interacting, and so through requestIdleCallback we gain an API that allows us to make use of any spare time in the most efficient way possible.

If you find yourself wrestling with CSS layout, it’s likely you’re making decisions for browsers they should be making themselves. Through a series of simple, composable layouts, Every Layout will teach you how to better harness the built-in algorithms that power browsers and CSS.

Here’s a handy way to quickly generate a hash salt for a Drupal 8 install, provided you have Drush installed:

 drush eval "var_dump(Drupal\Component\Utility\Crypt::randomBytesBase64(55))"

Andy and I have put a lot of work and thought into Every Layout. We want it to be the best resource it can be. Naturally, we would like to be paid for the value we are giving you. However, we know that not everyone can afford the things they’d like to have. We’re trying to address this in two ways:

1. A large selection of free content, including all of the “rudiment” articles that cover the basics of (our take on) contemporary CSS
2. An honor system, wherein you can claim to be eligible for the full Every Layout for free

What makes you eligible for (2)? If you are currently out of work, you are a full-time student or under 19 years old, you are trying to get your first job as a web developer or designer, or you are an unpaid volunteer for a charitable organization not involved in proselytism: consider yourself a match. Also, if you are the sole person of your ethnicity, gender, or sexual orientation at your company or in your local developer community: we will gift Every Layout to you. If you have a disability that makes accessing equivalent resources difficult, you can have this resource for free. We are trying to make it as accessible as possible.

[…]

It would be logistically and ethically implausible for us to vet, or otherwise judge, if you deserve to have Every Layout without a charge. If you believe you fit into the criteria above, let us know. That’s the honor part.

Are we suckers? Perhaps, to some. But while you alone decide if you qualify, we decide if you disqualify. That is, if we see you saying or sharing racist, homophobic, transphobic, sexist, or fascist sentiments, or you’re caught engaging in what we consider, in any way, punching down, you get fuck all for free from us.