Tags: offline

104

sparkline

Saturday, September 23rd, 2017

Progressive Web Apps? No, we are building Alien Web Apps | Condé Nast Technology

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.

Yes!

This simply isn’t true. Disappointingly, It is what most of the documentation, blog posts and public discourse seem to imply.

Preach it!

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.

Friday, September 22nd, 2017

How much storage space is my Progressive Web App using? | Dean Hume

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.

Tuesday, September 19th, 2017

Infusion: An Inclusive Documentation Builder

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.

Sunday, September 17th, 2017

Tame your Service Worker before your Progressive Web App go into the wild by Maxim Salnikov

There are some great service worker optimisation tips in these slides.

Monday, September 11th, 2017

Betting on the Web

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.

Friday, September 1st, 2017

Yes, That Web Project Should Be a PWA · An A List Apart Article

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:

  • Informational
  • Periodical
  • Transactional
  • Social
  • Software
  • Institutional

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.

Highly recommended!

Thursday, August 24th, 2017

A Progressive Roadmap for your Progressive Web App - Cloud Four

Jason lists the stages of gradually turning the Cloud Four site into a progressive web app:

And you can just keep incrementally adding and tweaking:

You don’t have to wait to bundle up a binary, submit it to an app store, and wait for approval before your customers benefit.

Sunday, August 20th, 2017

Offline POSTs with Progressive Web Apps – Web Dev @ Microsoft – Medium

This is a smart way to queue up POST submissions for later if the user is offline. It’s not as powerful as background sync (because it requires the user to revisit your site) but it’s a good fallback for browsers that support service workers but don’t yet support background sync

Thursday, August 3rd, 2017

Attachment #317095 for bug #175115

I’ve never been so excited by a single diff in a JSON file.

Service workers are coming to Safari.

Wednesday, July 26th, 2017

Web Publications for the Open Web Platform: Vision And Technical Challenges

Given my experience publishing Resilient Web Design as a web book, I think I should take a good look at this nascent spec.

What we envision for Packaged Web Publications is similar to the goals and techniques of Progressive Web Apps: breaking the boundaries between web sites and mobile apps, an emphasis on “offline” paradigms, and so on. The time is right to broaden the scope and power of the web to include publications.

Friday, July 14th, 2017

You’re Offline | Max Böck - Frontend Web Developer

This looks like a sensible way to detect if the user is offline, and provide appropriate feedback, like making certain links or forms inactive.

Introducing PWAs

The slides from Calum’s presentation about progressive web apps. There are links throughout to some handy resources.

Thursday, July 13th, 2017

How to turn your website into a PWA | Max Böck - Frontend Web Developer

This primer on progressive web apps starts by dispelling some myths:

  1. Your thing does not have to be an “Application” to be a PWA.
  2. Your thing does not have to be a Javascript-powered single page app.
  3. PWAs are not specifically made for Google or Android.
  4. PWAs are ready and safe to use today.

Then it describes the three-step programme for turning your thing into a progressive web app:

  1. The Manifest.
  2. Go HTTPS.
  3. The Service Worker.

Thursday, July 6th, 2017

Your Site—Any Site—Should be a PWA | Aaron Gustafson

Tell it, brother!

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.

Sunday, June 25th, 2017

Service Worker gotchas

A great collection of learned lessons from implementing service workers.

I really, really like it when people share their own personal experiences and “gotchas!” like this.

Monday, June 5th, 2017

Johannes Dachsel – Making my website work offline – a service worker module for Processwire

If you use the ProcessWire Content Management System, Johannes has written a handy plug-in that allows you to specify which files should be cached by a service worker.

Wednesday, May 31st, 2017

HN PWA - Hacker News readers as Progressive Web Apps

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..

Four of them render absolutely no content without JavaScript.

In the Hall of Shame we have React, Preact, Angular, and Polymer.

In the Hall of Fame, we have the ones doing it right: React, Vue, and Viper.

That’s right: React appears in both. See, it’s not about the tools; it’s about how you use ‘em.

Tuesday, May 23rd, 2017

Going offline at Indie Web Camp Düsseldorf

I’ve just come back from a ten-day trip to Germany. The trip kicked off with Indie Web Camp Düsseldorf over the course of a weekend.

IndieWebCamp Düsseldorf 2017

Once again the wonderful people at Sipgate hosted us in their beautiful building, and once again myself and Aaron helped facilitate the two days.

