But you do need "PWA" if you want your site to work offline. PWAs were never really sold as something that would make your site's initial load time faster. Not really sure how the author got that impression.
It's almost like saying "you don't need jQuery to make your site faster" - to those who understand the purpose of jQuery, it's a bit of a nonsensical statement.
Moreover..PWAs are not meant to replace websites. They are meant to replace Mobile Apps. Almost all business apps can be replaced by PWAs without the rigmarole of creating an app and publishing on Apple and Google store.
I absolutely agree with you there. I bet if we ran a compression algorithm on all the apps in the app store, we would achieve a 90%+ reduction, on account of all the repeated
boilerplate code!
Can't you just use ServiceWorkers in a regular webpage? Seems like you can. That would allow you to have an offline persistent website while still using a webpage. https://caniuse.com/#feat=serviceworkers
There seems to be a few misconceptions around what is and what isn't a PWA. A PWA (in my opinion) is simply a website that makes use of certain browser features (e.g. service workers, push notifications, manifests). It's a bad definition, with a lot of grey areas, but it is what it is (and let's face it, definitions in web development are often hard to pin down).
For example, we built https://usebx.com/app with plain old HTML, JavaScript and CSS. Yet, it can be installed on your phone, send you push notifications and even works offline. So I would categorise it as a PWA rather than a website.
My point is, if you're using service workers, you're more a PWA than a standard website.
That would make it a Progressive Web App, by most definitions. It's kind of a vague term, but IMO anything using service workers to serve content offline is a PWA.
(but I also avoid using the term for exactly this reason)
So the thing that makes a site a PWA in your eyes is the "add $app to your homescreen" prompt? Because I would view any site that works offline, beyond http/s caching, to be a PWA.
The definition of a PWA is a page that uses features like add to homescreen, service workers... or push notifications. It doesn't have to use this and the browser doesn't have to support it. PWA will progressively use such features when they are supported, and that's where the name comes from. If a page requires these things to function then it's not a PWA.
The author mentions that, and says there is a use case there, but suggests that most PWA's don't have any use when offline, so they are useless in lots of cases.
"Initial load time" means "download, install, and run time". With PWAs (just like native apps) the "download and install" part only happens once. The article is irrelevant to PWAs.
> But you do need "PWA" if you want your site to work offline.
The author addresses this point quoting the examples of the most popular apps where offline mode doesn't make sense as their whole point is to facilitate online communication (booking, chatting, dating, social interaction etc.).
But in those examples, offline mode still makes a lot of sense. For example, looking up bookings when signal is bad (when on a train), or past multimedia messages within you chats etc etc.
It's almost like saying "you don't need jQuery to make your site faster" - to those who understand the purpose of jQuery, it's a bit of a nonsensical statement.