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 writ­ing and talk­ing about future web fea­tures, from CSS3 to Web Com­po­nents. But I’ve recent­ly come to realise that, while I still think these fea­tures are impor­tant, I’ve been miss­ing out on the big­ger pic­ture: the sur­vival of the open web. That sounds hyper­bol­ic, I know, but so many arti­cles I’ve read, con­ver­sa­tions I’ve had, and behav­iours I’ve observed, have led me to the con­clu­sion that the open web, in the form we know it now, is under threat.

The signs are every­where. A few exam­ples: some of the biggest tech acqui­si­tions of recent years (Insta­gram, What­sApp, SnapChat) are native only or with web as a sec­ondary con­sid­er­a­tion; Face­book made React Native because the web isn’t suf­fi­cient­ly per­for­mant, and App Links to make the web just a con­duc­tor between mobile apps; and major Indi­an retail­er Flip­kart are clos­ing their Web por­tal and going native only.

Cen­ny­dd Bowles recent­ly wrote Open and Shut, in which he bald­ly states the situation:

Let’s be clear: the open web is not win­ning. Today’s most sig­nif­i­cant tech prod­ucts and com­pa­nies are not web-based: they are build­ing on pro­pri­etary mobile plat­forms (I include Android here). The ideas, the trans­for­ma­tion, the growth are all hap­pen­ing on the closed side. The tal­ent is increas­ing­ly mov­ing there, and the mon­ey has long since cho­sen its alle­giances. The open web isn’t out­right los­ing yet, but its goal­keep­er has been sent off and there’s a free kick just out­side the box.

The web is per­ceived, for right or wrong, as slow, bloat­ed, and expen­sive. This is a major prob­lem in devel­op­ing economies with lim­it­ed net­works, who may be skip­ping the web entirely:

Many peo­ple in India, Chi­na, and oth­er parts of the world, where band­width is low and slow, and where mobile phones are their one and only com­put­er, have no room for… sen­ti­men­tal­i­ty. They may nev­er have expe­ri­enced the same hey­day of the web, so they feel no anal­o­gous nos­tal­gia for it as a medium.

The received wis­dom is that “open wins”. But, as Cen­ny­dd sug­gests [1], maybe this isn’t always true:

Maybe the Inter­net had to hap­pen, but it was a one-time dis­rup­tive event. Maybe there’s no inevitable pendulum.

While the last few years has seen a wel­come focus on per­for­mance by devel­op­ers, I don’t feel that’s enough. For the web to thrive and be suc­cess­ful, it needs to bet­ter com­pete with native apps. That’s not to say that I think native apps are supe­ri­or, or that every­thing on the web should be app-like; but native apps have set expec­ta­tions of per­for­mance, oper­a­tion and inter­ac­tion for mobile users — and in most cas­es those expec­ta­tions aren’t, or can’t be, met on the web.

In his recent arti­cle, The Future of Com­mu­ni­ca­tions Apps is on the Web, Paul Kin­lan iden­ti­fied four guid­ing prin­ci­ples of what native apps offer: pres­ence; per­sis­tence; inte­gra­tion; and media access. In terms of fea­tures, these very crude­ly map to: being instal­lable; hav­ing at least min­i­mal offline sup­port; send­ing and receiv­ing noti­fi­ca­tions; and giv­ing access to the con­tact list, pho­to gallery, and cam­era [2]. So if we accept that this is what’s required for mobile web apps to offer a com­pa­ra­ble expe­ri­ence to native apps, this is what mobile browsers should be push­ing towards.

Google and Mozil­la are the two brows­er ven­dors with the biggest inter­est in an open web, although each has dif­fer­ent moti­va­tion: Google need the web to be open and index­able to achieve their busi­ness goals, and an open web is Mozilla’s mis­sion. Because of this inter­est, each ven­dor has begun impor­tant ini­tia­tives: Google’s Project Fizz aims to bring native fea­tures to Chrome, and Mozilla’s WebAPI defines many new media and device APIs for FirefoxOS.

