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.
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?
Ian [April 29th, 2015, 11:37]
Thanks Ian.
getUserMedia
is great to have, but itās basically unusable for client projects because itās Android only.Peter [April 29th, 2015, 12:14]
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.
Ian [April 29th, 2015, 13:15]
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.
Dan Appelquist [April 29th, 2015, 15:49]
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.
amul [April 29th, 2015, 22:26]
[…] Via broken-links […]
Il futuro del Web ĆØ un Web senza futuro? | Edit - Il Blog di HTML.it [April 30th, 2015, 09:03]
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.
AdriƔn [May 1st, 2015, 08:37]
[…] The Future of the Open Web by Peter “Blakey” Gasston. Peter writes “the single most important [new initiative] is the Service Worker API”. […]
Bruce Lawson’s personal site : Reading List [May 1st, 2015, 16:58]
[…] 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; […]
Tweet Parade (no.18-2015) - Best Articles of Last Week | gonzoblog [May 2nd, 2015, 14:05]
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.
Wayne H [May 6th, 2015, 16:55]
[…] 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 […]
Instant Articles - Nico BrĆ¼njes [May 13th, 2015, 08: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 […]
Hardware APIs coming to browsers - Broken Links [July 23rd, 2015, 11:28]