The Future of the Open Web

Warning This article was written over six months ago, and may contain outdated information.

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 App Links to make the web just a conductor between mobile apps; 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.

A competitive web also needs gesture events, finer control over scrolling, Bluetooth, NFC, paymentsā€¦ and everything else that native apps get. But Service Workers are the most immediate and pressing requirement.

Service Workers and complementary features 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.

12 comments on
“The Future of the Open Web”

  1. All good points, although there’s one tiny one that I question, the web does give you access to a device’s camera, via getUserMedia (the specification for which is improving all the time). Or are you referring to more specific access?

  2. Thanks Ian. getUserMedia is great to have, but itā€™s basically unusable for client projects because itā€™s Android only.

  3. Android only? It’s a web based API, but yes, now I see that iOS hasn’t bothered to support it. Apple are falling behind here, sadly.

  4. Yes I agree with your comments. Ten years ago, opined that the future of mobile would be more sophisticated mobile web and mobile apps. Because of things like service worker, push API, save-to-homescreen with W3C manifest file and other new powerful features coming to the web, I am more bullish than ever on the important role the web will continue to play. In fact, I see the web clawing back some of the mindshare that mobile apps have won. What I hope happens is that the web becomes more useful as a conduit for mobile services and the discovery of applications where appropriate.

  5. so crazy I was thinking about this earlier this morning.

    Jobs gated the internet – Android copied – Adobe’s flash got killed.

    But atleast javascript succeeded.

    until swift kills that.

  6. […] Via broken-links […]

  7. Great article, I think that the balance of who could ‘win’ (if we needed a winner) is mainly based on a type of projects who really needs access to specific native features, but we aren’t counting that in the reverse way: how many native apps could be solved with a simple; well thinked and executed; not necessarily downloadable trought a store; not overblowed by unnecesary native access to justify the budget (or to fit with the apple store guidelines), webapp approach. No speaking of the reduced cost to produce and to mantain it in an universal way (no more iPhone/Android/Windows independently teams).

    Maybe my point is quite nostalgic, but like in traditional graphic design, I think that trends don’t let us see the real needs on some brief projects.

    Of course that FB, instagram, etc needs a native approach, but since a high percentage of native apps don’t need that kind of integrations but they need an internet connection to accomplish their tasks, I think we should push the web to be faster, with better offline modes, better integrated with the OS instead or consider a not open web future.

  8. […] The Future of the Open Web by Peter “Blakey” Gasston. Peter writes “the single most important [new initiative] is the Service Worker API”. […]

  9. […] The Future of the Open Web – 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 an afterthought; […]

  10. Great article. Thanks for all the thought you put into this. I have been thinking the same as you for the past two years. As a Enterprise Web Application Engineer for many years, and now on my own, I have wished that from a browser mobile standpoint to make non native apps easier to emplement for customers. The ability to easily drop a shortcut on a mobile device that would then (in looks anyway) seem like a native app but use the browser. Many people have a disconnect with this meaning being able to set up on there phone.

    The biggest piece of the puzzle I see that would be beneficial is that fact that it wouldn’t matter what OS you are on for development…. You could still be able to provide applications to a broader audience and from a development standpoint would be a win. Like with anything though. Security, may become a possible issue.

    Thanks again for the article and the thought put into this.

  11. […] nur der Geburtshelfer fĆ¼rā€¦ Gottchen, da wird einem ja schlecht. TatsƤchlich ist es ja ziemlich schlecht bestellt um das open web, das kann man nicht von der Hand weisen. Und was wir in den letzten Wochen sehen, ist sowas wie […]

  12. […] the web are features that provide parity with native mobile apps. Iā€™ve written previously about the importance of service workers in providing this parity, but there are also a few new features breaking through that Iā€™m equally […]