Probably the weirdest thing about the way Paul Kinlan writes and talks about "the web" and "native" is that he's really just talking about "Chrome" and "Android."
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?
I take your point and to some extent I am certainly hedging on the API fronts, but at this point we know it is technically a solved problem with rough consensus on the path for all browsers modulo deployment. The platform for a broad set of users has the capabilities and that is a good thing and that is something everyone can build to. I am also hedging that Apple will move towards a friction-less install model; personally I am not convinced that Instant Apps for Android is the right thing but I am more concerned that the intent is there.
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).
I'm having trouble understanding the relationship between two pretty abstract ideas: this one, and the Richardson maturity model [0].
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?
The Richardson 'REST API maturity model' describes how people commonly exchange HTTP payloads, how those systems can be augmented to get closer and closer to the ideas behind REST. Most people are perfectly happy with staying at levels 0 through 2, because HATEOAS is hard in the sense that you actually have to think about stuff like link relations, hypermedia mediatypes, and the semantic web. This is something most people on the 'normal web' don't even do properly, even though the 'normal web' is quite obviously hypermedia, and quite obviously an embodiment of REST. But despite its lack of deployment, Level 3 describes an API that has truly and unambiguously earned the right to call itself a 'REST API'.
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.
>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.
I wish I had actually said that in the post. It's quite succinct.
It'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 'documents' until they were graphically intensive for visuals' sake.
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.
"Your" content can't rationally have an owner, because it can't be property: It's not scarce. Copyright is an irrational, barbaric concept that relies on the violence of the government.
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't reach true accessibility without such a decoupling.
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.
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”).
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.
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.
> 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.
I think the effort to make a "mobile-optimized" website is quite low these days.
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.
> 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 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.
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?