
Turn your website into a Progressive Web App - mxbck
https://mxb.at/blog/how-to-turn-your-website-into-a-pwa/
======
finchisko
Please don't convert your website to PWA before thinking if it really adds an
value to your visitors first. Some sites are just great as they're now. I
understand you spent time "pimping up" your website, but No I don't want to
receive push notification from your site, or ability to visit your website
offline. Maybe I'm visiting your website for just single article and you'll
never see me again. It reminds me AMP situation. Those who stepped into hype
train, are now those whose starting to realise that maybe it wasn't such a
great idea at first place.

~~~
mxbck
> No I don't want to receive push notification from your site...

A PWA does not equal push notifications. Those are completely optional and
should of course only be added where that makes sense. And even then, you'd
have to agree to receiving them first.

> ...or ability to visit your website offline

Fine, you don't have to. In that case, the service worker just improves page
speed and reduces data usage.

~~~
StavrosK
> the service worker just improves page speed and reduces data usage

Hmm, how does it do that? I don't see what advantages it may have over caching
and HTTP/2 push...

~~~
finchisko
browser already do caching well, but you have to setup your server to sent
correct headers and it's kind of difficult (unpractical) to set different
caching policy for different kind of files if you're hosting many different
sites, or you're on shared hosting. With service worker you can have more
granular control over caching. But again, you really have to know, what are
you doing. For regular website using service worker to improve caching is IMO
overkill and also there is small chance, you'll make it unwillingly worse.

~~~
eberkund
> it's kind of difficult (unpractical) to set different caching policy for
> different kind of files if you're hosting many different sites, or you're on
> shared hosting

No it's not. In Apache and Nginx (and I assume any other half decent web
server) it is very easy to specify different cache times for each file
extension. Same on shared hosting (.htaccess)

~~~
finchisko
>Same on shared hosting (.htaccess)

apache yes, but what about nginx? And there are many other ways, how to host
your site (Amazon S3,...).

Also by unpractical I mean you have to have access to the server (ssh...). IMO
it should be more concern of an app then server. But I'm not advocate for
service worker for static resource caching (for websites).

~~~
eberkund
Pretty much all the shared hosts I've seen use Apache (or lighttpd)
specifically because of htaccess files.

------
codedokode
This is clearly overengineering if one has to write and maintain a service
worker just to be able to display a static site offline. How to debug it? How
to see if any of your visitors cannot load site because of error in a service
worker? How to decide which pages to preload for offline reading?

Also a service worker would add additional process in Chrome and require 30-40
Mb of RAM. I don't want service workers in my browser.

Well, web standards have always been this broken and illogical as long as I
rememeber.

~~~
untog
> How to debug it?

Chrome debug tools work just fine.

> How to see if any of your visitors cannot load site because of error in a
> service worker?

The service worker fetch event is a promise, so you can catch any errors
encountered and tell the client to go fetch the remote version instead. You
can then do whatever analytics stuff you want with the error.

> How to decide which pages to preload for offline reading?

Well, who knows. But it's flexible enough to let you decide yourself - the
last attempt, AppCache, forced you to decide upfront. With a service worker
you could in theory use a user's browsing history to know what pages they are
likely to look at. Or you can actually create responses manually in the
worker, so you can dynamically generate an entire page locally on the device.
It's very powerful.

> Also a service worker would add additional process in Chrome and require
> 30-40 Mb of RAM

This part I can't argue with. I mean, Chrome already uses a different process
for every tab, but more resources is more resources.

I don't see service workers as over engineering, I see them as a low level
API. We just need some abstractions.

~~~
codedokode
There is still a problem that some sites will have a service worker and some
will not. Maybe it would make more sense to allow the user to pick what they
want to cache for offline reading.

> The service worker fetch event is a promise,

By the way promises is another poorly designed technology: they catch
unhandled errors and do not report them in any standard way [1].

[1] [https://stackoverflow.com/questions/28001722/how-to-catch-
un...](https://stackoverflow.com/questions/28001722/how-to-catch-uncaught-
exception-in-promise)

~~~
untog
> There is still a problem that some sites will have a service worker and some
> will not.

Why is that a problem?

> By the way promises is another poorly designed technology: they catch
> unhandled errors and do not report them in any standard way

If you're using promises there is really no reason to not be handling your
errors. Catching unhandled errors is by design and it works great. It's
absolutely trivial to do.

And, as the SO post you've linked to points out, you can catch unhandled
promise errors using window.onunhandledrejection. It's not like it's that
dramatically different to window.onerror. Promises might not be perfect, but
they're better than JS callback hell in absolutely every way.

