Google introduced the term "Progressive Web Apps" recently, describing web applications that progressively enhance to feel native. With service workers enabling offline functionality and app-like experiences, this could fundamentally change mobile web development.
Or it could be mobile web's latest disappointment. We've been here before.
What Progressive Web Apps Promise
PWAs aren't a new technology—they're a pattern combining existing and emerging web features:
Service workers: JavaScript that runs in the background, intercepts network requests, enables offline functionality
Web App Manifest: JSON file that describes your app for installation (name, icons, display mode)
HTTPS: Required for service workers, ensures security
Responsive design: Works on any device/screen size
App-like interactions: Smooth animations, gestures, no page reloads
The pitch: build once for the web, get offline capability, push notifications, homescreen installation, and native-like performance.
The Service Worker Game-Changer
Service workers are the key technology. They're like client-side proxies that intercept network requests:
self.addEventListener('install', event => {
event.waitUntil(
caches.open('v1').then(cache => {
return cache.addAll([
'/',
'/styles.css',
'/script.js'
]);
})
);
});
self.addEventListener('fetch', event => {
event.respondWith(
caches.match(event.request).then(response => {
return response || fetch(event.request);
})
);
});This caches assets and serves them offline. When the network is unavailable, the app continues working with cached data.
This is more powerful than AppCache (which failed due to terrible API). Service workers give programmatic control over caching strategy.
The Installation Story
PWAs can be "installed" to homescreen via Web App Manifest:
{
"name": "My PWA",
"short_name": "PWA",
"start_url": "/",
"display": "standalone",
"icons": [
{
"src": "icon-192.png",
"sizes": "192x192",
"type": "image/png"
}
]
}When installed, the app launches without browser chrome, feels standalone. Users might not notice it's not native.
But "might not notice" is the challenge. PWAs still have limitations native apps don't.
What PWAs Can't Do (Yet)
Despite the hype, PWAs have constraints:
No access to many native APIs. Bluetooth, NFC, advanced camera features, background processing—native apps have more capabilities.
Performance limitations. JavaScript and DOM are slower than native UI. For most apps this doesn't matter, but games and heavy graphics suffer.
Discoverability problems. PWAs aren't in app stores (though Google is exploring this). Users are trained to find apps in stores, not web.
iOS support is weak. Apple isn't enthusiastic about PWAs (they compete with App Store revenue). Safari's service worker support is limited.
Second-class citizens on Android. Even on Android, PWAs lack full native app parity. Some APIs remain unavailable.
These aren't necessarily permanent limitations, but they're current reality.
The Offline Strategy Challenge
Making apps work offline requires careful thinking:
- What data must be available offline?
- How much can you cache without bloating storage?
- How do you handle conflicts when syncing back online?
- What's the fallback for resources that aren't cached?
Service workers give tools, not solutions. Implementing robust offline functionality is complex. Most apps don't need it, and for those that do, it's significant work.
The danger is "progressive enhancement" becomes "additional complexity that provides marginal benefit."
When PWAs Make Sense
PWAs are compelling for:
- Content sites that benefit from offline reading
- Utility apps with lightweight interactions
- Applications where installation friction is killing conversion
- E-commerce wanting app-like checkout
- Teams without native mobile expertise
PWAs are questionable for:
- Apps requiring native APIs PWAs don't support
- Heavy graphics or gaming
- Applications where app store presence drives discovery
- iOS-primary user bases
The React Native Comparison
Both PWAs and React Native try to bridge web and native. Different approaches:
PWAs: Web tech, progressive enhancement, works everywhere but with limitations
React Native: JavaScript but native components, platform-specific but fully capable
PWAs are more "write once," React Native is more "learn once, write platform-specific."
Neither is universally better. They solve different problems and have different trade-offs.
The Mobile Web's History of Disappointment
We've seen mobile web promises before:
- 2007-2010: Web apps in Mobile Safari! (Too slow, limited APIs)
- 2011-2013: PhoneGap/Cordova hybrid apps! (Better but still not native)
- 2014-present: React Native, PWAs, various attempts
Each iteration got closer but never achieved parity with native. PWAs are the latest attempt. Whether they succeed where others failed depends on execution.
Looking Forward
PWAs represent a bet that web technology can be good enough for most apps. "Good enough" is a lower bar than "better than native," but it might be the right bar.
If browser vendors (especially Apple) support PWAs fully, if tooling matures, if developers learn offline patterns, PWAs could be significant. The web reaches more users than any app store.
But if iOS support remains weak, if offline complexity proves too much for most teams, if users continue preferring app stores, PWAs might be a niche approach.
For now, PWAs are worth exploring but not betting everything on. The technology is promising, but adoption and ecosystem support will determine success.
Resources:
- Progressive Web Apps – Google's PWA documentation
- Service Workers – MDN documentation
- PWA Examples – Showcase of PWAs
