Tom explains the history, design, function, and use cases of Progressive Web Apps.
Featuring Tom Merritt.
Please SUBSCRIBE HERE.
A special thanks to all our supporters–without you, none of this would be possible.
Thanks to Kevin MacLeod of Incompetech.com for the theme music.
Thanks to Garrett Weinzierl for the logo!
Thanks to our mods, Kylde, Jack_Shid, KAPT_Kipper, and scottierowland on the subreddit
Send us email to firstname.lastname@example.org
This app I want says I have to use its web version
But I don’t want a website?
But it says I can install it But it’s on the Web How does that work?
Are you confused?
Let’s help you Know a Little more about Progressive Web Apps
A progressive web app or PWA is essentially an application that is delivered through a browser but can be used like a native app. It doesn’t even need to be online and it can be launched from its own icon without having to go through the normal browser interface.
PWAs are much easier to deploy and maintain than native apps because you don’t need to keep up with an API or changing operating system demands including backwards compatibility. Of course because they aren’t native apps with direct access to the API and OS, they aren’t usually as smooth or as fast. But they can get very close.
The other advantage of a PWA is you can start using it immediately when you find it. You don’t have to wait to install it if you don’t want to. And you can share it with others with a link!
The term progressive web app was introduced by Google’s Alex Russell in 2015.
In a conversation with Frances Berriman they decided on the attributes of a new class of applications that took advantage of modern web browsers.
Russell lined out the attributes in a post on June 15, 2015 called “Progressive Web Apps: Escaping Tabs Without Losing Our Soul”
He didn’t invent PWAs. There were already loads of things like it: Adobe AIR Applications, Chrome and Firefox Packaged Applications, BlackBerry WebWorks Apps, W3C Widgets, WebOS Apps, the Chromium Embedded Framework and more.
Russell essentially proposed grouping the major attributes of these approaches and giving them the name Progressive Web Apps. He described the attributes of a PWA as
Responsive. Doesn’t matter if you’re on a phone screen or a desktop. It should work.
It should Work offline
Always be updated transparently. He called this fresh.
Discoverable. In other words identifiable as an app
Re-engageable by the OS for things like Push Notifications
Installable. You should be able to have an icon on your home or launch screen. No need for an App Store.
And Linkable: meaning PWAs should be zero-friction and easy to share.
There’s no single standard for PWAs but Google has championed them
Google’s Developers page distills PWAs down into three points.
Reliable – It loads instantly and doesn’t show you a 404 or as they call it the Downasaur.
It’s fast responding to user interactions the way a native app would be. As Google says, “No janky scrolling”
And it’s engaging. Feels like a natural app with an immersive user experience. In other words it’s not just a tab.
That doesn’t address cross-browser compatibility, but Microsoft mentions it in its page on PWAs on MDN.
Microsoft describes PWAs as “using modern web APIs along with traditional progressive enhancement strategy to create cross-platform web applications. These apps work everywhere and provide several features that give them the same user experience advantages as native apps.”
Of course to get there you need companies to support them.
Google has supported PWAs since the Russell proposal in 2015. Windows added support for PWAs in February 2018. In March of that same year iOS added it to Safari 11.3. So at last count Firefox, Chrome, Safari and Edge all support it as do many other browsers.
OK so we have a kind of definition of what Progressive Web Apps are and who supports them.
How do you make them work?
PWAs need a few things a typical website doesn’t have to include.
One is a manifest. This is a JSON file that defines things about the look, like the name of the app, the icon for the home screen, background colors and whether to show the browser UI or take over full screen.
PWAs also need something called Service Workers. These are little waiters that run around in the OS… well OK not actually that kind of service worker. But not that far off. Service workers create a layer between the app and the network. They cache new content and synchronize local changes with a remote server. It enables notifications and fast loading.
And a PWA should also use https so when it does send data, it’s secure.
Those are the things almost always considered necessary to be a PWA. But there are a few other options and/or alternatives for making websites that work like apps. These are not yet considered essential to be a PWA and may even be separate from them but let’s run through what they are.
WebAssembly is a binary format for the web that is pre-compiled before it’s shipped to you then fully compiled by your browser, meaning it runs closer to native speed.
Houdini is a set of features to talk more directly to a browser’s CSS rendering engine for more custom layouts, styles and animations than the browser would give from interpreting CSS itself. Fancy animations and drop shadows and such.
And WebRTC can give browser real-time communications, often thought of for use with audio or video conferencing but Nvidia is using it to deliver its cloud gaming service on iOS.
These can be used on their own or sometimes mixed in with PWA approaches.
All right so you know what one is and how it works. Where do you find them?
On the Web
If you want to try a progressive web app, a few of the most commonly cited examples are twitter lite, Flipkart and Pinterest. Just do a search. One of the more recent examples is Amazon’s Luna game streaming service on iOS.
Some of them are even getting listed in app stores.
I hope this helps you understand why your app may not act like an app.
In other words I hope now you know a little more about Progressive Web Apps