index.md 8.2KB
title: The Future of the Open Web
url: http://www.broken-links.com/2015/04/28/the-future-of-the-open-web/
hash_url: 7eee660422
I’ve spent a lot of time in my career writing and talking about future web features, from CSS3 to Web Components. But I’ve recently come to realise that, while I still think these features are important, I’ve been missing out on the bigger picture: the survival of the open web. That sounds hyperbolic, I know, but so many articles I’ve read, conversations I’ve had, and behaviours I’ve observed, have led me to the conclusion that the open web, in the form we know it now, is under threat.
The signs are everywhere. A few examples: some of the biggest tech acquisitions of recent years (Instagram, WhatsApp, SnapChat) are native only or with web as a secondary consideration; Facebook made React Native because the web isn’t sufficiently performant; and major Indian retailer Flipkart are closing their Web portal and going native only.
Cennydd Bowles recently wrote Open and Shut, in which he baldly states the situation:
Let’s be clear: the open web is not winning. Today’s most significant tech products and companies are not web-based: they are building on proprietary mobile platforms (I include Android here). The ideas, the transformation, the growth are all happening on the closed side. The talent is increasingly moving there, and the money has long since chosen its allegiances. The open web isn’t outright losing yet, but its goalkeeper has been sent off and there’s a free kick just outside the box.
The web is perceived, for right or wrong, as slow, bloated, and expensive. This is a major problem in developing economies with limited networks, who may be skipping the web entirely:
Many people in India, China, and other parts of the world, where bandwidth is low and slow, and where mobile phones are their one and only computer, have no room for… sentimentality. They may never have experienced the same heyday of the web, so they feel no analogous nostalgia for it as a medium.
The received wisdom is that “open wins”. But, as Cennydd suggests [1], maybe this isn’t always true:
Maybe the Internet had to happen, but it was a one-time disruptive event. Maybe there’s no inevitable pendulum.
While the last few years has seen a welcome focus on performance by developers, I don’t feel that’s enough. For the web to thrive and be successful, it needs to better compete with native apps. That’s not to say that I think native apps are superior, or that everything on the web should be app-like; but native apps have set expectations of performance, operation and interaction for mobile users — and in most cases those expectations aren’t, or can’t be, met on the web.
In his recent article, The Future of Communications Apps is on the Web, Paul Kinlan identified four guiding principles of what native apps offer: presence; persistence; integration; and media access. In terms of features, these very crudely map to: being installable; having at least minimal offline support; sending and receiving notifications; and giving access to the contact list, photo gallery, and camera [2]. So if we accept that this is what’s required for mobile web apps to offer a comparable experience to native apps, this is what mobile browsers should be pushing towards.
Google and Mozilla are the two browser vendors with the biggest interest in an open web, although each has different motivation: Google need the web to be open and indexable to achieve their business goals, and an open web is Mozilla’s mission. Because of this interest, each vendor has begun important initiatives: Google’s Project Fizz aims to bring native features to Chrome, and Mozilla’s WebAPI defines many new media and device APIs for FirefoxOS.
Of all the new features being implemented in these initiatives, I’m becoming convinced that the single most important is the Service Worker API. This allows web apps to register background services, an operation that’s critical to empowering the web to take on native apps. Of Paul Kinlan’s guiding principles (above), Service Workers directly offer persistence (through caching) and integration (the Push API), and indirectly offer presence with the Web Manifest and new App Install experience in the latest Chrome|Android.
Service Workers, and related services, are rolling out in the latest releases of Chrome and coming very soon in Firefox (currently in Nightlies). Of the other major browsers [3], Project Spartan (formerly Internet Explorer) have them listed as ‘under consideration’ [4] and Safari (more accurately, WebKit) have no indication on their status page. Apple and Microsoft currently treat their mobile browsers as discrete apps rather than providing deep integration with the OS, so it will be interesting to see their decisions.
I still believe in the promise of the open web, but we can’t hold on to it dogmatically. The web must directly compete with native apps if it is to remain ubiquitous and successful. While new features like Web Components are important for the long-term vitality of the web, they’re not the critical technologies right now. And I feel that while I’ve been out preaching them, I’ve perhaps been missing the wood for the trees.
Afterword
It took me almost two months to write this article; it started off as a look at the future of browsers, and developed into this piece about the future of the web. I’ve tended to keep my previous blog posts quite factual, so a long opinion piece like this is a bit of a departure and I look forward to feedback and criticism. I especially welcome any input on the plans of Safari/WebKit for implementing Service Workers or other efforts at pushing for an open web.
Footnotes
[1] Cennydd’s conclusion (paraphrased) is that he doesn’t mind if open loses, as long as we all win. Jeremy Keith disagrees.
[2] I work in a creative technology company, and we receive many client briefs every year that we simply can’t build on the web, for lack of access to device functions such as live camera input (on iOS), Bluetooth, or background geolocation.
[3] I’m not including Opera here as their Desktop and Mobile browsers are based on Chromium and largely follow Chrome, while Opera Mini is a proxy browser and unable to offer Service Worker support with its current architecture. (Thanks to Bruce for the information.)
[4] The Project Spartan team have an open voting system for new features so you can upvote Service Workers.