~~~
codedokode
By the way I have tried to use promises in PHP (they are almost the same as JS
promises) and had the same problem with promises catching all exceptions and
reporting nothing. I am thinking now about writing my own version of promises
because nobody seems to understand how to handle exceptions and unhandled
rejections correctly.

> Catching unhandled errors is by design and it works great.

I don't think that it's great because by default I would prefer to terminate
the application if there is an unhandled error or rejection. This is called
"fail fast" principle. What promises developers suggest is to continue running
the application even if it's broken.

~~~
WorldMaker
Tearing down an entire application immediately due to an asynchronous
exception has the possibility to leave the system in a deadlock or worse. It's
a bad idea in any asynchronous environment.

JS isn't today truly asynchronous in most usage today, but they are planning
for that future (present if you count Service Workers and Node/Electron).

~~~
codedokode
What you are suggesting (preventing errors from crashing application) only
makes discovering errors more difficult. For example, application might look
like it is working ok, but some of requests do not return any response or
return invalid data - because an exception was ignored.

Try googling "fail fast" if you want to see more reasons to use this
principle.

> Tearing down an entire application immediately due to an asynchronous
> exception has the possibility to leave the system in a deadlock or worse.

It should not. Because application can crash anyway - for example, if there is
memory access violation or out-of-memory error. And synchronous applications
crash on uncaught exception, I don't see why asynchronous applications should
not.

~~~
WorldMaker
Fail fast is also a terrible user experience: why did my app just disappear,
did I do something wrong? It implies blame to users that may not be at fault.

Sure, fail fast is very useful in debuggers to help a developer find and fix
problems. But this is why we have debuggers. Debuggers are a terrible user
experience, we don't need to force every user to live in a debugger and decide
themselves which errors matter.

Not every exception is "fatal" and "might look like it is working ok" is often
_good enough_ in the pragmatic real world where you can't control everything.

Also, just because you've never accidentally caused a machine to BSOD on a
deadlock or catch fire from an improper halt in a "fast fail" of multi-
threaded code, that just means you are one of the lucky ones. There are
disastrous consequences to bad multi-threaded code during "fail fast"
teardowns of threads not privy/cause to the error. There are enough nightmare
scenarios to keep a multi-threaded programmer up at night.

I appreciate your concern that developers sometimes ignore errors they should
fix instead or handle more appropriately. "Fail fast" in a debugger works to
help that. "Fail fast" in day-to-day operation isn't the right solution, at
the very least for making users possibly hate you because you'll never
properly handle 100% of exceptions.

~~~
codedokode
I have worked with code (in PHP) that didn't use "fail fast" approach and
didn't even log most warnings and notices. App didn't crash but sometimes
randomly returned invalid results. Of course, nobody fixed this because after
reloading the page the error could be gone. If you ignore errors or warning
you just get low quality code as a result. Maybe this code will corrupt your
database content, who knows. It is safer to stop the code if something seems
wrong.

Also I remember reading somewhere that the earlier you find the error the
cheaper it is to fix it.

> why did my app just disappear, did I do something wrong?

Usually operating system reports that there was an error in the application.
If the application crashes often, the users will complain to developers and
they will fix it.

> Debuggers are a terrible user experience, we don't need to force every user
> to live in a debugger

You should test your app properly before releasing it.

> There are disastrous consequences to bad multi-threaded code during "fail
> fast" teardowns of threads not privy/cause to the error.

I cannot agree with this. Usually the OS releases all locks, closes all files,
frees memory when the process terminates. I don't see what can go wrong here
and how you can get a deadlock because some process has terminated. Also if
you use locking you should add some kind of timeout. For example, MySQL has
lock timeouts and can even detect and fix deadlocks.

> "Fail fast" in day-to-day operation isn't the right solution, at the very
> least for making users possibly hate you because you'll never properly
> handle 100% of exceptions

The users will probably hate you more if the app will silently hang or show
incorrect data.

------
kylecordes
PWA is very slick for making complex client-side web applications work and
feel much more like native mobile applications, in terms of faster launch,
off-line, etc. (And by the way, the machinery to make them work is getting
quite nicely integrated in the box with Angular for example - I expect the
same for other SPA libraries coming soon also).

But I am somewhat skeptical of the implications beyond SPAs, which is that,
across the entire Internet, basically every static website in the world should
be converted to a PWA for an optimal mobile experience. Doesn't that seem
backwards? Shouldn't mobile browsers have a way to "just work" and give a
great experience for static websites, rather than changing all the sites?
Shouldn't we only need something like PWA for rich SPAs?

