# Discourse as a Progressive Web App

**URL:** <https://meta.discourse.org/t/discourse-as-a-progressive-web-app/47265>\
**Category:** Feature\
**Created:** [7월 14, 2016, 12:40오전 UTC](https://meta.discourse.org/t/discourse-as-a-progressive-web-app/47265 "2016-07-14T00:40:59Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![barryvan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/barryvan/32/82635_2.png) [@barryvan](https://meta.discourse.org/u/barryvan)\
**Post date:** [7월 14, 2016, 12:40오전 UTC](https://meta.discourse.org/t/discourse-as-a-progressive-web-app/47265/1 "2016-07-14T00:40:59Z")

</div>

### 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](https://ada.is/blog/2016/06/01/yet-another-progressive-webapp-post/), 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>`:

```plaintext
<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 · GitHub](https://github.com/DockYard/ember-service-worker) could provide a pluggable service worker engine upon which useful functionality could be built.

---

_[View the full topic](https://meta.discourse.org/t/discourse-as-a-progressive-web-app/47265)._