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
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...)
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.
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.
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!
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
Angular 2 typescript apps can use AOT compilation, so that could be added if it's not there already, but regardless of that isn't one huge benefit of a PWA that the code is cached so it can be used offline, and a service worker is used to control what needs to be downloaded on subsequent loads? That means that, while it's good not to be wasteful, the initial download size isn't really that important. Adding a one-time download few hundred KB of code isn't going to make a big difference to the user.
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.
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.
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.
Http2 is what I was thinking. Progressive web apps are cutting edge, browsers that support them will also support Http2. It will load a large number of assets over a single connection, more efficiently than using concatenation. It dones struggle on bad network connections more than Http 1.1, but the service worker should account for that.
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?
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!
I went to a talk about progressive web apps, by one of the Google Chrome developers working on them along with some colleagues and that inspired me to build this. I think they have potential to save the web, by making it as fast as a native app. It also means the app store of your choice doesn't take a cut of your income. https://wego.com is a good example of a production app.
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
Shameless plug: I have also developed a Dart library for progressive web apps: 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...
(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...)