Of all the new fea­tures being imple­ment­ed in these ini­tia­tives, I’m becom­ing con­vinced that the sin­gle most impor­tant is the Ser­vice Work­er API. This allows web apps to reg­is­ter back­ground ser­vices, an oper­a­tion that’s crit­i­cal to empow­er­ing the web to take on native apps. Of Paul Kinlan’s guid­ing prin­ci­ples (above), Ser­vice Work­ers direct­ly offer per­sis­tence (through caching) and inte­gra­tion (the Push API), and indi­rect­ly offer pres­ence with the Web Man­i­fest and new App Install expe­ri­ence in the lat­est Chrome|Android.

A com­pet­i­tive web also needs ges­ture events, fin­er con­trol over scrolling, Blue­tooth, NFC, pay­ments… and every­thing else that native apps get. But Ser­vice Work­ers are the most imme­di­ate and press­ing requirement.

Ser­vice Work­ers and com­ple­men­tary fea­tures are rolling out in the lat­est releas­es of Chrome and com­ing very soon in Fire­fox (cur­rent­ly in Nightlies). Of the oth­er major browsers [3], Project Spar­tan (for­mer­ly Inter­net Explor­er) have them list­ed as ‘under con­sid­er­a­tion[4] and Safari (more accu­rate­ly, WebKit) have no indi­ca­tion on their sta­tus page. Apple and Microsoft cur­rent­ly treat their mobile browsers as dis­crete apps rather than pro­vid­ing deep inte­gra­tion with the OS, so it will be inter­est­ing to see their decisions.

I still believe in the promise of the open web, but we can’t hold on to it dog­mat­i­cal­ly. The web must direct­ly com­pete with native apps if it is to remain ubiq­ui­tous and suc­cess­ful. While new fea­tures like Web Com­po­nents are impor­tant for the long-term vital­i­ty of the web, they’re not the crit­i­cal tech­nolo­gies right now. And I feel that while I’ve been out preach­ing them, I’ve per­haps been miss­ing the wood for the trees.

Afterword

It took me almost two months to write this arti­cle; it start­ed off as a look at the future of browsers, and devel­oped into this piece about the future of the web. I’ve tend­ed to keep my pre­vi­ous blog posts quite fac­tu­al, so a long opin­ion piece like this is a bit of a depar­ture and I look for­ward to feed­back and crit­i­cism. I espe­cial­ly wel­come any input on the plans of Safari/WebKit for imple­ment­ing Ser­vice Work­ers or oth­er efforts at push­ing for an open web.

Footnotes

[1] Cennydd’s con­clu­sion (para­phrased) is that he doesn’t mind if open los­es, as long as we all win. Jere­my Kei­th dis­agrees.

[2] I work in a cre­ative tech­nol­o­gy com­pa­ny, and we receive many client briefs every year that we sim­ply can’t build on the web, for lack of access to device func­tions such as live cam­era input (on iOS), Blue­tooth, or back­ground geolocation.

[3] I’m not includ­ing Opera here as their Desk­top and Mobile browsers are based on Chromi­um and large­ly fol­low Chrome, while Opera Mini is a proxy brows­er and unable to offer Ser­vice Work­er sup­port with its cur­rent archi­tec­ture. (Thanks to Bruce for the information.)

[4] The Project Spar­tan team have an open vot­ing sys­tem for new fea­tures so you can upvote Ser­vice Work­ers.