IndieWebCamp Düsseldorf 2017

Saturday was the BarCamp-like discussion day. Plenty of interesting topics were covered. I led a session on service workers, and that’s also what I decided to work on for the second day—that’s when the talking is done and we get down to making.

IndieWebCamp Düsseldorf 2017 IndieWebCamp Düsseldorf 2017 IndieWebCamp Düsseldorf 2017 IndieWebCamp Düsseldorf 2017

I like what Ethan is doing on his offline page. He shows a list of pages that have been cached, but instead of just listing URLs, he shows a title and description for each page.

I’ve already got a separate cache for pages that gets added to as the user browses around my site. I needed to figure out a way to store the metadata for those pages so that I could then display it on the offline page. I came up with a workable solution, and interestingly, it involved no changes to the service worker script at all.

When you visit any blog post, I put metadata about the page into localStorage (after first checking that there’s an active service worker):

if (navigator.serviceWorker && navigator.serviceWorker.controller) {
  window.addEventListener('load', function() {
    var data = {
      "title": "A minority report on artificial intelligence",
      "description": "Revisiting Spielberg’s films after a decade and a half.",
      "published": "May 7th, 2017",
      "timestamp": "1494171049"
    };
    localStorage.setItem(
      window.location.href,
      JSON.stringify(data)
    );
  });
}

In my case, I’m outputting the metadata from the server, but you could just as easily grab some from the DOM like this:

var data = {
  "title": document.querySelector("title").innerText,
  "description": document.querySelector("meta[name='description']").getAttribute("contents")
}

Meanwhile in my service worker, when you visit that same page, it gets added to a cache called “pages”. Both localStorage and the cache API are using URLs as keys. I take advantage of that on my offline page.

The nice thing about writing JavaScript on my offline page is that I know the page will only be seen by modern browsers that support service workers, so I can use all sorts of fancy from ES6, or whatever we’re calling it now.

I start by looping through the keys of the “pages” cache (that’s right—the cache API isn’t just for service workers; you can access it from any script). Then I check to see if there is a corresponding localStorage key with the same string (a URL). If there is, I pull the metadata out of local storage and add it to an array called browsingHistory:

const browsingHistory = [];
caches.open('pages')
.then( cache => {
  cache.keys()
  .then(keys => {
    keys.forEach( request => {
      let data = JSON.parse(localStorage.getItem(request.url));
        if (data) {
          data['url'] = request.url;
          browsingHistory.push(data);
      }
    });

Then I sort the list of pages in reverse chronological order:

browsingHistory.sort( (a,b) => {
  return b.timestamp - a.timestamp;
});

Now I loop through each page in the browsing history list and construct a link to each URL, complete with title and description:

let markup = '';
browsingHistory.forEach( data => {
  markup += `
<h2><a href="${ data.url }">${ data.title }</a></h2>
<p>${ data.description }</p>
<p class="meta">${ data.published }</p>
`;
});

Finally I dump the constructed markup into a waiting div in the page with an ID of “history”:

let container = document.getElementById('history');
container.insertAdjacentHTML('beforeend', markup);

All those steps need to be wrapped inside the then clause attached to caches.open("pages") because the cache API is asynchronous.

There you have it. Now if you’re browsing adactio.com and your network connection drops (or my server goes offline), you can choose from a list of pages you’ve previously visited.

The current situation isn’t ideal though. I’ve got a clean-up operation in my service worker to limit the number of items stored in my “pages” cache. The cache never gets bigger than 35 items. But there’s no corresponding clean-up of metadata stored in localStorage. So there could be a lot more bits of metadata in local storage than there are pages in the cache. It’s not harmful, but it’s a bit wasteful.

I can’t do a clean-up of localStorage from my service worker because service workers can’t access localStorage. There’s a very good reason for that: the localStorage API is synchronous, and everything that happens in a service worker needs to be asynchronous.

Service workers can access indexedDB: it’s asynchronous. I could use indexedDB instead of localStorage, but I’m not a masochist. My best bet would be to use the localForage library, which wraps indexedDB in the simple syntax of localStorage.

Maybe I’ll do that at the next Homebrew Website Club here in Brighton.

Service Worker Security FAQ - The Chromium Projects

Got questions about the security of service workers? This document probably has the answer.

Thursday, May 4th, 2017

Going offline. — Ethan Marcotte

Ethan has added a service worker to his site and he’s got a nifty little recipe for showing a list of saved-for-offline articles.