Progressing the web

Frances has written up some of the history behind her minting of the term “progressive web app”. She points out that accuracy is secondary to marketing:

I keep seeing folks (developers) getting all smart-ass saying they should have been PW “Sites” not “Apps” but I just want to put on the record that it doesn’t matter. The name isn’t for you and worrying about it is distraction from just building things that work better for everyone. The name is for your boss, for your investor, for your marketeer.

Personally, I think “progressive web app” is a pretty good phrase—two out of three words in it are spot on. I really like the word “progressive”, with its echoes of progressive enhancement. I really, really like the word “web”. But, yeah, I’m one of those smart-asses who points out that the “app” part isn’t great.

That’s not just me being a pedant (or, it’s not only me being a pedant). I’ve seen people who were genuinely put off investigating the technologies behind progressive web apps because of the naming.

Here’s an article with the spot-on title Progressive Web Apps — The Next Step In Responsive Web Design:

Late last week, Smashing Magazine, one of the largest and most influential online publications for web design, posted on Facebook that their website was “now running as a Progressive Web App.”

Honestly, I didn’t think much of it. Progressive Web Apps are for the hardcore web application developers creating the next online cloud-based Photoshop (complicated stuff), right? I scrolled on and went about my day.

And here’s someone feeling the cognitive dissonance of turning a website into a progressive web app, even though that’s exactly the right thing to do:

My personal website is a collection of static HTML files and is also a progressive web app. Transforming it into a progressive web app felt a bit weird in the beginning because it’s not an actual application but I wanted to be one of the cool kids, and PWAs still offer a lot of additional improvements.

Still, it could well be that these are the exceptions and that most people are not being discouraged by the “app” phrasing. I certainly hope that there aren’t more people out there thinking “well, progressive web apps aren’t for me because I’m building a content site.”

In short, the name might not be perfect but it’s pretty damn good.

What I find more troubling is the grouping of unrelated technologies under the “progressive web app” banner. If Google devrel events were anything to go by, you’d be forgiven for thinking that progressive web apps have something to do with AMP or Polymer (they don’t). One of the great things about progressive web apps is that they are agnostic to tech stacks. Still, I totally get why Googlers would want to use the opportunity to point to their other projects.

Far more troubling is the entanglement of the term “progressive web app” with the architectural choice of “single page app”. I’m not the only one who’s worried about this.

Here’s the most egregious example: an article on Hacker Noon called Before You Build a PWA You Need a SPA.

No! Not true! Literally any website can be a progressive web app:

That last step can be tricky if you’re new to service workers, but it’s not unsurmountable. It’s certainly a lot easier than completely rearchitecting your existing website to be a JavaScript-driven single page app.

Alas, I think that many of the initial poster-children for progressive web apps gave the impression that you had to make a completely separate app/site at a different URL. It was like a return to the bad old days of m. sites for mobile. The Washington Post’s progressive web app (currently offline) went so far as to turn away traffic from the “wrong” browsers. This is despite the fact that the very first item in the list of criteria for a progressive web app is:

Responsive: to fit any form factor

Now, I absolutely understand that the immediate priority is to demonstrate that a progressive web app can compete with a native mobile app in terms of features (and trounce it in terms of installation friction). But I’m worried that in our rush to match what native apps can do, we may end up ditching the very features that make the web a universally-accessible medium. Killing URLs simply because native apps don’t have URLs is a classic example of throwing the baby out with the bath water:

Up until now I’ve been a big fan of Progressive Web Apps. I understood them to be combining the best of the web (responsiveness, linkability) with the best of native (installable, connectivity independent). Now I see that balance shifting towards the native end of the scale at the expense of the web’s best features. I’d love to see that balance restored with a little less emphasis on the “Apps” and a little more emphasis on the “Web.” Now that would be progressive.

If the goal of the web is just to compete with native, then we’ve set the bar way too low.

So if you’ve been wary of investing the technologies behind progressive web apps because you’re “just” building a website, please try to see past the name. As Frances says:

It’s marketing, just like HTML5 had very little to do with actual HTML. PWAs are just a bunch of technologies with a zingy-new brandname.

Literally any website can—and should—be a progressive web app. Don’t let anyone tell you otherwise.

I was at an event last year where I heard Chris Heilmann say that you shouldn’t make your blog into a progressive web app. I couldn’t believe what I was hearing. He repeats that message in this video chat:

When somebody, for example, turns their blog into a PWA, I don’t see the point. I don’t want to have that icon on my homepage. This doesn’t make any sense to me.