12 comments on
“The Future of the Open Web”

  1. All good points, although there’s one tiny one that I ques­tion, the web does give you access to a device’s cam­era, via getUser­Me­dia (the spec­i­fi­ca­tion for which is improv­ing all the time). Or are you refer­ring to more spe­cif­ic access?

  2. Thanks Ian. getUserMedia is great to have, but it’s basi­cal­ly unus­able for client projects because it’s Android only.

  3. Android only? It’s a web based API, but yes, now I see that iOS has­n’t both­ered to sup­port it. Apple are falling behind here, sadly.

  4. Yes I agree with your com­ments. Ten years ago, opined that the future of mobile would be more sophis­ti­cat­ed mobile web and mobile apps. Because of things like ser­vice work­er, push API, save-to-home­screen with W3C man­i­fest file and oth­er new pow­er­ful fea­tures com­ing to the web, I am more bull­ish than ever on the impor­tant role the web will con­tin­ue to play. In fact, I see the web claw­ing back some of the mind­share that mobile apps have won. What I hope hap­pens is that the web becomes more use­ful as a con­duit for mobile ser­vices and the dis­cov­ery of appli­ca­tions where appropriate.

  5. so crazy I was think­ing about this ear­li­er this morning.

    Jobs gat­ed the inter­net — Android copied — Adobe’s flash got killed.

    But atleast javascript succeeded.

    until swift kills that.

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

  7. Great arti­cle, I think that the bal­ance of who could ‘win’ (if we need­ed a win­ner) is main­ly based on a type of projects who real­ly needs access to spe­cif­ic native fea­tures, but we aren’t count­ing that in the reverse way: how many native apps could be solved with a sim­ple; well thinked and exe­cut­ed; not nec­es­sar­i­ly down­load­able trought a store; not overblowed by unnece­sary native access to jus­ti­fy the bud­get (or to fit with the apple store guide­lines), webapp approach. No speak­ing of the reduced cost to pro­duce and to man­tain it in an uni­ver­sal way (no more iPhone/Android/Windows inde­pen­dent­ly teams).

    Maybe my point is quite nos­tal­gic, but like in tra­di­tion­al graph­ic design, I think that trends don’t let us see the real needs on some brief projects.

    Of course that FB, insta­gram, etc needs a native approach, but since a high per­cent­age of native apps don’t need that kind of inte­gra­tions but they need an inter­net con­nec­tion to accom­plish their tasks, I think we should push the web to be faster, with bet­ter offline modes, bet­ter inte­grat­ed with the OS instead or con­sid­er a not open web future.

  8. […] The Future of the Open Web by Peter “Blakey” Gasston. Peter writes “the sin­gle most impor­tant [new ini­tia­tive] is the Ser­vice Work­er API”. […]

  9. […] The Future of the Open Web – The open web, in the form we know it now, is under threat. The signs are every­where. A few exam­ples: some of the biggest tech acqui­si­tions of recent years (Insta­gram, What­sApp, SnapChat) are native only or with web as an afterthought; […]

  10. Great arti­cle. Thanks for all the thought you put into this. I have been think­ing the same as you for the past two years. As a Enter­prise Web Appli­ca­tion Engi­neer for many years, and now on my own, I have wished that from a brows­er mobile stand­point to make non native apps eas­i­er to emple­ment for cus­tomers. The abil­i­ty to eas­i­ly drop a short­cut on a mobile device that would then (in looks any­way) seem like a native app but use the brows­er. Many peo­ple have a dis­con­nect with this mean­ing being able to set up on there phone.

    The biggest piece of the puz­zle I see that would be ben­e­fi­cial is that fact that it would­n’t mat­ter what OS you are on for devel­op­ment.… You could still be able to pro­vide appli­ca­tions to a broad­er audi­ence and from a devel­op­ment stand­point would be a win. Like with any­thing though. Secu­ri­ty, may become a pos­si­ble issue.

    Thanks again for the arti­cle and the thought put into this.

  11. […] nur der Geburtshelfer für… Gottchen, da wird einem ja schlecht. Tat­säch­lich ist es ja ziem­lich schlecht bestellt um das open web, das kann man nicht von der Hand weisen. Und was wir in den let­zten Wochen sehen, ist sowas wie […]

  12. […] the web are fea­tures that pro­vide par­i­ty with native mobile apps. I’ve writ­ten pre­vi­ous­ly about the impor­tance of ser­vice work­ers in pro­vid­ing this par­i­ty, but there are also a few new fea­tures break­ing through that I’m equally […]