Discourse as a Progressive Web App


(Barry van Oudtshoorn) #1

Current functionality

Discourse works beautifully when you pin it your homescreen on an Android device from Chrome (or Firefox) – but this isn’t particularly discoverable out of the box. Is it worth thinking about advertising the fact that they can tap on the menu in Chrome/Firefox and add it to their homescreen? Then it’ll look and feel like a native app, without having any of the normal browser UI, like an address bar etc.

Future functionality: PWA

@codinghorror Would it perhaps be worthwhile jumping through the necessary hoops to get browsers to recognise Discourse instances as Progressive Web Apps? According to Yet another blog about the state and future of Progressive Web App - The blog of Ada Rose Cannon, this means

  • has a service worker (requires https)

HTTPS will be out of the box for (I assume) most paying customers, and can be set up by those running their own instances.

  • has a web app manifest (with at least minimal config)

Looks like Discourse already does this.

  • it is the second distinct visit to the web site.

This will happen organically – although I note that Opera has been experimenting with providing users with an explicit indicator from the first visit, so this may become unnecessary.

Hacking in a service worker

It looks as though the only piece that is missing for this is a service worker. The good news, of course, is that there’s no requirement the service worker actually do anything! This means that is should be possible to “hack this in” by

  1. Adding a stub JS file, called, say, sw.js, to the root of the domain
  2. Popping the following snippet in the <head>:
<script>
  if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/sw.js').then(registration => {
      console.log('ServiceWorker registered in scope ', registration.scope)
    }).catch(error => {
      console.warn('Failed to register ServiceWorker', error);
    });
  }
</script>

(Of course, it may be necessary to “un-es6” this – but I think you can safely assume that any browser which supports service worker supports fat arrows and the global console object!)

Making the ServiceWorker do useful work

First prize would, naturally, be to have the service worker do some useful work. I’m not familiar with Ember, but it looks like GitHub - DockYard/ember-service-worker: A pluggable approach to Service Workers for Ember.js could provide a pluggable service worker engine upon which useful functionality could be built.


Make Discourse play nice with the Wayback Machine
(Rafael dos Santos Silva) #2

You mean this?


(Barry van Oudtshoorn) #3

@Falco That’s really nice, yes. But now let’s go further! Once it’s added to the homescreen, let’s make it work offline (with a ServiceWorker). :smiley:


(Jeff Atwood) #4

That is what the push notifications plugin, currently in alpha, does. So you are proposing all stuff that … already exists?


(Barry van Oudtshoorn) #5

@codinghorror Possibly – I wasn’t aware that the push notifications plugin also gave offline capabilities…? That is to say, can I be set my phone to aeroplane mode and still launch the app, read (some) topics (maybe not post), and have my activities synchronised back up when I re-establish connectivity?


(Jeff Wong) #6

Service workers don’t allow you to connect offline (aeroplane mode), but allow network activity to happen (such as push notifications) even when you don’t have a tab open.

I don’t think there are currently any plans to have content available offline.


(Barry van Oudtshoorn) #7

@awole20 Understood that Service Workers won’t transcend connectivity. :slight_smile: They allow you to effectively act as a proxy server between the web application itself and the network, caching and managing requests. It’d be pretty sweet if Discourse were semi-available offline – letting you read (or re-read) cached topics and so on. That is, I guess, the final end-point in this topic.


(Sam Saffron) #8

Yes, offline support is something both @eviltrout and myself want to get to. It is not slotted for any release yet, I imagine we will get to it some time before 2.0.


(Tom Newsom) #9

1.10? :wink:

post must be at least 20 characters


(Robin Ward) #10

Definitely! Thing is, it’s not even hard to get the basics working due to the way the app is all JS.

The main annoyance is that AppCache is much better supported than ServiceWorkers. AppCache is “deprecated” but it’s the only option on iOS.


(Barry van Oudtshoorn) #11

Yeah, but it’s not as though iOS is widely-used or anything. :stuck_out_tongue:

I’m not sure that AppCache and ServiceWorkers are really comparable, to be honest; they solve quite different problems. AppCache is about providing developers with a really powerful, hard-to-use-safely footgun – things haven’t really moved on since this 2012 article to that effect. I’m actually not sure how AppCache could be used to provide reasonable offline capabilities in a Discourse instance…

ServiceWorkers, by contrast, are a way of controlling the interaction between your app and the network in a fine-grained and completely arbitrary way.

My thinking, then, would be to build for the future – ServiceWorkers – and hope that Apple eventually works to make them available in iOS Safari (notwithstanding the fact that they would allow web apps to compete with the app store, and thus go against Apple’s financial interests). This would bring benefits to all users of Chrome, Firefox, and Edge, regardless of device. I’m not sure what the stats are like around the world, but that would bring decent capabilities to 60-75% of our customers.

And Progressive Web Apps are all about Progressive Enhancement, after all. :slight_smile:


(Robin Ward) #12

AppCache has a lot of problems, but it absolutely could be used to provide offline access. I’ve seen quite a few examples of Ember apps doing this. You just have to work around the awkwardness.

Service Worker is a non starter on iOS which is a sizeable portion of mobile users.

So it’s the question of the poor API that’s “deprecated” or the one that isn’t fully supported yet.


(Rafael dos Santos Silva) #13

Service Worker will give 60% ~ 90% market share, and occasionally 100%.

Service Workers are under consideration on Safari and on the 5 year plan.


(Robin Ward) #14

And AppCache works on 100% of devices today :slight_smile:

Look don’t mistake this for a decision I’ve made, I’m just saying there’s a reason why most people I know who are serious about offline are using AppCache right now.


(Rafael dos Santos Silva) #15

Can you give me some examples of website with AppCache? This is something new, that I need to study.

Using Service Workers I really like the implementation of Telegram Web. It’s very fast, and ask for updates.

Twitter new mobile webapp also uses Service Workers, but it’s kinda buggy with flaky connections.


(Felix Freiberger) #16

One huge drawback of AppCache is that it’s caching exactly one block of data. This must obviously contain the Discourse “App”, and shouldn’t contain all posts (of course), so the actual data (the posts to be cached) has to be put into something like localStorage, which seems to be often limited to 5 MB.

(I have some experience with AppCache as I have built one webapp with it. AppCache is unflexible, confusing and punishes you for any mistake you make, but works pretty well if used correctly.)


(Dante) #18

examples of website Progressive Web Apps  |  Web  |  Google Developers


(Jeff Atwood) #19

Aha but is it though? Can I use... Support tables for HTML5, CSS3, etc

https://developer.apple.com/library/prerelease/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_1.html

I guess the “service” part is still missing.


(Robin Ward) #20

Yeah web workers are different from service workers, despite sounding the same. Best we can hope for is the next iOS release.


(Sam Saffron) #21

Either that or the antique, deprecated and quirky app cache :frowning: