
The headless web - kinlan
https://paul.kinlan.me/the-headless-web/
======
dfabulich
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](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?

~~~
kinlan
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).

------
jake-low
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?

[0]:
[http://martinfowler.com/articles/richardsonMaturityModel.htm...](http://martinfowler.com/articles/richardsonMaturityModel.html)

~~~
niftich
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.

[1] [http://www.iana.org/assignments/link-relations/link-
relation...](http://www.iana.org/assignments/link-relations/link-
relations.xhtml)

[2] [https://paul.kinlan.me/slice-the-web](https://paul.kinlan.me/slice-the-
web)

[3] [https://paul.kinlan.me/rise-of-the-meta-
platforms/](https://paul.kinlan.me/rise-of-the-meta-platforms/)

~~~
kinlan
>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.

------
niftich
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.

------
niftich
This is a natural convergence two trends:

[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.

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

~~~
dredmorbius
More reason to treat information as a public good and decouple access from
payment.

Universal content syndication, broadband tax, universal income. _Something._

------
doublerebel
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.

------
arxpoetica
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.

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

~~~
dredmorbius
From about the middle of the article:

<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.

~~~
kinlan
> 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.

~~~
dredmorbius
And that's not necessarily a bad exercise.

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.

------
drinchev
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.

~~~
kinlan
Just one quick one, you mention distribution is a problem. Could you expand on
that a little for me?

~~~
drinchev
It's about the use of the AppStore / Google Play to distribute your web-
applications.

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...](http://stackoverflow.com/questions/1157576/is-it-possible-to-
distribute-an-iphone-web-application-through-the-app-store)

------
paradite
> __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.

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

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

