Ringing in a New Year spurs the temptation to cast an eye to the future. With web technologies that future is usually tomorrow – or even later this afternoon – such is the pace of change. As amazing as this is, a side effect is that there can be quite a lot of noise and it’s hard to distinguish where to dedicate your attention.
Over the past few months there’s been an increasing amount of discussion and excitement around one particular area that’s worthy of our attention, and that’s ‘Progressive Web Applications’.
Earlier last year at UVD we ran a hack day and one of the outcomes was a small side project that involves a real-time photo stream that can be shared.
Steering the development I was adamant that this could – and more importantly, should – be built as a web application rather than as an installable native app. For me, if we could build something that could simply be shared and used via a URL it would improve the usability and discoverability of the product enormously. The long term plan was to develop a good base experience as a web application, and then when we hit features that require capabilities provided by a native only app, we’d support those in an enhanced experience with a native app.
Throughout the development we managed to achieve the base experience we’d hoped for, however simple things that would make the experience so much more polished had to be sacrificed due to a lack of technical capability in the mobile browsers. Requiring a network connection to access repeat visits and having to have the application open to know when new updates were available were also big sticking points. It felt slightly unfair to be able to achieve so much on the web to be robbed the niceties that users come to expect from a digital product on their device.
Then the future happened… or at least started to.
Progressive web applications
Originally coined – I believe – by Alex Russell in the excellent article Progressive Web Apps: Escaping Tabs Without Losing Our Soul progressive web applications are the consequence of employing a suite of emerging web technologies to progressively enhance a web page with the abilities – where supported by the browser – to become more ‘appy’. In short, mobile websites can opt in to functionality to make them feel more like a native application, whilst preserving all the magic of them being websites.
As mentioned, there’s no specific technical feature or technology here; rather a range, which will no doubt expand over time. An overview of these recent additions are;
- Service Workers which allows us to intercept network requests and thus provide a range of offline support when no network is available.
- Push API used alongside service workers, allows an application to subscribe to events and send push notifications to the users’ device, just like native applications.
- Web app manifest – A JSON file containing meta data for the web application which, amongst other things allows developers to configure how the mobile OS should launch and display on the home screen and when launching.
- Background Sync – Very much in its infancy but background sync will primarily solve the problem of trying to send data to a server when a network isn’t available by queuing it and sending it when network becomes available, even if a user has navigated away from the application. It can also request data, and along with push notifications, notify the user when that data is fetched.
- Add to Home Screen Banner – After meeting a set of requirements and a heuristic – that’s still being debated – the browser will prompt to install to home screen. If nothing else, in the short term this will help improve the awareness that web pages can be ‘installed’ to the device.
- Web Workers – whilst not new to mobile browsers, techniques to offload a lot of heavy computational work to a separate thread keeping the UI thread free and reactive are becoming better documented, which may lead to significant architectural changes in how we author apps in the future.
In the wild
Despite browser support just emerging – or being dragged kicking and screaming in mobile Safari’s case – a few stellar examples of progressive web applications exist.
FlipKart, a massive e-commerce outfit in India re-launched their mobile presence using these techniques and have an excellent writeup of their progressive web app on their blog and were featured at the chrome dev summit explaining the process.
Nolan Lawson has a stunning proof of concept – pokedex, taking his experience developing apps for native (android in this case) and attempting to create a similar experience on web. The emphasis is on performance here (network and UI responsiveness) and there’s some really interesting techniques such as using Web Workers to handle most of the application and sending rendering instructions back to the main thread to keep it as unblocked as possible. The blog post summarising his approach is arguably one of the best articles I read last year.
Progressive Web Apps are, for me, the maturing of a strategy, supported by developing technologies for building for the web. Responsive web design techniques were the genesis and we’re now seeing the next evolution.
The absolute core benefit of the web is in its reach: the ability to serve one URL and be immediately accessible to anyone with a browser on almost any device. The trade-off is varying capabilities of the browsers consuming what you serve. This is progressive enhancement: the art of distilling your product down into a core valuable experience and layering functionality as it becomes available. It’s easier said than done certainly, but more difficult when the functionality your product needs to compete simply doesn’t exist yet. Fortunately as more and more of the web is consumed on mobile devices the browsers are starting to catch up and innovate. For me this is one of the most exciting areas of web development happening this afternoon.. tomorrow.. and the future.