The headless web
paul.kinlan.me
paul.kinlan.me
For example, see that chart in his "The table stakes" section? It clearly states that while the web "KINDA" had offline mode in 2014, in 2015 he upgraded that answer to "YES," by which he means that Service Workers became available on Chrome and Firefox.
But Service Workers aren't available on any browser provided by Apple or Microsoft. http://caniuse.com/#feat=serviceworkers says < 60% of browser share supports SWs today, in 2016. Apple didn'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).
Less than 70% of users will have what Kinlan thinks are 2015's "table stakes" this year.
And in the subsequent table, look at "Single click install and launch." In 2016, "Native: YES." Here, he's talking about Instant Apps for Android. But iOS doesn't support that at all. Perhaps they never will!
And did you "know" that the web just got Auth and Payments in 2016? Of course you didn't know that, because it'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's new autofill APIs are even less established.
The auth story is the most fictional of all. We'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 "now" we have auth? Even though nobody uses those Chrome APIs, and everybody just logs in with password or Facebook?
Are we going to wait until the platform is completely uniform until we take advantage of any of these things? Some will, some won't. We are already seeing those that build progressively in terms of taking advantage of newer parts of the stack are doing well with those elements.
I would say that the brunt of my article still holds valid even if you disagree on the platform capabilities, we are catching up with native platforms but we need excel in where the web is best, and I think that is embedability of content (although that seems like a lost art) is one core part where we need to do a better job and ease of interaction (i.e, no install).
Are the two futures at odds? Kinlan seems to be imagining annotations embedded in Hypermedia, so that documents could be "displayed" by non-traditional "browsers" that didn't actually render the document but rather extracted data from it and displayed it in some other interface to the user.
Richardson describes a system in which web APIs can be explorable by software, so that the software doesn'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 "nouns" and "verbs" are understood commonly by the API and the client program.
I can't wrap my head around how these ideas would fit together. Are they the "read" and "write" halves of a post-browser Web? Or are they contradictory futures?
[0]: http://martinfowler.com/articles/richardsonMaturityModel.htm...
In REST, these 'link relations' are extremely important, because they represent well-specified ways of relating one resource to another. They are as critical to REST as mediatypes (MIME types) are. In the graph theory sense, link relations are the label on an edge, URIs are the nodes, and mediatypes are formats that can be used as concrete representations of the nodes. The IANA maintains a Link Relations registry [1].
But since the 'normal web' is used by humans, we don't need link relations to traverse a website; we can instead use context clues, familiarity, or other techniques to achieve what we want on a website; the entire discipline dedicated to coaxing humans into interacting with websites is called 'UI/UX'.
Meanwhile, Kinlan envisions... well, to be frank I'm not entirely sure what Kinlan envisions because after mentioning 'headless web' he writes a lot about service workers, notification hooks, then points to ways we already use the web in ways that aren't out of our own volition, like in WebViews and IFrames (which he writes about in detail here [2]). I think his point is largely that every app maker wants to control the viewport around which content is surfaced, so they can add their own control and bring their own community, auth, ads [3], etc, and we're finally at a point to where the web platform has matured enough to make these websites or 'web includes' access capabilities offered by the device or the device's platform runtime, such as notifications, sensor data, and the like.
In a sense, they're not contradictory at all. The Richardson model clearly strives towards the semantic web, while Kinlan's writings predict that the semantic web has essentially failed, leaving people to write custom scripts and parsers and crawlers and bots to mash web content, some of it 'Web Platform-enabled', into other places.
[1] http://www.iana.org/assignments/link-relations/link-relation...
I wish I had actually said that in the post. It's quite succinct.
Then to gain interactivity we fitted an entire framework for manipulating that document's structure through imperative code (DOM), drawing arbitrary pictures (canvas), making other requests (XHR), and now we're at a point where the browser proxies nearly every feature of the OS platform for use of a website.
JS and WebAssembly aside, the VM inside the browser isn't even the new VM... rather, the integration point is the entire browser and everything that'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.
[1] that HTTP APIs operated by to most webapps/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/view logic whereas a website already provides that courtesy of the first-party;
[2] and that the Web Platform (previously known as "those random javascript globals under 'window'") has more and more 'hooks' to functionality to what's traditionally implemented by a modern desktop/mobile OS.
Universal content syndication, broadband tax, universal income. Something.
This is what I'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.
The technology exists, just the mindset has to change -- so it's great to see articles like this.
His description could prove prophetic, but seems a bit microscopic even though he's describing a sea change. I tend to think something more disruptive is coming.
<q>
What if everything was powered by “The Web”, but you never saw a browser?
This is a big question. As an industry would we be happy with the user hardly ever seeing a web browser anymore? Or is that the one thing that is sacrosanct?
I think my original classifications: Notifications, Physical, Embedded and Integrated, were not a million miles off where I think the platform is headed.
</q>
It's a long argument / technical exploration of what a web-served world not mediated by browsers, but through notifications, native apps, embedded systems, etc., would look like. More Web-as-data-back-end than Web-as-content-delivery, in one view that occurs to me.
That said: the article wanders, doesn't start with or come to a point, and is difficult to follow. It's more a thinking-out-loud exploration than clear draft IMO.
I would say that is true, there are a lot of different threads that I am trying to pull together at the moment.
Quick off-the-cuff bits (like this comment), or things I've been thinking about for a long time, can just spill out. It's the ideas I'm still putting together which I've got to struggle with most, often with extensive notes, outlines, and graphs to organise them.
It's a joy for me to see other writers who've clearly distilled their argument. Rare, too. It takes talent, clarity of thought, and organisation.
The school of writing advice that this is just words and you've got to keep them flowing strikes me as quite flawed.
Contrary to this article the effort to make a "mobile-web-app" is quite big. There are multiple gotchas like 'tap-delay', cache, session-storage, distribution, you name it.
So far ( I still remember when iPhone OS introduced screen-bookmark-web-apps ) I think there is no business reason to go with a 'web-app' when you can spend that time / dev-money on a native app. Maybe cordova / phonegap still sounds like an option, although I think temporarily, until you can afford making a native one for all platforms.
Currently the only way to install one would be to bookmark it from your browser, which is counter-intuitive to the users.
There are a couple of ways to mitigate this problem [1] , but we are not talking about pure web-application anymore.
1 : http://stackoverflow.com/questions/1157576/is-it-possible-to...
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.