For a detailed video presentation of the concepts in this post, see our Functional Web tech talk.
If you want to know the future of apps and the web, don’t think about short-term trends.
- Don’t think about which new HTML5 APIs are coming.
- Don’t think about which devices have which market share.
- Don’t think about whether mobile websites or mobile apps are getting more eyeballs.
Just think about one thing: the URL.
The URL has been around since 1994, but it’s evolved a lot in 20 years. And the future of apps and the web has everything to do with the URL’s evolution.
URL stands for “Uniform Resource Locator”. A resource locator tells you where an HTML file lives within a web server’s directory tree. For example, a website called Shakespeare Online lets anyone read the full text of Shakespeare’s Hamlet by accessing the URL
shakespeare-online.com/plays/hamlet.html. That URL works because it locates a resource – a file called
hamlet.html which lives in a directory called
plays on the Shakespeare Online web server.
In the last decade, the web has grown to support new functions that aren’t powered by HTML resources – networking with friends, booking flights, gaming, watching videos, using maps, etc. These new functions aren’t powered by your grandfather’s HTML files. They don’t have “resources” to be “located” in the traditional sence.
For example, when you access
www.facebook.com/home.php, Facebook doesn’t send you a static HTML file called
home.php. Instead, Facebook dynamically pieces together your friends’ status updates and streams them to your browser in realtime.
When you access
www.youtube.com/watch?v=dMH0bHeiRNg&t=50s, it plays the video “Evolution of Dance” starting at 50s. The “t=50s” is converted to a command that tells YouTube’s video player to skip to timecode 0:50 in the video.
When you access
maps.google.com/maps?ll=21.28,-157.83, it shows a map centered around Waikiki beach, whose geocoordinates are
21.28°N, 157.83°W (the
ll in the URL stands for “latitude & longitude”).
Today, the URL isn’t just a resource locator. In fact, it’s rarely used for accessing files like
hamlet.html anymore. Instead, today the URL is a gateway to functions like “read my Facebook news feed”, “play ‘Evolution of Dance’ at timecode 0:50″ and “show a map centered around Waikiki beach”. Today, the URL is a function identifier.
The Functional Web
Today we have the web, and we have apps. They seem like two separate silos, each with separate functions. Why is that?
Apps are software products, which makes them technologically different from web servers. Apps don’t have HTML resources that old-fashioned URLs can locate. This technological difference is why apps haven’t traditionally been considered a part of the web.
The Functional Web offers a technology-independent view of URL-accessible functions. On the Functional Web, URLs can be accessed either by downloading a file from Shakespeare Online’s web server, or by issuing a seek command to YouTube’s video player, or by launching a native app into a particular state.
Apps fit naturally into the Functional Web. Consider the function “search Yelp for karaoke”. Yelp’s website already has a function-identifying URL for it:
Now consider Yelp’s iPhone app – one of Yelp’s many device-specific native app editions. It clearly gets you the same function the Yelp website does, namely “search Yelp for karaoke”.
This diagram visualizes how both editions of Yelp can access the same point on the Functional Web, by getting you the same “search Yelp for karaoke” function.
The only missing piece is to make the function URL-accessible to the Yelp app, the way it’s URL accessible to the Yelp website.
Apps like Yelp provide many of the same functions as their web counterparts, but don’t currently support the ability to access the URLs for those functions. It’s time for apps to fully join the Functional Web by making their URL-identified functions URL-accessible.
The Web’s Natural Evolution
Why did we ever separate apps from the web? How did we overlook the idea that URLs could be used to access functions of apps?
Our old-fashioned technology-centric view of URLs is to blame. We assumed that if apps weren’t like web servers – if apps didn’t have HTML resources to be located – then apps must not have functions worth identifying and accessing with URLs.
We didn’t notice that the transition to URLs as function identifiers was already happening. We ignored the fact that we already use URLs to access functions on social networking sites, video sites, mapping sites and other dynamic sites.
The URL is our key to understanding the convergent future of apps and the web – we just have to understand its evolution from resource locator to function identifier. Then we can understand the decades-long trend toward the new web that brings URL accessibility to website-supported functions, app-supported functions, and all other technology-supported functions – the Functional Web.