Excuse me!? Just because you don’t want to have someone’s icon on your home screen, that person shouldn’t be using state-of-the-art technologies!? Excuse my French, but Fuck. That. Shit!

Our imaginations have become so limited by what native mobile apps currently do that we can’t see past merely imitating the status quo like a sad cargo cult.

I don’t want the web to equal native; I want the web to surpass it. I, for one, would prefer a reality where my home screen isn’t filled with the icons of startups and companies that have fulfilled the criteria of the gatekeepers. But a home screen filled with the faces of people who didn’t have to ask anyone’s permission to publish? That’s what I want!

Like Frances says:

Remember, this is for everyone.

Have you published a response to this? :

Responses

Hidde

“Literally any website can be a progressive web app: switch to HTTPS, add a manifest file, and add a service worker” adactio.com/journal/12461

# Posted by Hidde on Wednesday, June 28th, 2017 at 9:02am

Simon R Jones

“I don’t want the web to equal native; I want the web to surpass it.”

Aaron Gustafson

The other day, Frances Berriman—who coined the term “Progressive Web App”—wrote a bit about how she came up with that name. In it she clearly points out that the name has become a little problematic in dev circles:

I keep seeing folks (developers) getting all smart-ass saying they should have been PW “Sites” not “Apps” but I just want to put on the record that it doesn’t matter. The name isn’t for you and worrying about it is distraction from just building things that work better for everyone. The name is for your boss, for your investor, for your marketeer. It’s a way for you to keep making things on the open web, even those things that look really “app-y” and your company wants to actually make as a native app, 3 times over. They don’t want you to make websites anymore, but you still can if you’re sneaky, if you tell them it’s what they think they want.

As someone who is at once a practitioner, an educator, and a consultant on web projects, this can be tough to wrestle with. But like DHTML, Ajax, and HTML5 before, when viewed as a catch-all term for an approach to building stuff for the web it really shouldn’t matter that the word “app” is in there. Sure, it could have been “site” or “thang”, but when we—and I’m talking to the practitioners here—hear someone talking about PWAs, we need to take the broad view.

Jeremy Keith made a really solid case for the broad usefulness of PWAs:

