
6 Myths of Progressive Web Apps - olivier-tille
https://medium.com/samsung-internet-dev/6-myths-of-progressive-web-apps-81e28ca9d2b1
======
geebee
This is different from how I understood the term... here's something closer to
what formed my understanding.

[https://developers.google.com/web/fundamentals/codelabs/your...](https://developers.google.com/web/fundamentals/codelabs/your-
first-pwapp/)

"Progressive - Works for every user, regardless of browser choice because it's
built with progressive enhancement as a core tenet."

My impression was that a progressive web app was built with the simplest
technology and UI at first (simple HTML and CSS), and enhanced _progressively_
for different environments (javascript for browsers, various mobile
environments)

I like this approach a lot because it preserved the ability to do something
simple when that was all that was needed, but with the option of adding more
complexity in exchanged for a more sophisticated UI later, as needed.

This approach, I think, also gained popularity as a counter point to the pure
SPA, single page app, which required using a more complicated and powerful
front end framework.

I noticed some people felt that a progressive web app was equivalent to
elegant degradation to HTML for javascript heavy apps. To be clear, this is
just how I thought of things (by no means is this an industry definition), but
I saw that as slightly inaccurate. A pure SPA from a dev point of view can
degrade to HTML without error, but it wouldn't have been built iteratively
from simplest HTML and enhanced later. Likewise, a developer could add
javascript to a simple HTML layout in a way that no longer degrades
gracefully.

Personally, I think that progressive enhancement is the right way to go, and
will continue to be so, for a huge number of apps for a long time. I see this
as similar to the NoSql cycle - many of the technologies that emerged are
extremely good and critical to many types of databases, but SQL databases
actually do meet the business needs (and scalability) for a huge number of
projects. Similarly, there really are apps that should be written as SPAs with
powerful front end JS frameworks, but this is currently very over-applied,
resulting in high complexity costs that had either no benefit or not nearly
enough benefit to justify the increase in development and maintenance costs.

~~~
WorldMaker
I think a terminology quirk here is that the goal posts for "progressive
enhancement" have moved over the years. Certainly there's still the ideal out
there of artisanal HTML that doesn't need JS to function, but slowly gets
enhanced as layers of JS are added... but the P in PWA doesn't necessarily
refer to that ideal.

In the specific context of PWA, I've seen progressive enhancement is most
often specific to how the app-like enhancements are applied (ie, use platform
notifications if they are available, fallback to something like a JS toast
library, if not), not necessarily to, say, the relationship of the HTML and
JS. Many PWAs in the wild are still SPAs (and still going to be SPAs), and
arguably a SPA is going to provide the most app-like feel for a PWA on a
user's device, rather than something "pure" and HTML page driven.

~~~
geebee
That certainly appears to be the case. I'm not quite so willing to give up on
the original definition, though. "Agile", for instance, eventually came to be
widely (though by no means universally) known as something requiring a very
specific set of tools and processes (SCRUM, test-first, velocities,...) when
the original manifesto made no mention of any of this and even said
"Individuals and interactions over processes and tools".

Goalposts move, definitions change... but if "progressive" doesn't refer to
the progression from HTML to elaborate UI in JS or mobile, does it still refer
to the movement from simple to more complex? Or has "progressive" become a
great sounding word, like "agile", that everyone wants to claim? Nobody wants
to describe themselves as lumbering and clunky instead of agile, or regressive
and backward instead of progressive.

~~~
WorldMaker
It still refers to a movement from simple to complex: server delivery to
service-worker-based caching and offline-capable "delivery" strategies;
lighting up an increasing number of "app-like" experience APIs as browsers and
OSes offer them (from general "web platform" APIs that work across operating
systems such as web platform notifications, to hooks into OS-specific APIs; an
example there is PWAs on Windows can request access to a _lot_ of the UWP APIs
to support things like Live Tiles).

ETA here: The missing idea here being that when using these OS-specific
components, you should do it in a progressive enhancement way such that they
have fallbacks or offer alternative functionality when they don't exist. Try
to avoid the old west days of "Works Best on This Particular Browser/OS
Combo".

There is definitely a need to preserve the old meaning of "progressive
enhancement", but that may be a need for a new term, as this one moves on.
Particularly the more that it feels that JS has "won" and is the default much
more than the exception. I used "artisanal" as a joke in the previous post,
but it's also somewhat apt here as raw, barely filtered, HTML [1] feels
increasingly like a fad for hipsters and old curmudgeons more than the way of
the web. To support it as a movement you might have to market it in similar
"return to the web's roots" marketing.

[1] Just like Grandma used to bake.

~~~
poshaughnessy
Hi. Progressive Enhancement is a separate term and concept from Progressive
Web Apps. The intention is not to replace the meaning of Progressive
Enhancement. As you say, it is a very important concept in its own right.

Progressive Enhancement is an important aspect of PWAs, as it is for web
development in general. PWAs are bringing new features to the Web, but it
should/must be done in a way that does not break the experience for anyone
else. I guess that's why Alex chose that word in particular.

------
fenwick67
"Responsive, connectivity-independent, app-like, fresh, safe, discoverable,
re-engageable, installable, linkable web experiences."

This just makes me want to barf.

------
zackify
There's one metric Google's lighthouse doesn't look for, and it's huge to me.
Speed while switching pages on a PWA, and if there's a loading spinner on
every single page change, whether you loaded it or not.

A site I built splits JS and waits the 20ms for it to be downloaded, then
switches the page. Other sites I see will put up a loading spinner every time
and leads to a horrible user experience.

