Progressive Web Apps (commonly abbreviated as just PWA) are all the rage these days. Everyone seems to be jumping over each other to take their existing web experiences and giving them a hearty dose of progressiveness. It seems like some well-known brand is regularly announcing that they are building a PWA - brands like Starbucks, Google Maps, Twitter, Uber, and many more:
Over the next few sections, let's get a really good look at what PWAs are why all of us should pay more attention to them...or not :P
Onwards!
If we take a step back and put aside any of the noise we’ve been hearing about PWAs, they are just plain old web apps (or sites) very similar to the ones we’ve been seeing and building for billions of years. They are built using HTML, CSS, JS and rely on a large ecosystem of tools and frameworks whose stickers are probably featured on the back of your laptop at this very moment. At the end of the day, PWAs look like regular web apps. They smell like regular web apps. They probably even taste like regular web apps.
What this doesn't mean is that every web app is a PWA. Sorry, Yahoo from 1997:
PWAs combine ordinary web content with capabilities such as installation and offline support. The user experience we aim for is one thing; the features a particular browser and operating system support are another. Let's look at both.
One of the hallmarks of PWAs is to reinforce a new vision that the web isn't about terribly bloated content with ads and pop-ups everywhere. The goal is for all of us to collectively move the web forward with a strong focus on doing the right things for our users. This means that PWAs are expected to...
A PWA should start quickly and respond promptly to interaction. Calling it a PWA doesn't make those things happen automatically. We still need to measure loading and interaction on the devices and connections our users have.
Our world isn't just big screens with a keyboard and mouse. Pretty much everything with access to a power outlet and a wireless connection is capable of running web content these days:
This means our users may access our content across different devices, input methods, accessibility modes, and screen sizes. We need to test the experiences we actually support, rather than assuming that one successful desktop run covers them all.
One of the biggest frustrations with traditional web apps is that they fall apart the moment your internet connection gets flaky:
With PWAs, you account for network flakiness and design the right features to ensure your users don't lose valuable data or can't make progress in whatever they are doing. There are various degrees of offline capabilities you can provide. You can be extremely lazy and just provide a simple offline message like what you'll see on this site:
On the other end, you can be an industrious koala and provide a fully offline-capable version of your content where everything is cached similar to what the lodash documentation does:
Many PWAs will fall somewhere in the middle, but the important thing is that they will acknowledge inconsistent internet connectivity and try to provide the right set of features to help users out.
PWAs can use capabilities that used to be associated mainly with native apps. Push notifications are one example. A supporting browser and operating system may deliver them while the app's page isn't open, subject to permissions and platform rules. That is different from promising that a fully quit browser will always receive them:
The other functionality is the ability for a PWA to be launched from your default OS launch location (home screen, start menu, dock, etc.) and run inside a native app shell instead of your browser. This means that users won’t just access a PWA via a browser tab:
Instead, if they choose to install the PWA, they can run it just like they would any native stand-alone application. The following screenshot is of this site running as a standalone app, and notice the icon in the dock below:
Installation support and the steps a user follows vary by browser and operating system. Where installation is supported, the app can get a launch entry and a window without the usual browser controls. Users on other platforms should still be able to use the underlying website.
The word installing is misleading when it comes to PWAs. All of the app content is still served from your server and, unless you explicitly added some caching capabilities, your PWA will suffer the same challenges it normally would if the network connectivity goes haywire. All that really gets installed on your machine is just the bare minimum information needed to launch your app, like what the app icon should be and the URL to use when starting up.
HTTPS, an app manifest, and service workers help with different parts of this experience. Installation criteria vary by browser, and a service worker is not a universal prerequisite for installation. We use one when our app needs the caching or event-handling behavior it provides.
1. Use HTTPS to serve content securely. This is a straightforward one that you are probably well aware of.
2. Specify a Web Application Manifest to specify additional metadata about your app. In the past, we had meta tags that gave search engines extra details about your content. The Web Application Manifest is like meta tags 2.0:
{
"short_name": "KIRUPA",
"name": "KIRUPA",
"icons": [
{
"src": "/images/orange_192.png",
"type": "image/png",
"sizes": "192x192"
},
{
"src": "/images/orange_512.png",
"type": "image/png",
"sizes": "512x512"
}
],
"start_url": "/index.html?source=pwa",
"background_color": "#0099fe",
"display": "standalone",
"scope": "/",
"theme_color": "#0099fe"
}By specifying this manifest, you provide additional details about your app that browsers, search engines, and operating systems can use to provide a more native app-like experience. For example, the PWA installation case we looked at earlier relies on the information in this manifest for specifying the appropriate app icon, title, etc.
3. Use a service worker when you need richer caching or supported background events. A service worker is an event-driven script managed by the browser. The browser can start it for an event and stop it when its work is finished; it is not a permanently running background process. For controlled pages, it can take part in network and cache handling:
An active service worker can handle fetch events for the clients it controls. Its registration scope and the page's lifecycle determine which pages are controlled; simply creating the script doesn't intercept every request on a site. Our code chooses when to use the network or a cache, rather than caching everything automatically. Supported events such as push have their own requirements. For more detail, see Using Service Workers.
So, there you have it. A PWA builds on a website with app-like capabilities and an emphasis on a good user experience. HTTPS protects the connection, a manifest describes the app, and a service worker can support our chosen offline behavior. These pieces have different jobs. Does putting a new name on them change everything? Well, yes...and no!
Web technologies have been evolving for a very long time, and we never had to rebrand what we called web apps every time some new API or functionality became available that did something cool. The reason for this new name is best summarized by Frances Berriman who first coined the term Progressive Web Apps. In Naming Progressive Web Apps, she says:
The name [PWA] isn’t for you and worrying about it is [a] distraction from just building things that work better for everyone. The name is for your boss, for your investor, for your marketeer. It’s a way for you to keep making things on the open web, even those things that look really “app-y” and your company wants to actually make as a native app, 3 times over. They don’t want you to make websites anymore, but you still can if you’re sneaky, if you tell them it’s what they think they want.
To echo what Frances says, I saw this first-hand when I was the Product Manager for PWAs at Microsoft and had to work with various internal and external teams on their app strategy. A large reason PWAs got (and continue to get!) so much interest is largely because of the naming. The general name of web apps has been around for a while, and it didn’t exactly have a lot of positive connotations - especially when you compared it to native apps and the level of performance and UX richness they provided. It doesn’t matter that web apps today are light years better than what they were just a few years ago purely based on under-the-hood performance improvements in all the browsers and web runtimes, and a well-built web app can meet demanding performance requirements, though we still need to measure the target workload and check the required platform features. Early impressions are what matter, and many people in the decision making process for your team or company’s app strategy would not give web apps a second look. They probably still reference Mark Zuckerberg's ancient 2012 statement that betting on HTML5 was a mistake. The key word being: 2012.
PWAs, on the other hand, are new and don't carry the historical baggage that web apps are known for. If calling something a web app will incite yawns but calling the same thing a PWA will get rounds of applause, why not just go with the PWA name especially when the people who benefit are your end-users and maybe even your developers?
The useful question is which capabilities help our users, and whether our target browsers support them. Check current Service Worker support, installation behavior, and any other APIs the app needs. Then test the experience, including what happens when a capability or network connection is unavailable. A PWA name or an install icon can't do that work for us.
Just a final word before we wrap up. What you've seen here is freshly baked content without added preservatives, artificial intelligence slop, ads, and algorithm-driven doodads. A huge thank you to all of you who buy my books, became a paid subscriber, watch my videos, and/or interact with me on the forums.
Your support keeps this site going! 😇
:: Copyright KIRUPA 2026 //--