Literally any website can be a progressive web app:

  • switch over to HTTPS,
  • add [a JSON manifest file](https://www.w3.org/TR/appmanifest/) with your [metacrap](https://www.well.com/~doctorow/metacrap.htm), and
  • add a service worker.

PWAs don’t require you use a particular JavaScript framework or any JavaScript framework at all. You don’t need to be building a Single Page App either. In fact, it will probably be easier if you’re not.

If you work on a website, there’s a really good chance your site could benefit from the technologies and approaches aggregated under the PWA umbrella:

  • Works on any device (a.k.a. progressive enhancement and responsive design)? Check.
  • Secure by default? Check.
  • Links to any core functionality or content? Check.
  • Easily shared and discovered? Check and check.
  • Better network resilience and faster page loads? Check and mate.

Depending on what you’re building, your site might even benefit from features like

  • push notifications,
  • syncing data in the background (when your site’s not open), and
  • install-ability.

Every project is different, but there’s a good chance yours should be a PWA or at least have some of the features of one. To quote Christian Heilmann:

Nothing necessary to turn your current web product into a PWA is a waste. All steps are beneficial to the health and quality of your product.

What are you waiting for?

mxb.at

# Wednesday, July 19th, 2017 at 10:09pm

glueckpress.com

Note: Content might be outdated!

As someone providing support for a WordPress caching plugin for a living and dealing with questions around page caching and website performance all day long, I am fascinated by the concept of Progressive Web Apps. So I made one, just for the fun of it!

Want to see the web app in action first and read later? Here you go:

WordPress is not WordPress.com

To see the website turning into a standalone app, just open it in your phone’s browser, add it to your home screen, and then re-open it from there. Play around with airplane mode, or open it when you’re on a 2G network—it should always be accessible.

Progressive Web Apps—what’s the fuzz about?

If you have not, or only vaguely heard about PWAs, the basic concept is this: Make content available offline, so a person who would access your site once would be able to pull it up later even if their phone happens to be on a slow network connection, or is even completely offline.

If you are interested in benefits for engagement and conversion, I recommend for you to read some of the case studies on PWA Stats.

Also, turning your website into a PWA does not require to re-build that website as a “single-page app”. Not at all!

Literally any website can be a progressive web app:

3abeee6efb766f1e608b850cda698786

That last step can be tricky if you’re new to service workers, but it’s […] certainly a lot easier than completely rearchitecting your existing website to be a JavaScript-driven single page app.

Jeremy Keith, Progressing the web

You can make a PWA, too!

For my own little PWA experiment, I followed a Beginner’s guide to making Progressive Web Apps, kindly posted by a Samsung Developer whose real name I would love to learn, so I could thank him properly.

Making a PWA (a trivially simple one, admittedly) was pretty straightforward with that tutorial. I did not pick a WordPress site for my first attempt, of course, but went with just the one page of static HTML linked at the top of this article.

Obviously, once you’re done, you’re going to want to know how well you’ve done. I used the Lighthouse audit panel in Chrome:

Lighthouse report in Chrome’s Audits panel showing mostly scores of 100. That score of 97 for a11y is caused by a third-party’s decision making about the contrast ratio of their brand colours.

So yay, that was easy! 🎉

What’s next? WordPress?

The nice people over at Cloud Four have kindly shared their experience of how they turned their company WordPress website into a PWA.

They cover some of the technical bits, but what interested me most was their decision making for the cache strategy: Which pages (or views) should be available offline, and which should be replaced by a default placeholder page? Obviously, having a service worker fetch an entire larger website into the browser’s cache would not make sense.

I’d venture to predict that PWAs will be all over the place in a year from now; which obviously isn’t a very dramatic prediction since they have started to appear all over the place already.

I found some WordPress plugins related to offline content and service workers in the WordPress plugin directory, but most of them seem to provide a proof of concept rather than a ready-to-use product for WordPress site owners. Which is cool, I mean, no rush.

Do you have any first-hand experience turning a WordPress site into a Progressive Web App, flesh out a cache strategy, and implement a service worker? I’d love to hear about your thoughts in the comments!

# Sunday, August 13th, 2017 at 10:55am

depone.net

ServiceWorker Eine verlässliche Internetverbindung, und damit den ständigen Zugriff auf Webseiten oder Server, gibt es zwar theoretisch, der Alltag sieht jedoch anders aus. An manchen Orten ist nur eine Verbindung in Edge-Geschwindigkeit möglich, an anderen Tagen scheint LTE in vollem Umfang verfügbar, die Verbindung klappt trotzdem nicht. In anderen Situationen hat eine scheinbar schnelle DSL-Anbindung Schluckauf was eine verlässliche Datenübertragung unmöglich macht. Um Webseiten auch in den eben beschriebenen Szenarien benutzbar zu machen, steht in einigen aktuellen Browsern ServiceWorker zur Verfügung. Chrome und Firefox unterstützen die Technologie bereits, in den kommenden Versionen von Edge und Safari wird sie erwartet. Artikel, Vorträge und Tweets zu ServiceWorker verfolge ich seit einiger Zeit interessiert. Am vergangenen Wochenende führte dieses Interesse zur Implementierung eines ServiceWorker für diese Webseite. Der Artikel Progressing the web von Jeremy Keith gab mir den entscheidenden Schubs mich tatsächlich dran zu wagen. Um meinen eigenen ServiceWorker zu erstellen orientierte ich mich an dem von Jeremy Keith und kombinierte diesen mit den Hinweisen von Michael Scharnagl, der in seinem Blog darüber schreibt wie er für seine WordPress-Seite einen eingerichtet hat. Das daraus resultierende ServiceWorker-Skript für diese Webseite findest Du hier. Auf welche Punkte lohnt es sich zu achten Der ServiceWorker muss im Root Verzeichnis liegen. Um ihn dennoch über das Theme verwalten zu können, folge ich dem Beispiel von Michael Scharnagl und erstelle einen Symbolic Link im Root Verzeichnis, der auf das Skript im Assets-Verzeichnis des Themes verweist. $ ln -s /var/www/virtual/user/wp-content/themes/netz/assets/js/serviceworker.min.js /var/www/virtual/user/serviceworker.min.js Den ServiceWorker registriere ich in der footer.php durch folgenden Aufruf: if (navigator.serviceWorker) { navigator.serviceWorker.register(‘/serviceworker.min.js’, { scope: ‘./’ }); window.addEventListener(‘load’, function() { if (navigator.serviceWorker.controller) { navigator.serviceWorker.controller.postMessage({‘command’: ‘trimCaches’}); } }); } Der zweite Teil dieses Skripts ruft die trimCaches-Funktion auf, die dafür sorgt, dass der Speicherhunger des ServiceWorkers nicht unersättlich ist, und ab einer gewissen Anzahl von gespeicherten Inhalten, die ältesten Einträge löscht. Den ServiceWorker habe ich so geschrieben, dass er Stylesheet, Javascript, die Hauptseiten und besuchte Seiten speichert. Diese stehen fortan sowohl dann zur Verfügung wenn die Besucherin offline ist als auch dann wenn der Server nicht erreichbar ist. Für den Fall, dass die angeforderten Inhalte nicht im Zwischenspeicher sind, habe ich eine Seite mit meinen Kontaktdaten und einer kurzen Info erstellt. Die Besucherinnen dieser Webseite bekommen also entweder die gewünschten Inhalte oder eine kurze Info und Kontaktdaten angezeigt, und nicht wie bisher die Offline-Meldung des Browsers. Bis zur Implementierung des ServiceWorkers gab ich meinem Stylesheet und dem Javascript eine Versionsnummer mit, dieses führte jedoch zu Fehlern beim Aufruf der Webseite aus dem Speicher. Daher hänge ich momentan keine Versionsnummer an meine eigenen Dateien an. Dies möchte ich demnächst aber wieder ändern, wollte es hier jedoch nicht unerwähnt lassen, da ich einen Moment gebraucht habe, um die Quelle der Fehler zu finden. Um die Implementierung des ServiceWorkers abzurunden, fügte ich dieser Webseite noch ein manifest.json hinzu, so dass Chrome sie zukünftig als Webapp erkennt. Auf diese Weise lässt sie sich als Progressive Web App installieren, und dadurch ganz einfach starten. Ausblick Für die neuen Versionen von Safari und Edge ist die volle Unterstützung von ServiceWorker angekündigt. Und die kommende iOS-Version soll Progressive Web Apps unterstützen, wodurch schließlich eine Installation einer Webapp auf den Homescreen von iPhone und iPad nichts mehr im Wege steht. Um Service Worker besser zu verstehen habe ich mir vorgenommen den Vortrag The Pragmatist’s Guide to Service Workers, den Lyza D Gardner auf der SmashingConf Freiburg 2016 gehalten hat, nochmals anzusehen. Veröffentlicht am 05.03.2018 von Daniel in Netzgestaltung.

# Monday, March 5th, 2018 at 3:14pm

mxb.dev

# Wednesday, April 14th, 2021 at 8:31am

18 Shares

# Shared by Jeremy Keith on Tuesday, June 27th, 2017 at 3:07pm

# Shared by Alberto Medina on Tuesday, June 27th, 2017 at 3:09pm

# Shared by Hubert 😎 SABLONNIÈRE on Tuesday, June 27th, 2017 at 3:13pm

# Shared by Lee Gunn on Tuesday, June 27th, 2017 at 3:18pm

# Shared by ge ricci on Tuesday, June 27th, 2017 at 3:18pm

# Shared by Rich Clark on Tuesday, June 27th, 2017 at 3:19pm

# Shared by Andrés Villanueva 🔥 on Tuesday, June 27th, 2017 at 3:36pm

# Shared by Baldur Bjarnason on Tuesday, June 27th, 2017 at 3:38pm

# Shared by Frances Berriman on Tuesday, June 27th, 2017 at 5:20pm

# Shared by Bradley Holt on Tuesday, June 27th, 2017 at 5:28pm

# Shared by Ian Clark on Tuesday, June 27th, 2017 at 6:27pm

# Shared by Saulius Kerusauskas on Tuesday, June 27th, 2017 at 7:37pm

# Shared by Niklas Ranås on Tuesday, June 27th, 2017 at 9:42pm

# Shared by Martin Auswöger on Wednesday, June 28th, 2017 at 10:14am

# Shared by tams sokari on Wednesday, June 28th, 2017 at 12:21pm

# Shared by A Book Apart on Wednesday, June 28th, 2017 at 5:51pm

# Shared by John Larsen on Wednesday, June 28th, 2017 at 6:00pm

# Shared by Jhonatan Jacinto on Wednesday, June 28th, 2017 at 6:02pm

36 Likes

# Liked by Ivan Wilson on Tuesday, June 27th, 2017 at 1:21pm

# Liked by Joschi Kuphal 吉 on Tuesday, June 27th, 2017 at 5:37pm

# Liked by just_sam on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Baldur Bjarnason on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Malte Ubl on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Andy Baio on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Cheney Tsai on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Lasha Krikheli on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Michael LaRoy on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Jeremy Wynn on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Simon McManus on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Frances Berriman on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Abdulaziz on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Vladimir Starkov on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Jay Greasley on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Marc Drummond on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Alberto Medina on Tuesday, June 27th, 2017 at 5:37pm

# Liked by Ian Clark on Tuesday, June 27th, 2017 at 6:39pm

# Liked by Saulius Kerusauskas on Tuesday, June 27th, 2017 at 8:03pm

# Liked by A Book Apart on Tuesday, June 27th, 2017 at 9:11pm

# Liked by Charles Stanhope on Tuesday, June 27th, 2017 at 9:39pm

# Liked by Danyel Becker on Tuesday, June 27th, 2017 at 11:25pm

# Liked by Julian Gaviria on Wednesday, June 28th, 2017 at 3:42am

# Liked by vollepeer on Wednesday, June 28th, 2017 at 9:02am

# Liked by James Milner on Wednesday, June 28th, 2017 at 10:29am

# Liked by Mizan :) on Wednesday, June 28th, 2017 at 2:12pm

# Liked by Jhonatan Jacinto on Wednesday, June 28th, 2017 at 6:22pm

# Liked by John Larsen on Wednesday, June 28th, 2017 at 6:23pm

# Liked by mumoss on Wednesday, June 28th, 2017 at 6:24pm

# Liked by Simon R Jones on Wednesday, June 28th, 2017 at 7:26pm

# Liked by Adrian D. Alvarez on Thursday, June 29th, 2017 at 1:43am

# Liked by Kelvin on Thursday, June 29th, 2017 at 2:34am

# Liked by Alex Russell on Thursday, June 29th, 2017 at 4:49pm

# Liked by Jay Robinson on Thursday, June 29th, 2017 at 10:23pm

# Liked by Gabor Lenard on Friday, June 30th, 2017 at 9:46pm

# Liked by Daniel on Sunday, May 12th, 2019 at 3:13pm

Related posts

Push

Mobile Safari finally ships the feature we’ve all been waiting for …but hardly anyone is going to get to use it.

Service worker weirdness in Chrome

Debugging an error message.

Backdoor Service Workers

The tragedy of the iframe commons.

A wager on the web

What’s the worst that could happen?

Read-only web apps

It’s fine to require JavaScript for read/write functionality. But have you considered a read-only mode without JavaScript?

Related links

Home Screen Advantage - Infrequently Noted

This is exactly what it looks like: a single-fingered salute to the web and web developers.

Read Alex’s thorough explanation of the current situation and then sign this open letter.

Cupertino’s not just trying to vandalise PWAs and critical re-engagement features for Safari; it’s working to prevent any browser from ever offering them on iOS. If Apple succeeds in the next two weeks, it will cement a future in which the mobile web will never be permitted to grow beyond marketing pages for native apps.

Also, remember this and don’t fall for it:

Apple apparently hopes it can convince users to blame regulators for its own choices.

Tagged with

Manton Reece - Apple is twisting the truth

When it benefits Apple, they take the DMA requirements much further than intended. When it doesn’t benefit them, they lean back on the “integrity” of iOS and barely comply at all.

Tagged with

People do use Add to Home Screen – Firefox UX

Oh no! My claim has been refuted by a rigourous scientific study of …checks notes… ten people.

Be right back: just need to chat with eleven people.

Tagged with

Web Push on iOS requires installing the web app - Webventures

Instead of doing what the competing browsers are doing (and learning from years of experience of handling Web Push), Apple decided to reinvent a wheel here. What they’ve turned up with looks a lot more like a square.

Tagged with

Why We Create Progressive Web Apps: A Conversation with Jeremy Keith

This is a really nice write-up by Sydney of the chat we had on her podcast.

Tagged with

Previously on this day

8 years ago I wrote On the side

My Clearleft colleagues are an inspiration.

9 years ago I wrote 100 words 097

Day ninety seven.

14 years ago I wrote Wait. They don’t love you like I love you.

Maps.

17 years ago I wrote Talking with the BBC about microformats

Sounds like a Billy Bragg album.

18 years ago I wrote For want of a nail…

…the kingdom was lost.

22 years ago I wrote Warchalking

When I get back to England, I’m going to have to trip a trip up to London and start looking out for chalkmarks.

22 years ago I wrote iBook redux

Hallelujah! My iBook is fixed.