I agree with everything Andrew says here. Progressive web apps are great, but as long as Google heap praise on mobile-only solutions (like the Washington Post doorslam) and also encourage separate AMP sites, they’re doing a great disservice to the web.
More features arrive regularly to make this “one web” even better and easier to maintain. Service worker, streams, app manifests, payment request, to name a few. But adding these features one at a time to large, mature applications like WaPo or FT or Nikkei is a slow and painstaking process. That’s why it’s taking us a long time for us to tick off all these new features, and why it seems like madness to try and build the entire app several times over.
However, by creating the concept of PWAs and marketing them as they do, Google is encouraging publishers to ‘start again’. And they’re doing exactly the same thing with AMP.
The slides from Aaron’s workshop at today’s PWA Summit. I really like the idea of checking navigator.connection.downlink and navigator.connection.saveData inside a service worker to serve different or fewer assets!
I feel for BaseCamp, I do. But give up on the native app path. Make sure your existing web interface is a good progressive web app and you can end-run around Apple.
The slides and video from a really great well-rounded talk by Aaron, filled with practical examples illustrating concepts like progressive enhancement and inclusive design.
A directory of progressive web apps.
Here’s an intriguing proposal that would allow web apps to indicate activity in an icon (like an unread count) in the same way that native apps can.
This is an interesting one because, in this case, it’s not just browsers that would have to implement it, but operating systems as well.
Debugging an error message.
Turbo-boosting travel sites into progressive web apps.
The tragedy of the iframe commons.
I need to get better at balance.
Some handy tips courtesy of Chris Ferdinandi.