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.
As you might expect, lots of sites just don’t work, but there are plenty of sites that work just fine—Google search, Amazon, Wikipedia, BBC News, The New York Times. Not bad!
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.
I love, love, *love, traintimes.org.uk—partly because it’s so useful, but also because it’s so fast. I know public transport is the clichéd use-case when it comes to talking about web performance, but in this case it’s genuine: I use the site on trains and in airports.
Matthew gives a blow-by-blow account of the performance optimisations he’s made for the site, including a service worker. The whole thing is a masterclass in performance and progressive enhancement. I’m so glad he took the time to share this!
If your company is or is planning on doing business in emerging markets, architecting your web applications for performance through progressive enhancements is one easy way to drastically improve accessibility, retention, and user experience.
This article uses “progressive enhancement” and “progressive web app” interchangeably, which would be true in an ideal world. This is the first of a three part series, and it sounds like it will indeed document how to take an existing site and enhance it into a progressive web app—a strategy I much prefer to creating a separate silo that only works for a subset of devices (the app-shell model being pushed by Google).
Ethan’s been thinking about the trends he’s noticed in the work he’s doing:
- prototypes over mockups,
- preserving patterns at scale, and
- thinking about a design’s layers.
On that last point…
The web’s evolution has never been charted along a straight line: it’s simultaneously getting slower and faster, with devices new and old coming online every day.
A step-by-step guide to building progressive web apps. It covers promises, service workers, fetch, and cache, but seeing as it’s from Google, it also pushes the app-shell model.
This is a handy resource but I strongly disagree with some of the advice in the section on architectures (the same bit that gets all swoonsome for app shells):
Start by forgetting everything you know about conventional web design, and instead imagine designing a native app.
Avoid overly “web-like” design.
What a horribly limiting vision for the web! After all that talk about being progressive and responsive, we’re told to pretend we’re imitating native apps on one device type.
What’s really disgusting is the way that the Chrome team are withholding the “add to home screen” prompt from anyone who dares to make progressive web apps that are actually, y’know …webby.
This is wonderful meditation on the history of older technologies that degrade in varied conditions versus newer formats that fall of a “digital cliff”, all tied in to working on the web.
When digital TV fails, it fails completely. Analog TV, to use parlance of the web, degrades gracefully. The web could be similar, if we choose to make it so. It could be “the analog” web in contrast to “the digital” platforms. Perhaps in our hurry to replicate and mirror native platforms, we’re forgetting the killer strength of the web: universal accessibility.
The second part of Bruce’s excellent series begins by focusing on the usage of proxy browsers around the world:
But how!? Well, Bruce has the answer:
I call this amazing new technique “progressive enhancement.”
You heard it here first, folks!
An open beta of Smashing Magazine’s redesign, which looks like it could be a real poster child for progressive enhancement:
A nice look at the fallbacks that are built into CSS.
Tim Bray lists the options available to a technically-minded person thinking about their career path …but doesn’t mention the option of working at an agency.
Some good long-zoom observations in here:
The bad news that it’s a lot of work. We’re a young profession and we’re still working out our best practices, so the ground keeps changing under you; it doesn’t get easier as the decades go by.
The good news is that it doesn’t get harder either. Once you learn to stop expecting your knowledge to stay fresh, the pace of innovation doesn’t feel to me like it’s much faster (or slower) now than it was in 1987 or 1997 or 2007. More good news: The technology gets better. Seriously, we are so much better at building software now than we used to be in any of those other years ending in 7.
A useful tool to help you generate a manifest file, icons, and a service worker for your progressive web
Phil describes the process of implementing the holy grail of web architecture (which perhaps isn’t as difficult as everyone seems to think it is):
I have been experimenting with something that seemed obvious to me for a while. A web development model which gives a pre-rendered, ready-to-consume, straight-into-the-eyeballs web page at every URL of a site. One which, once loaded, then behaves like a client-side, single page app.
Now that’s resilient web design!
A nice straightforward account of building and testing a progressive web a… I mean, website.
I think every website from now on should use some of the Progressive Web App features. It’s even confusing to call it “Apps” as it applies to all websites and apps.
A practical guide to Progressive Web Apps for organisations who don’t know anything about Progressive Web Apps : Records Sound the Same
Sally gives a really good introduction to using service workers as a progressive enhancement.
Scott runs through the latest improvements to the Filament Group website. There’s a lot about HTTP2, but also a dab of service workers (using a similar recipe to my site).
Oh, how I wished everyone approached building for the web the way that Rachel does. Smart, sensible, pragmatic, and exciting!