To me the biggest advantage is that I get all the privacy benefits of a modern web browser as opposed to the user-hostile environment of modern app stores. On my de-googled phone I wouldn’t be able to call an Uber through an app (since it requires Google Play Services), but I can do it just fine through their mobile website: and actually close it afterwards. Doesn’t need to be an app either: you can do it in a browser tab just the same.
Once the PWA is closed, it’s can’t beacon home, it can’t track you, and it can’t drain your battery.
Correct me if I’m wrong, but I thought most PWAs ran service workers in the background for stuff like notifications, which do not get shut down when the PWA closes.
On iOS (as of at least iOS 13), the service workers do not run in the background for notifications. The moment you stop looking at the app, its state is saved and it its invisible wrapper app is SIGSTOPped and after a minute SIGKILLed.
The reason I still create native apps and have never made a PWA is listed in the “how to install” section. It’s not a complicated set of instructions but it’s different from installing any other app. In fact on iOS you can just add a one-line meta tag to your site that puts a banner at the top encouraging people to download the app with just two taps.
Apple doesn’t take PWAs seriously and users don’t know about PWAs. Hopefully that will change but for now it’s a far worse experience for a business than creating a native app.
Isnt PWA just a buzzword? I keep seeing it in different articles, and correct me if I’m wrong, but PWA seems to essentially be “I wrote a website that uses JavaScript and localstorage”. Am I missing something?
We find ourselves saying “A website that uses JavaScript and localstorage” that we found a shorter way to write it, as we’ve done with every other long phrase we need to use often.
From a web developer perspective it’s broadly building a web app with those components, but browsers/OSes are treating them differently. E.g. on Android if you hit “Add to Home Screen” on a traditional website it just adds a bookmark. For a PWA it’s added to the app drawer and appears on your Settings > Applications list. It works similarly on other systems that are supporting PWAs.
Yeah, but that still doesnt explain how the site itself is different. So I can bookmark it in a different way on mobile. That has nothing to do with desktop version, and it has nothing to do with the site itself.
I ask again, how is a PWA different from a JavaScript site with localStorage? The fact that you didnt give a single concrete example makes me think PWA is just marketing talk.
I’m not totally convinced, but I’ll keep an eye on it. I’d prefer web apps are just upfront about being web apps than pretend to be something else. If installing a PWA gives it some further capabilities, then sure, I’m on board with that.
I find PWA to be too generic of a description, as it doesn’t tell us anything. The main difference is the ability to use the website while offline, even after refresh. E.g. my company has an app that uses IndexedDB to manually cache video and other dynamic content, while a PWA would be able to more easily handle that.
My (very limited) understanding was that it just uses normal web technologies to achieve this, e.g. service workers, which don’t require a PWA, is that not the case?
You’re correct about the service workers. That’s why I don’t find PWA to be a helpful word/acronym/whatever as it doesn’t actually tell you anything. PWA is the service workers + manifest for “installing” + whatever else anyone wants to use on that particular day. PWA can also be just 1 of those things, and not all of them. It’s a very unhelpful word.
+1 to that. I wrote a similar piece myself.
To me the biggest advantage is that I get all the privacy benefits of a modern web browser as opposed to the user-hostile environment of modern app stores. On my de-googled phone I wouldn’t be able to call an Uber through an app (since it requires Google Play Services), but I can do it just fine through their mobile website: and actually close it afterwards. Doesn’t need to be an app either: you can do it in a browser tab just the same.
Correct me if I’m wrong, but I thought most PWAs ran service workers in the background for stuff like notifications, which do not get shut down when the PWA closes.
On iOS (as of at least iOS 13), the service workers do not run in the background for notifications. The moment you stop looking at the app, its state is saved and it its invisible wrapper app is SIGSTOPped and after a minute SIGKILLed.
The reason I still create native apps and have never made a PWA is listed in the “how to install” section. It’s not a complicated set of instructions but it’s different from installing any other app. In fact on iOS you can just add a one-line meta tag to your site that puts a banner at the top encouraging people to download the app with just two taps.
Apple doesn’t take PWAs seriously and users don’t know about PWAs. Hopefully that will change but for now it’s a far worse experience for a business than creating a native app.
[Comment removed by author]
Isnt PWA just a buzzword? I keep seeing it in different articles, and correct me if I’m wrong, but PWA seems to essentially be “I wrote a website that uses JavaScript and localstorage”. Am I missing something?
It’s not a ‘buzzword’, it’s jargon.
We find ourselves saying “A website that uses JavaScript and localstorage” that we found a shorter way to write it, as we’ve done with every other long phrase we need to use often.
From a web developer perspective it’s broadly building a web app with those components, but browsers/OSes are treating them differently. E.g. on Android if you hit “Add to Home Screen” on a traditional website it just adds a bookmark. For a PWA it’s added to the app drawer and appears on your Settings > Applications list. It works similarly on other systems that are supporting PWAs.
Yeah, but that still doesnt explain how the site itself is different. So I can bookmark it in a different way on mobile. That has nothing to do with desktop version, and it has nothing to do with the site itself.
I ask again, how is a PWA different from a JavaScript site with localStorage? The fact that you didnt give a single concrete example makes me think PWA is just marketing talk.
It does look like it’s mainly a traditional web app with an extra web app manifest to give it an ‘app’ flavour:
https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Advantages
I’m not totally convinced, but I’ll keep an eye on it. I’d prefer web apps are just upfront about being web apps than pretend to be something else. If installing a PWA gives it some further capabilities, then sure, I’m on board with that.
I find PWA to be too generic of a description, as it doesn’t tell us anything. The main difference is the ability to use the website while offline, even after refresh. E.g. my company has an app that uses IndexedDB to manually cache video and other dynamic content, while a PWA would be able to more easily handle that.
My (very limited) understanding was that it just uses normal web technologies to achieve this, e.g. service workers, which don’t require a PWA, is that not the case?
You’re correct about the service workers. That’s why I don’t find PWA to be a helpful word/acronym/whatever as it doesn’t actually tell you anything. PWA is the service workers + manifest for “installing” + whatever else anyone wants to use on that particular day. PWA can also be just 1 of those things, and not all of them. It’s a very unhelpful word.