This looks interesting—a new book by Dean Hume all about progressive web apps. A few chapters are available to download.
Here’s a nice one-sentence definition for the marketing folk:
A Progressive Web App is a regular website following a progressive enhancement strategy to deliver native-like user experiences by using modern Web standards.
But if you’re talking to developers, I implore you to concretely define a Progressive Web App as the combination of HTTPS, a service worker, and a Web App Manifest.
This is such a strange announcement from Microsoft. It’s worded as though they chose to use the WebKit engine on iOS. But there is no choice: if you want to put a browser on iOS, you must use the WKWebView control. Apple won’t allow any other rendering engine (that’s why Chrome on iOS is basically a skin for Safari; same for Opera on iOS). It’s a disgraceful monopolistic policy on Apple’s part.
A word to the Microsoft marketing department: please don’t try to polish the turd in the shit sandwich you’ve been handed by Apple.
The BBC has been experimenting with some alternative layouts for some articles on mobile devices. Read on for the details, but especially for the philosophical musings towards the end—this is gold dust:
Even the subtext of Google’s marketing push around Progressive Web Apps is that mobile websites must aspire to be more like native apps. While I’m as excited about getting access to previously native-only features such as offline support and push notifications as the next web dev, I’m not sure that the mobile web should only try to imitate the kind of user interfaces that we see on native.
Do mobile websites really dream of being native apps, any more than they dreamt of being magazines?
Are you the creator, programmer, or quality-tester of a podcasting application? This page provides a range of podcasts that exemplify a range of atypical use case from merely uncommon to exceedingly fringe. If your app can handle all these, you’re doing well.
There’s a lot of misinformation on the internet as to how to build a PWA and how “appy” and SPA-y one must be.
This simply isn’t true. Disappointingly, It is what most of the documentation, blog posts and public discourse seem to imply.
I’m so, so happy to see some pushback against the misinformation that progressive web apps automatically imply client-side rendered single page apps built from scratch. There’s so much value to be had in turbo-charging an existing site into a progressive web app.
But what we don’t need is yet another TLA like Alien Web Apps.
A great bit of web history spelunking in search of the first websites that allowed users to interact with data on a server. Applications, if you will. It’s well written, but I take issue with this:
The world wide web wasn’t supposed to be this fun. Berners-Lee imagined the internet as a place to collaborate around text, somewhere to share research data and thesis papers.
This often gets trotted out (“the web was intended for scientists sharing documents”), but it’s simply not true that Tim Berners-Lee was only thinking of his immediate use-case; he deliberately made the WWW project broad enough to allow all sorts of thitherto unforeseen uses. If he hadn’t …well, the web wouldn’t have been able to accommodate all those later developments. It’s not an accident that the web was later used for all sorts of unexpected things—that was the whole idea.
Anyway, apart from that misstep, the rest of the article is a fun piece, well worth reading.
You can use
navigator.storage.estimate() to get a (vague) idea of how much space is available on a device for your service worker caches.
Two of my favourite things together at last: pattern libraries and service workers. Infusion is a tool for generating pattern libraries that also work offline.
Thinking about it, it makes total sense that a pattern library should be a progressive web app.
There are some great service worker optimisation tips in these slides.
Along the lines of John’s recent post, Henrik makes the business case for progressive web apps.
He also points out how they can be much better than native apps for controlling hardware.
They can be up and running in a fraction of the time whether or not they were already “installed” and unlike “apps” can be saved as an app on the device at the user’s discretion!
Essentially they’re really great for creating “ad hoc” experiences that can be “cold started” on a whim nearly as fast as if it were already installed.
John makes the point that unless you’re one of the big, big players, your native app is really going to struggle to find an audience. But that’s okay—a progressive web app might be exactly what you need.
In short, using native apps as a path to reaching a large number of potential customers and benefitting from crucial network effects is close to impossible.
But, in the meantime, the Web has responded to the very significant impact that native apps had on user behaviour.
For me, the strength of the web has never been about how it can help big companies—it’s about how it can amplify and connect the niche players.
Manifest files can have categories now. Time to update those JSON files.
A fantastic piece by Aaron who—once again—articulates what I’ve been thinking:
Your site—every site—should be a PWA.
He clearly explains the building blocks of progressive web apps—HTTPS, a manifest file, and a service worker—before describing different scenarios for different kinds of sites:
Progressive Web Apps may seem overly technical or beyond the needs of your project, but they’re really not. They’re just a shorthand for quality web experiences—experiences that can absolutely make a difference in our users’ lives.
Paul goes into detail describing how he built a progressive web app that’s actually progressive (in the sense of “enhancement”). Most of the stuff about sharing code between server and client goes over my head, but I understood enough to get these points:
- the “app shell” model is not the only—or even the best—way of building a progressive web app, and
- always, always, always render from the server first.
The slides from Calum’s presentation about progressive web apps. There are links throughout to some handy resources.
This primer on progressive web apps starts by dispelling some myths:
- Your thing does not have to be an “Application” to be a PWA.
- PWAs are not specifically made for Google or Android.
- PWAs are ready and safe to use today.
Then it describes the three-step programme for turning your thing into a progressive web app:
- The Manifest.
- Go HTTPS.
- The Service Worker.
Tell it, brother!
AMP is a symptom that someone, somewhere, thinks the web is failing so badly (so slow, so unresponsive) for a portion of the world that they want to take all the content and package it back up in a sterile, un-webby, branded box. That makes me so sad. PWAs, to me, are a potential treatment.
Of all the sites to pick to demo progressive web apps, we get the cesspit that is Hacker News …I guess it is possible to polish a turd.
Anyway, here are some examples of using frameworks to create alternative Hacker News readers. So the challenge here is to display some text to read..
That’s right: React appears in both. See, it’s not about the tools; it’s about how you use ‘em.