Building for a future mobile web
Paul Kinlan considers how the future mobile web will combine
the perks of native apps with the best bits of the web
Mobile has changed the world. Everyone on the planet is getting access to the internet, many for the first time. In India over six million internet-connected smartphones are sold each month. That means each year the equivalent of the entire UK population is getting connected, in that one country alone.
The way people are using their devices in India is similar to the way the younger generations do in the UK. Huge amounts of time is spent inside apps. The companies building these apps are now building their own content discovery and distribution platforms to rival the reach and scalability of the web. At the same time, native platforms are incorporating more of the core strengths of the web — most recently, the ability to link to content — directly into their platforms.
Watching how millions of people are getting online and almost bypassing the web is galling. A new way of thinking about how we build apps and content experiences for the web is needed. One that is progressive in allowing us to build for the web at large, but takes inspiration from the deeper engagement that can be found in native app platforms.
Web benefits
One way to think about the properties that embody the power of web is through an acronym: SLICE.
- Secure: The web is sandboxed from the device and from other sites, so it can’t leak data
- Linkable: The raw power of the web, sites, pages and paragraphs can all be directly connected to each other and thus shared easily
- Indexable: The openness of the web and the ability to easily parse the content inside each page means huge amounts of the world’s content can be understood and made available to search
- Composable: Embedding pages, components and functionality allows us to create and mash-up new experiences quickly
- Ephemeral: Everything lives and dies with the tab — when a user leaves a site, there are no remnants of it left on the user’s machine taking up resources
The web as a medium embodied by SLICE is amazingly rich and powerful, but the world is changing with mobile. As tension builds between the web and native apps, our understanding of the underlying properties of the web
needs to adapt.
Web drawbacks
There are at least four core criticisms of the web as a platform that I want to touch upon.
- The web is for documents: This was originally true. However, it quickly grew past this to live documents with JavaScript and dynamic content, generated by complex server logic. The web doesn’t have a ListViewController baked in, but neither do the host OSs on mobile — they are part of the framework shipped with the platform
- The web is slow: Not true; it’s just our experience of the web that’s slow. As an industry, this is our fault — we don’t treat performance as critical
- The web doesn’t work offline: True — unless we build it to work offline. But who would launch a web browser without an internet connection?
- The web can’t do X, Y and Z: The specification and standards process means we don’t always get access to the new hotness the second it arrives. However, this does mean we can learn from the mistakes of other platforms before we bake them into the web
These arguments imply there is a clear separation between the web on mobile and mobile native platforms, but it is much more complex. Mobile platforms, social platforms and app developers all want properties embodied by the web: content that is hosted inside their own experiences, with no need to install.
Apps and SLICE
It’s not a question of if, but when native app platforms embody all the principles of SLICE. ‘S’ is a core principle of mobile platforms, and ‘I’ has recently been partly solved, with both Apple and Google presenting solutions for indexing app content. ‘C’ has always been available with the libraries and toolkits provided by native frameworks. Most recently, linkability issues have been solved with deep app-linking on both iOS and Android.
That leaves ‘E’: Ephemerality. The ability to quickly load an experience or a piece of content, consume it and then leave it is the web’s biggest strength. It is what gives it its reach and ability to work on any platform.
That said, the web and browsers would benefit from being less ephemeral at times, and having the ability to act like they are installed and part of the native platform. New APIs such as Service Worker and push notifications are starting to get us there, but they require us to change how we build experiences.
10 years ago, Ajax fundamentally changed the way developers approached apps for the web, and more importantly the expectations of users. Service Worker will be the next step of change. Service Worker gives you access to the underlying systems of the browser: the networking stack so you can build robust, connectivity-tolerant sites; the notification system so you can keep users up to date with relevant information; and potentially much more in the future. But fundamentally, it changes what the web will deliver to users. We’ve started to think of this in terms of progressive web apps.
Progressive web apps are a range of new platform capabilities in the browser. They play to the strengths of the web — including instant access and universal availability — as well as including some of the utility of native app platforms
Progressive web apps
Progressive web apps are a way to think about building web apps combined with new platform capabilities in the browser. They play to the strengths the web has today (instant access and universal availability, link-powered, with the advantages of an SPA), as well as including some of the abilities of native app platforms.
Essentially, progressive web apps combine the best bits of the web (SLICE) and app-like qualities:
- Robust in the face of flaky networks
- Load instantly; can be launched from the home screen
- Responsive to touch, with smooth interactions
- Able to use device capabilities like push messages
This new approach requires us to employ progressive enhancement throughout our stack. We need to embrace server-side rendering: site structure, layout and content are rendered and merged on the server and streamed to the browser for it to display. We also need to incorporate single-page app architecture: a shell of the app is sent to the browser, which then takes over navigation with JavaScript and Service Worker.
Progressive web apps will ideally render on the server in the first request and then upgrade into client-side rendering with a caching layer provided by the Service Worker. The benefit with this model is that if a browser doesn’t support Service Worker your web app should still work well in the browser, but is dramatically enhanced when a Service Worker is available.
We have the tools and a framework to enable us to build modern progressive experiences, but we need to go out and actually build them today. That’s up to us as an industry to do.
Paul works on the Chrome developer relations team, and focuses on building the next generation of web apps
This article originally appeared in issue 277 of net magazine. For more on progressive web apps, check out net’s issue 282, on sale now.
