When you name something you need to define it. Once you do that it is natural to have the definition poked at, and you run examples through those definitions. “What is different between a cat and a dog?”.
You tend to start with the definition, which leads you to Alex Russell’s original post and look through the attributes of a progressive web app:
- Responsive: to fit any form factor
- Connectivity independent: Progressively-enhanced with Service Workers to let them work offline
- App-like-interactions: Adopt a Shell + Content application model to create appy navigations & interactions
- Fresh: Transparently always up-to-date thanks to the Service Worker update process
- Safe: Served via TLS (a Service Worker requirement) to prevent snooping
- Discoverable: Are identifiable as “applications” thanks to W3C Manifests and Service Worker registration scope allowing search engines to find them
- Re-engageable: Can access the re-engagement UIs of the OS; e.g. Push Notifications
- Installable: to the home screen through browser-provided prompts, allowing users to “keep” apps they find most useful without the hassle of an app store
- Linkable: meaning they’re zero-friction, zero-install, and easy to share. The social power of URLs matters.
It is more important to look at the motivation and the outcomes that you are really looking for though.
I will talk a lil about the past, and then talk about the journey from about:blank to what I think would be the Ideal Web Experience.
AJAX to Ajax
When Ajax first came along it was talked about as an acronym, but we quickly saw that this wasn’t what we actually meant:
- If you used JSON instead of XML do I have an Ajax app?
- The killer feature of Google Maps was the panning and loading of tiles, which wasn’t about Ajax
What mattered was that we had enough tools to deliver a great desktop web experience, and that people were on the journey to build these. And, it was a journey. People talked about the various states of ajax adoption, and often the path was ugly.
We had to deal with legacy systems and you would often see a app.foo.com approach until that experience could eat www.foo.com. We also see the regression of behavior, when people would focus on the new shiny and leave behind some of the great features of the web (accessibility, progressive enhancement, etc). Evolution is messy, but many got through to the other side.
We are starting the same journey again. This time around we are dealing with constrained mobile devices and networks, and new great capabilities due to sensors and context. The browsers had to quickly optimize themselves for this new world. We are seeing some early success stories where we finally see proof that this is worthwhile, for users and businesses.
It has helped me to think about the Web experiences that I look forward too. Those that reach the ideal. What do they look like?
- They are predictably fast (all across RAIL, all the time, all devices, via any deep link entry point)
- They are secure (https all the things, CORS, CSP)
- They are accessible (everyone in the world can experience them)
- They have low friction (if I want to get to one from my home screen I can. If I want to easily pay without filling out forms AGAIN I can. If I want to be notified to re-engage, I can, …. etc etc)
- They are resilient (shit happens, they deal with it)
- They are adaptable (responsive across the board, from screens to inputs to context)
- They are progressive (they are always the best they can be given the constraints of their environment. no lowest common denominator, they keep getting better and better and they use ever capabilities that makes sense)
Now, let’s get back to reality from my idealistic view, and put the “is it a progressive web app if….” questions to the test.
These answers are my opinionated ones:
My experience is kinda slow, but it has all of the cool new features, is that good enough?
No. Performance on mobile at the center of this. Sorry.
If you deliver an experience that focuses on mobile is that a PWA? Yes. It is far from ideal though. We cracked the progressive nut and it is a huge advantage of the Web, so please keep going on the journey! Other form factors such as desktop and tablets are still huge, and I often see some a-ha moments when talking about how you can use a feature such as push to reach your users on the desktop!
If your experience only works with service workers is it a PWA?
No. Come on, Service Workers are designed to be progressive enhancement, please don’t mess with that!
If your experience only works on Chrome is it a PWA?
No. We went through the “best viewed on X” era. It’s not good enough. I know that all of the browsers aren’t fully shipping everything yet but they are doing pretty well. Being a Web developer means that you write to the platform across implementations
If you don’t want to hide the URL bar is it not a PWA?
No. This can be a choice. The important part is that you have the possibility to go full screen / immersive.
If you don’t support $BROWSER yet is it a PWA?
Yes. Flipkart went down this path. While I would have loved for them to ship to more browsers, they decided to ship earlier and iterate and the important point is that they HAVE kept going on the journey and they now support browsers such as Safari and UC Browser
Is it OK to ship pwa.foo.com first?
It’s your choice! If that is the best way to ship and learn, go ahead. Just please keep going and reach for the ideal of One URL across desktop, mobile, etc etc.
Is it OK to ship on http?
Nope, sorry. Safety is too important. I know that it takes effort to get over to HTTPS but it has never been easier, so get on that journey
Is it OK to not be that accessible?
No. I know it takes effort here too, but it is much easier to start with accessibility in mind (and security, and performance) so try to get that habit going.
This is another type of “accessibility”. It’s business importance may differ depending on the demographic and what you are building, but…. remember the BILLIONS of people coming online that use browsers such as Opera Mini? This is an age old debate that will come and go, but the context is important.
What if I don’t support Add To Homescreen?
Really? Is that so much work? I get it…. this isn’t the part that MAKES it a PWA, but why not allow that option for your users?
What if I don’t use push notifications?
If there isn’t a valid use case for you or your users, then THANK YOU for not needlessly sending push messages.
What if I am building “websites” not “webapps”
All good! Just don’t ignore the capabilities that can make the website fantastic.
What if I don’t have an app shell architecture?
All good! That is just one option than people are exploring, especially for certain types of experiences.
For me when I go through this thinking, I land right where I was back in the days of Ajax. I want the browsers, frameworks, and developers to be pushing each other in the right direction, evolving so that we can deliver amazing web experiences.
We aren’t yet at the ideal web experience, but I think that we are at least poised better with the technology and thinking around progressive web apps. It is all well and good to expect every development team behind a website to be craftsmen with infinite time to build the perfect experience, but the world isn’t like that. There are a slew of problems, a ton of legacy, and piles of work to do. All we can hope for is that this work is prioritized.
The PWA term itself is also useful as it was with Ajax. It gives you something to talk about with your clients, or with your business partner.
“We really need to prioritize some of these new capabilities, have you seen the results companies are getting? And the types of experiences? There may be some tech debt to pay off as we get the foundations cleaned up, but now is the time.”
Chances are you may be a lil sick of the term already. That’s OK…. but it has its uses.
We are right in the middle of some messy evolution, but I am so excited with the direction and enjoy working with the chaotic and passionate web community to keep on trucking.