Trying to imagine a web that focuses more on the open data layer and less on the presentation layer
At the heart of the competition between native apps and the web is a question: When can you tolerate the wait?
With native apps, you need to wait five to twenty seconds for the download and install, but then the app is always lightning fast and ultra-responsive because the presentation code is already on your device.
With a website, you have to wait somewhere between two and twenty seconds for the server roundtrip and local rendering every time you click on a new page. So whereas with native apps you have a very painful initial download experience and the rest of the experience is snappy, the web is more like a death by a thousand downloads.
This story is playing itself out all over again with Facebook, Snapchat, Twitter and all the social apps: Why even wait that one to three seconds it takes to find and then launch a different app when you can consume the same content in an app that’s already launched? The notion of waiting for even a moment has nearly been made obsolete by Facebook’s Instant Articles: Like a good assistant, Facebook has fetched everything you need before you even asked for it.
Sure, web development practices could adapt to solve for speed first. Quartz, for example, pre-loads the next story as you’re reading the current one. [Service Worker scripts], which are now supported in Chrome and Firefox, might also aid in making the web more responsive without the need for a refresh.
However, it’ll take a long time for that practice to wash over all the legacy ways we build websites, and web publishers might not even be able to improve their practices at the same rate that the likes of Facebook do with their native apps. Facebook and the other big tech firms employ the best engineers, leverage the fastest CDN’s, and figure out all the best solutions for rendering stuff really quickly.
The question, then, is whether the web in its current form can be saved. I think the answer to that question depends on what you mean by “web”. If by “web” you mean an entire app that includes a presentation layer, I share many people’s pessimism. But if by “web” you mean an open network of data that can be indexed and scraped and sliced and diced like no other data/content network can, then there are reasons for optimism.
We're arriving at a “Let us do what we do best and you do what you do best” stage of the internet. Some examples:
These are all the conditions which make it so easy to spin up a business on the Internet these days.
What if we applied that logic to the web? We could drop the stuff that the web is not good at — the presentation layer, which is dragging along all the frameworks and cruft that slow it down — and allow it do what it does best: Point to data and content sets that can be indexed, scraped, sliced and diced like no other network can.
Imagine a world where retailers publish their inventory in the head of their website for tastemakers to promote, for an affiliate fee, all over Tumblr and Instagram and Pinterest. Or where news organizations more readily give away today’s news in exchange for a rev share on ads on other networks. Or where small businesses have a single place to publish their details for the Yelps and future Yelps of the world to harvest. A marketplace for everything, hosted on the web.
I know this is kinda similar to what the web does now, given that we all publish stuff for Google to index on our behalf. But when it comes to publishing on the web, the things that retailers and publishes and content creators and small businesses spend their time and attention on matters. Every hour that a small business spends optimizing its presence on Yelp, or a retail business spends building its online store, or a news business spends strengthening the present by experimenting with banner ads, is one less hour spent doing what they do best. And one hour less getting us to a web that's the best it can be.
Thanks to Julien Genestoux for reviewing a draft of this post