Check out a free preview of the full Progressive Web Applications and Offline course:
The "Application Shell Pattern" Lesson is part of the full, Progressive Web Applications and Offline course featured in this preview video. Here's what you'd learn in this lesson:

Mike starts reviewing common PWA patterns by first examining the Application Shell Pattern, which focuses on the core components necessary for an app rather than data.

Get Unlimited Access Now

Transcript from the "Application Shell Pattern" Lesson

[00:00:00]
>> Mike North: So the last thing I want to talk about before we take some final measurements on our app and wrap up is a high level patterns for progressive web app architecture. So we've learned about a lot of different ingredients that we can put together in order to make our app work offline, background sync, notifications, terminate a service worker remotely, using those sequel database that's right in our browser, but how do we like adopt a pattern that we know works, right.

[00:00:30] We don't want to reinvent the wheel. So the first pattern I want to talk about is called App Shell. And we've actually been sort of using this the whole time, at least since we dealt with enhanced client-side rendering. If you remember, we grabbed some HTML, found the stuff that is visible on the screen no matter what URL we're on.

[00:00:50] We kind of started with that. And that would be, like, the shell, that is like the User interface elements of our applications. At least the top level user interface, right? No data is required in order for that to be rendered, and that's why we were able to start with that and get a sub one second initial paint.

[00:01:14] The second thing, the second part of this is stuff that is drawn within the shell and that would be our grocery items, right? If we start adding this stuff to our grocery item database we'll see new things showing up there.
>> Mike North: So here's an example using Twitter Lite, which is a great progressive web app that was released very recently.

[00:01:34] And they're doing well in emerging markets with this, where there's a lot of reluctance to install native apps on phones. And you can see here, we've got sort of the shell, highlighted in orange. And those are just the navigation elements, the core top-level actions available on the bottom.

[00:01:52] And then the tweets, that's the content that is rendered later. We need some dynamic thing, in order for that to work. And in terms of, if you've ever built a native mobile app, like often times you'll have that frame showing, your app bar that'll render first, and then you'll kind of wait for your content to come in and render that as a second step.

[00:02:15] This is just adopting that same pattern. So, it's pretty easy to see where the line between the shell and the content is here. Mostly because we already kind of extracted it out.
>> Mike North: So the idea here is that we can cache the App Shell with the Service Worker as we have been.

[00:02:39] But the key change that we can make in order to truly adopt App Shell is that even in the event that we're online, we will render that shell first before going to the network to get like HTML content potentially that we can render in the app. So in theory, we don't have to have that bias.

[00:03:01] We just have to flip the bias essentially, where for the index.html stuff, we could hit the cache first and then only go to the network in the event that the cache is empty. Because honestly, index.html is not changing much. Now, in order for this to work, you have to have a way of getting a new index.html to the browser, in the background.

[00:03:22] Because if we were to use the cache first, we'd be sort of in an app cache territory, where we're never seeing a new version of our app deployed. We never like get rid of the cache, we never find a new service worker so you wouldn't necessarily want to do that.

[00:03:37] But an interesting pattern that helps you draw the line between stuff that you can show almost instantly verses things that you must hit a server for in order to get new data