
TypeScript Progressive Web App Quickstart - aussieguy1234
https://github.com/insprintorob/typescript-progressive-quickstart/
======
isoos
The code seems generate to generate a very simple service worker that enables
offline more for the web app: it puts the static assets in a cache that serves
them if the network is down.

While it is a great start, and nothing wrong with that, I encourage people to
check the more advanced features of routing and caching, where you have much
better control of what is happening in the service worker. I have found the
best JS library for that is sw-toolbox: [https://github.com/GoogleChrome/sw-
toolbox](https://github.com/GoogleChrome/sw-toolbox)

Shameless plug: I have also developed a Dart library for progressive web apps:
[https://github.com/isoos/pwa](https://github.com/isoos/pwa)

One significant advantage of the library over the original solution is that
you can have offline mode without sweating as much as 100-ish characters:
[https://medium.com/dartlang/making-a-dart-web-app-offline-
ca...](https://medium.com/dartlang/making-a-dart-web-app-offline-
capable-3-lines-of-code-e980010a7815)

(Scroll ~to the middle, super-simple to setup).

Another advantage is that cache invalidation is really hard. Neither the
linked quickstart, nor the sw-toolbox addresses this, but there should be a
way to control your cache updates, invalidations, and making sure you don't
leave it in a broken state. Also, these should make sure that you don't
pollute the user's browser too much.

My pwa package does cover a lot of these edge-cases, and I'm happy to answer
questions wrt/ pwa caching if there are any.

(Next up: messaging solution between service workers, web workers,
isolates...)

~~~
aussieguy1234
From my testing, the service worker served cached assets without requesting to
the network, unless you cleared the cache or had automatic reloads enabled in
chrome devtools.

You can control invalidations a from chrome devtools. Assets get served from
the cache unless it's invalidated.

A chokidar powered script also watches for cached asset changes and
regenerates the service worker (using sw-precache) with a new cache key.

~~~
isoos
Couple of things are mixed up here.

1) You may instruct a developer that they should clear their caches in Chrome
DevTools. Good luck telling that to my father, who will have no clue what you
are talking about. Cache invalidation is not only a technical issue, it
affects the user experience, and should be an active part of your design. If
your low-level tool does not support it, you need to be aware of that, and
should write the code that does support it.

2) Automatically regenerating the serviceworker is the minimum you shall do,
but there are other error scenarios that may happen:

\- You accidentally cache hundreds of 10MBs assets, taking up a huge space of
your users. You roll out the new version, these assets are no longer cached,
but unless you evict them actively, they will still take up space on the
user's computers.

\- A cache request fails (for whatever reason), and one of the 29 assets goes
missing in the cache. The app may be able to run offline, except that it will
not show an icon, or will not run an asynchronously loaded script.

\- A cache update may fail during re-populating the cache (e.g. computer
powered off), and the next time the offline app is loaded, the cache stores a
mixture of old and new assets.

3) There are several layers of caches between the pixels and the server assets
(to name a few: CDNs, web proxies, browser's disk cache, service worker's
cache). Being aware that any of them may produce a different version of the
same resource will usually help you to design a better tolerance for the edge
cases.

------
ben_jones
As someone who has lost more hours then I care to admit toggling flags with
Webpack until I found the magic incantation: I love that this doesn't use
webpack. I also love that it focuses on setting up a full testing environment.
Thank you!

------
hazza1
This is really an Angular progressive web app, it doesn't do AOT minified
compilation so the deployment size will be huge.

Depends what you're building but for most PWAs I'd recommend a much smaller
library such as Preact probably in conjunction with
[https://github.com/NekR/offline-plugin](https://github.com/NekR/offline-
plugin)

~~~
mattmanser
The word 'huge' looks suspicious to me.

Also, if it is progressive why couldn't you still AOT the client side?

You could be completely right, but your comment smells dodgy.

Note that as it's typescript it will be transformed to JavaScript anyway, all
the comments stripped, etc. so very much doubt it will be huge. And
minification is becoming ever more irrelevant in the modern age because of
http2.

~~~
hazza1
Huge in the context is a few hundred kb, not great for a simple webpage.
[https://blog.nrwl.io/angular-is-aot-worth-
it-8fa02eaf64d4](https://blog.nrwl.io/angular-is-aot-worth-it-8fa02eaf64d4)

You could and should AOT the client side, my point was this quickstart project
doesn't.

Typescript isn't the problem here Angular is, without AOT it includes an in
browser compiler. Minification doesn't change with http2, you are probably
thinking of concatenation/bundling.

~~~
aussieguy1234
One thing to remember is that it is a quick start rather than a full
production setup, so minification/uglification etc could be added as desired
by whoever clones the repo as a base for their own up.

------
rco8786
I'm not sure I understand the recent uptick in posts about progressive web
apps. Are people running into enough problems with connectivity to architect
their entire app around them?

~~~
girvo
Outside of the developed world (and somehow Australia because our net
infrastructure is just that bad), being robust to network connectivity issues
is super important. It's also why SMS based "apps" work so well in those
situations, as intermittent issues is the norm, and SMS doesn't take much, but
your 2MB web app does!

~~~
rco8786
Ah. Was admittedly not thinking much outside my little bubble with that
comment. Thanks!