~~~
mxbck
I would argue that, while not every site should have to be converted to a PWA
to work properly, every site can benefit from it. If a website is not a
complex SPA, why should it not be fast, secure or offline-accessible?

HTTPS or Service Worker caching is not something a mobile browser can do for
you by default.

~~~
zerkten
It seems to me that a lot of the technology making up PWA has been bundled
with a PWA philosophy that has made it difficult for folks coming from a
progressive enhancement background to understand how it can be applied. Too
many people make it seem like an all-or-nothing deal, or couple learning these
technologies with other technology that's not an essential. In reality you can
incrementally add pieces to your approach for new site, or improve an old
site.

------
adrianN
Or you could just serve a small website without scripts or huge images that
doesn't need to be progressive because it could be viewed just as well on some
100Mhz Pentium I class computer over a 56k connection.

~~~
gramstrong
What is the point of this comment? If you want to create a tiny static web
page for which the benefits of a service worker are nominal, then do it and
stop worrying about it. That's not the purpose of service workers anyways.

~~~
hyperdunc
The comment is intimating that many websites are over-engineered.

Consider it a suggestion to developers who are tempted to implement cool new
tech on a site just to tickle their own itch.

------
benmarks
A decent primer which wisely handles the important things first: namely,
misconceptions around what it is & what's required.

"Application" in PWA is best thought of as indicating the user experience on a
mobile, with the ability to add to homescreen without downloading via an app
store, and offline capabilities. Where PWA shines is website > AMP > PWA. See
[https://www.google.com/search?q=myntra+kurtis](https://www.google.com/search?q=myntra+kurtis)
on your mobile for a great example of this transition.

------
Softcadbury
I recently turned my app into a progressive web app, if you follow football
results, you can check it [https://github.com/Softcadbury/football-
peek](https://github.com/Softcadbury/football-peek)

------
tuananh
The author does this for fun / practice only i think.

For personal static blog, it doesn't take any effort to be fast; just don't
bundle lots of bs stuff with it.

btw, there are still optimizations that can be done for author's site. See
Google PageSpeed

[https://developers.google.com/speed/pagespeed/insights/?url=...](https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fmxb.at%2Fblog%2Fhow-
to-turn-your-website-into-a-pwa%2F&tab=mobile)

------
rocky1138
This is 2017's version of flashturbation.

~~~
benmarks
Not really. Simulate a garbage cell connection and try buying things online.
AMP+PWA are a fairy compelling experience.

------
pwinnski
Illustrated with an image that includes a giant bar with "ADD TO HOME SCREEN"
on it. I already know how to do that on my phone. If I go to a page with a bar
like that, I'm closing the page. I'm sure I'm not alone.

~~~
anderber
I believe that's a Chrome feature, not a specific website feature. If you have
a manifest and it's https, Chrome will ask if you want to add to home screen.
Although, I think they only ask once.

~~~
Andrex
Yes. And only after repeat visits to the same site.

------
Zpalmtree
Is it impossible for websites to use my horizontal space? I don't like having
a tiny bar in the middle when I have 300 unused pixels either side of the
text, this phone centric internet is really annoying on desktop.

~~~
kbsletten
I'm pretty sure this is because there's a critical limit on how wide a column
of text can be before your eye won't snap back to the next line as easily. The
thing I love about the phone centric web is that I don't have to have my
browser full screen (as you say, it just wastes space).

~~~
oneZergArmy
Agreed. I usually have two browser windows per screen, or I just zoom a little
if a website uses too little horizontal space.

When I come upon a site that uses too much horizontal space for me to read
comfortably, I just leave.

------
blueside
is going full "Progressive Web App" worth really the time investment right now
given Apple's lack of support in mobile Safari?

------
drumttocs8
What about monetization? Do you serve Adsense or Admob with a PWA? Probably
Adsense, but then you lose out on ads optimized for mobile.

------
vvdcect
I always had this idea that a PWA was a site/app that works without js.

~~~
codedokode
I think "progressive" is just a new meaningless buzzword.

~~~
finchisko
For me progressive should mean, that features (like adding to home screen,
push notifications...) reveals progressively. Visitor should show some
engagement, before PWA start to offering those features. Definitely not on
first visit. It's very trendy nowadays, but extremely annoying to cancel all
those feature request popups. "Do you want to receive push notifications?",
"Please install our app for better experience", "Add app to homescreen" ...
That's not web I like. And yes, I do realise it's far from original
definition.

~~~
codedokode
I think that it would be better to remove popups and only show an icon in the
address bar so the user can click it and grant necessary permissions. My
version of Chromium shows an icon when a site wants to install a service
worker.

------
mmagin
This is uh, a Chrome-specific thing?

