The headless web

Probably the weirdest thing about the way Paul Kinlan writes and talks about &quot;the web&quot; and &quot;native&quot; is that he&#x27;s really just talking about &quot;Chrome&quot; and &quot;Android.&quot;<p>For example, see that chart in his &quot;The table stakes&quot; section? It clearly states that while the web &quot;KINDA&quot; had offline mode in 2014, in 2015 he upgraded that answer to &quot;YES,&quot; by which he means that Service Workers became available on Chrome and Firefox.<p>But Service Workers aren&#x27;t available on any browser provided by Apple or Microsoft. <a href="http:&#x2F;&#x2F;caniuse.com&#x2F;#feat=serviceworkers" rel="nofollow">http:&#x2F;&#x2F;caniuse.com&#x2F;#feat=serviceworkers</a> says &lt; 60% of browser share supports SWs today, in 2016. Apple didn&#x27;t announce SWs in iOS 10, so earliest we can hope for is 2017, maybe 2018. MS will ship SWs for Edge later this year, but Edge is still a minority browser on Windows (because no one on Windows 7 can upgrade to it without upgrading to Windows 10).<p>Less than 70% of users will have what Kinlan thinks are 2015&#x27;s &quot;table stakes&quot; this year.<p>And in the subsequent table, look at &quot;Single click install and launch.&quot; In 2016, &quot;Native: YES.&quot; Here, he&#x27;s talking about Instant Apps for Android. But iOS doesn&#x27;t support that at all. Perhaps they never will!<p>And did you &quot;know&quot; that the web just got Auth <i>and</i> Payments in 2016? Of course you didn&#x27;t know that, because it&#x27;s not even remotely true. Maybe Apple will capture significant mobile-web payment share with the new iOS 10 Apple Pay API, but even Android Pay is struggling, and Chrome&#x27;s new autofill APIs are even less established.<p>The auth story is the most fictional of all. We&#x27;ve had the ability to login with Facebook or Google for years, but only in 2016 did Chrome ship their Nth attempt at getting you to authenticate using Chrome APIs. So &quot;now&quot; we have auth? Even though nobody uses those Chrome APIs, and everybody just logs in with password or Facebook?

I&#x27;m having trouble understanding the relationship between two pretty abstract ideas: this one, and the Richardson maturity model [0].<p>Are the two futures at odds? Kinlan seems to be imagining annotations embedded in Hypermedia, so that documents could be &quot;displayed&quot; by non-traditional &quot;browsers&quot; that didn&#x27;t actually render the document but rather extracted data from it and displayed it in some other interface to the user.<p>Richardson describes a system in which web APIs can be explorable by software, so that the software doesn&#x27;t need to be written to an API. In a sense, the API contains program-readable documentation about how to use it. This works as long as a set of &quot;nouns&quot; and &quot;verbs&quot; are understood commonly by the API and the client program.<p>I can&#x27;t wrap my head around how these ideas would fit together. Are they the &quot;read&quot; and &quot;write&quot; halves of a post-browser Web? Or are they contradictory futures?<p>[0]: <a href="http:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;richardsonMaturityModel.html" rel="nofollow">http:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;richardsonMaturityModel.htm...</a>

It&#x27;s also interesting to see that technology indeed moves in cycles. In the beginning, the web was intended as a data layer, where that data was interlinked documents; but once it became popular (and commercialized), we built more elaborate &#x27;documents&#x27; until they were graphically intensive for visuals&#x27; sake.<p>Then to gain interactivity we fitted an entire framework for manipulating that document&#x27;s structure through imperative code (DOM), drawing arbitrary pictures (canvas), making other requests (XHR), and now we&#x27;re at a point where the browser proxies nearly every feature of the OS platform for use of a website.<p>JS and WebAssembly aside, the VM inside the browser isn&#x27;t even the new VM... rather, the integration point is the entire browser and everything that&#x27;s inside of it, and this article predicts a future where we use an intelligent but headless browser to manipulate a page just to get some data out.

This is a natural convergence two trends:<p>[1] that HTTP APIs operated by to most webapps&#x2F;services do not have feature parity with their actual website, even if only in the sense that a third-party client has to implement a custom controller&#x2F;view logic whereas a website already provides that courtesy of the first-party;<p>[2] and that the Web Platform (previously known as &quot;those random javascript globals under &#x27;window&#x27;&quot;) has more and more &#x27;hooks&#x27; to functionality to what&#x27;s traditionally implemented by a modern desktop&#x2F;mobile OS.

Technically, no problem. But who pays for the content when someone else puts your content in their presentation?

I completely agree. We need to separate the data layer of the internet from the presentation layer. Most spam and poor user experience is due to the data owner controlling the presentation. I also believe we won&#x27;t reach true accessibility without such a decoupling.<p>This is what I&#x27;m building at Optik. A network focused on knowledge rather than display. The average person should be able to receive, manipulate, and publish data without understanding API integration. That will only work if we change the information providers.<p>The technology exists, just the mindset has to change -- so it&#x27;s great to see articles like this.

Another way of framing these ideas is that data is starting to look more and more like media, and the web is coalescing around shareable data (a.k.a., “Linked Data”).<p>His description could prove prophetic, but seems a bit microscopic even though he&#x27;s describing a sea change. I tend to think something more disruptive is coming.

Could someone write a tl;dr version for non english readers ? (article sound nice, but hard to grasp)

I think the effort to make a &quot;mobile-optimized&quot; website is quite low these days.<p>Contrary to this article the effort to make a &quot;mobile-web-app&quot; is quite big. There are multiple gotchas like &#x27;tap-delay&#x27;, cache, session-storage, distribution, you name it.<p>So far ( I still remember when iPhone OS introduced screen-bookmark-web-apps ) I think there is no business reason to go with a &#x27;web-app&#x27; when you can spend that time &#x2F; dev-money on a native app. Maybe cordova &#x2F; phonegap still sounds like an option, although I think temporarily, until you can afford making a native one for all platforms.

&gt; <i></i>If you take it one step further, many of the modern search engines run a browser behind the scenes to be able to themselves to execute JavaScript so that the content you host using you preferred framework of choice will still render and the data will then be indexable.<i></i><p>I had been wondering for years how Google is able to discover and index new pages without explicit indexing requests from webmasters. So it is the browser.

This is probably an oversimplification, but isn&#x27;t this kinda just ssh wrapped up in some kind of more user-friendly package?

Oh god no, the world do not need more http, html and javascript.