It used to all make sense.
The web was once nothing but documents.
Just like you'd want some type of file browser UI to dig through files on your operating system, obviously, you need some type of document browser to view all these web-addressable "documents".
But over time, those "documents" have become a lot more. A. lot. more.
But I can now use one of these "documents" to have a 4 person video/audio conference on Talky with people anywhere in the world, play incredible full-screen first-person shooters at 60fps, write code in a full-fledged editor, or {{ the reader may insert any number of amazing web apps here }} using nothing but this "document viewer".
Does calling them "documents" seem ridiculous to anyone else? Of course it does. Calling them "sites" is pretty silly too, actually because a "site" implies a document with links and a URL.
I know the "app" vs. "site" debate is tired and worn.
Save for public, content-heavy sites, all of the apps that I'm asked to write by clients these days at &yet are fully client-side rendered.
The browser is not an HTML renderer for me, it's the world's most ubiquitous, yet capable, runtime. With the amazing capabilities of the modern web platform, it's to the point where referring to a browser as a document viewer is a insult to the engineers who built it.
There is a fundamental difference when you treat the browser as a runtime instead of a document renderer.
I typically send it nothing but a doctype, a script tag, and a stylesheet with permanent cache headers. HTML just happens to be the way I tell the browser to download my app. I deal with the initial latency issues by all-but-ensuring visitors hit the app with a primed cache. This is pretty easy for apps that are opened frequently or are behind a static login page in which you prefetch the app resources. With proper cache headers the browser won't even do the 304 not-modified dance. It will simply start executing code.
This makes some people cringe, and many web purists (luddites?! #burn) would argue that everything should gracefully degrade and that there isn't, or at least there shouldn't be, any distinction between a JavaScript app and site. When I went to EdgeConf in NYC the "progressive enhancement" panel said a lot of things like "your app should still be usable without JS enabled". Often "javascript is disabled" is really the time when the browser is downloading your javascript. To this I say:
WELL, THEN SHOW ME A TALKY.IO CLONE THAT GRACEFULLY DEGRADES!
It simply cannot be done. Like it or not, the web has moved on from that myopic view of it. The blanket graceful degradation view of the web no longer makes sense when you can now build apps whose core use case is fully dependent on a robust JavaScript runtime.
I had a great time at Chrome Dev Summit, but again, the core message of the "Instant Mobile Apps" talk was: "render your html on the server to avoid having your render blocking code require downloading your JS before it can start executing."
For simple content-driven sites, I agree. Completely. The demo in that particular talk was the Chrome developer documentation. But it's a ridiculously easy choice to render documentation server side. (In fact the notion that there was ever a client-side rendered version to begin with was surprising to me.)
If your view of the web lacks a distinction between clientside apps and sites/documents, I'd go as far as to say that you're now part of the problem.
Why?
Because that view enables corporate IT departments to argue for running old browsers without getting laughed out of the building.
Because that view keeps some decision makers from adopting 100% JavaScript apps and instead spending money on native apps with web connectivity.
Because that view wastes precious developer time inventing and promoting hacks and workarounds for shitty browsers when they could be building next-generation apps.
Because that view enables you to argue that your proficiency of browser CSS hacks for IE7 is still relevant.
Because that view will always keep the web locked into the browser.
What about offline?
I'm writing this on a plane without wifi and of course, using a native app to do so. There are two primary reasons for this:
- The offline web is still crap. See offlinefirst.org and this hood.ie post for more.
- All my favorite web-based tools are still stuck in the browser.
The majority of users will never ever open a browser without an Internet connection, type in a URL and expect ANYTHING to happen.
Don't get me wrong, I'm very supportive of the offline first efforts and they are crucial for justifying that
We have a very different view of apps that exist outside of the browser. In fact, the expectation is often reversed: "Oh right, I do need a connection for this to work".
Chrome OS is one approach, but I think its 100% cloud-based approach is more hardcore than the world is ready to adopt and certainly is never going to fly with the indie data crowd or the otherwise Google-averse.
So, have I ranted enough yet?
According to Jake Archibald from Google, ServiceWorkers will land in Canary sometime early 2014. This work is going to fundamentally change what the web can do.
If you're unfamiliar with ServiceWorkers (previously called Navigation Controllers), they let you write your own cache control layer in javascript for your web application. ServiceWorkers promise to serve the purpose that appcache was intended for: truly offline web apps.
At a high level, they now let javascript developers building clientside apps to treat the existence of a network connection as an enhancement rather than an expectation.
You may think, "Oh, well, the reason we use the web is because access to the network provides our core value as an app."
While I'd tend to agree that most of the useful apps fundamentally require data from the internet to be truly useful, you're missing the point.
Even if the value of your app depends entirely on a network connection, you can now intercept requests and choose to answer them from caches that you control, while in parallel attempting to fetch newer versions of those resources from the network.
If you think about it, that capability is no different than something like Facebook for iOS or Android.
That Facebook app's core value is unquestioningly derived from seeing your friends' latest updates and photos, which you're obviously not going to get without a connection. But the fundamental difference is this: the native app will still open the app and show you all the cached content it has. As a result (and for other reasons) the OS has given those types of apps a privileged status.
With full programmatic cache control for the web that ServiceWorkers will offer, you'll be able to choose to load your app and whatever latest content you had downloaded from cache first while optionally trying to connect and download new things from the network. The addition of a controllable cache layer in web apps means that an app like facebook really has no compelling reason to be a native app. I mean, really. If you break it down, that app is mostly a friend timeline browser, right? (the key word there being browser).
BUT, even with the addition of ServiceWorkers, there's another extremely important difference: user perception.
We've spent years teaching users that things they use in their web browser simply do not work offline. Users understand (at least at on some unconscious level) that the browser is the native app that gets sites/documents from the Internet. From a user experience standpoint, trying to teach the average user anything different is attempting to roll a quarry full of rocks up a hill.
This is where it starts to become apparent that failing to draw a distinction between a fully client "apps" and a website really starts to become a disservice to all these new capabilities of the web platform. It doesn't matter how good the web stack becomes, it will never compete with native apps in the "native" space while it stays stuck in the browser.
The addition of "packaged" chrome apps is an admirable, but in my opinion, still inadequate attempt at addressing this issue.
At the point where a user on a mobile device opts to "add to home screen" the intent from the user is more than just a damn bookmark, they're saying: "I want access to this on the same level as my native apps". It's a user's request for an installation of that app, but in reality it's treated as a shitty, half-assed install that's really just a bookmark. But the intent from the user is clear: "I want a special level of quick and easy access to this specific app".
So why not just embrace that what they're actually trying to do is "install" that web application into their operating system?
Apple sort of does this for Mac Apps. After you first "sideload" (a.k.a. download from the web and try to run) a native Mac desktop app, they treat it a bit like an awkward stepchild when you first open it. They warn you and tell you: hey, this was an app downloaded from the Internet, are you sure you want to let this thing run?
While I'm not a fan of the language or the FUD involved with that, the timing makes perfect sense to me. At the point I've opted to "install" something to my homescreen on my mobile device (or the equivalent to that for desktop), that seems like the proper inflection point to verify with the user that they do, in fact, want to let this app have access to specific "privileged" OS APIs.
Without a simple way to install and authorize a clientside web app, these kinds of apps will always get stuck in the uncanny valley of half-assed, semi-installed apps.
So why bother in the first place? Why not just do native whenever you want to build an "app"? Beyond providing a way to build for multiple platforms, there's one more thing the web has that native apps don't have: a URL.
The UNIFORM RESOURCE LOCATOR concept is easy to take for granted, but it's extremely useful to be able to reference things like links to emails inside gmail, or a tweet, or a very specific portion of documentation. Being able to naturally link between apps on the web is what gives the web its power. It's unfortunate that many, when they first start building single page applications don't update URLs as they go and fail to respect the "back" button, thus breaking the web.
But when done properly, the blending the rich interactivity of native apps with the addressability and ubiquity of the web is a thing of beauty.
I cannot understate how excited I am about Service Workers. Because finally, we'll have the ability to build web applications that treat network resources the same way that good native applications do: as an enhancement.
Of course, the big IF is whether platforms play along and actually treat these types of apps as first class citizens.
Call me an optimist, but I think the capabilities that ServiceWorkers promise us, will shine a light on the bizarre awkwardness of the concept of opening a browser to access offline apps.
The web platform's capabilities have outgrown the browser.
Let's help the web to make its next big push.
--
I'm @HenrikJoreteg on twitter. I'd love to hear your thoughts on this.
For further reading on ServiceWorkers, here is a great explainer doc.
Also, check out my book on building sanely structured single page applications.