Offline First: Love the Idea, Hate the Name

Back in 2014, I had the great pleasure of listening to Ola Gasidlo of Hood.ie discuss the importance of offline at Beyond Tellerrand in Düsseldorf, Germany. Her excellent talk was my introduction to the “Offline First” movement and, while I can get behind the idea, I’ve had some serious issues with the name. And with the rise of Service Workers as a simple, usable means of making our content available offline, I thought it worth revisiting the idea of “offline first”, if only to address its core fallacy.

First, the good stuff: The “offline first” movement clearly recognizes the current dilemma of our time:

We live in a disconnected & battery powered world, but our technology and best practices are a leftover from the always connected & steadily powered past.

App Cache, Web SQL, Web Storage, Indexed DB, Service Workers, and a handful of other specs and ideas were all created to address this core limitation of the Web. They also make it possible to compete with traditional software experiences. I am 100% on board with this move. It sucks to open Chrome on my mobile and switch to a tab that’s been tucked out of view for a while only to have the page fail to load because I happen to be traveling abroad without a data plan. If that site was made to work offline, the fact that Chrome had recycled the RAM and CPU that tab had been consuming would be less of a problem and the page would load instantly from the cache.

Tunnels… hotel wifi… high latency mobile networks… expensive roaming data plans… these are all reasons we need an offline Web. I’m incredibly thankful for all of the hard work the smart folks working on solutions like these are contributing.

Also inline with the “offline first” movement, I think it’s important to consider the offline experience early in a project, so it isn’t forgotten or haphazardly bolted on. We need to make deliberate choices about what content and assets we are caching. We need to plan for offline, maybe not first, but certainly early.

All of this is to say I don’t have an issue with the philosophy of “offline first”, but I do take issue with the name. As a term, it’s a bit disingenuous. Looking at other “firsts”—“mobile first” or (to go back little further) “content first”—these terms work on multiple levels: They remind us to keep the core purpose of a page or interface central to our planning. They also support an experience that begins and ends with that core.

A “mobile first” experience starts with a distraction-free central message or content, optimized for a small screen and (often) a single, narrow viewport. It can be enhanced for larger screens and more capable devices, but that core experience may be all some users get, and that’s ok. Users will have an experience (and a site that works) no matter what. The same is true with a “content first” approach; its experience remains available regardless of device or access mechanism. Sure, both “mobile first” and “content first” require the network, but guess what: "Offline first" requires network connectivity too! You don’t see many websites delivering their content on USB drives, so all of the code required to make the offline experience possible in the first place requires an initial (and stable) connection to the Web. In other words, offline can’t be first.

You may be wondering Why is that important? It’s important because, historically, a “first” approach (as I mentioned) sets an expectation of that experience always being available. Offline can’t provide that.

Moreover, offline has another core dependency beyond the network: JavaScript. Without JavaScript, none of your fancy offline stuff—except App Cache, which few folks are using these days—will work. And yes, I know, everyone has JavaScript support… but the reality is that not everyone will get your JavaScript enhancements, even if that were actually the case.

Please don’t misunderstand the purpose of this post: I applaud the ideas behind the “offline first” movement and the amazing work that community is doing. And you should absolutely incorporate offline into projects you are building for the Web. Users with capable devices and browsers will thank you for it. Just try not to use the term “offline first” or at least be prepared for me to cringe a little when you do. Maybe I’m the only one who feels this way; if so, I’m okay with that. But, then again, semantics matter. Maybe we need a different rallying cry. Sadly “Offline Too” doesn’t have the same ring to it.


Webmentions

  1. @AaronGustafson It's "First", because offline is not a feature you can add later.
  2. @gr2m I’m all for planning early. And I said as much in the post. I don’t know about first, but early.
  3. @gr2m Really? I had a site before I had a Service Worker. On other projects we used offline tools as well, but as an enhancement.
  4. @AaronGustafson also it's usually a very different architecture if you need 2way sync for editable offline data
  5. @AaronGustafson it's not only a technical issue. The tech is the simplest bit. UX is much harder. Trust me, been there, hard to add later

Shares

  1. Chris Wright
  2. Erwan Carriou
  3. Tzviya Siegman
  4. Baldur Bjarnason
  5. Morgan Hallgren

Comments

Note: These are comments exported from my old blog. Going forward, replies to my posts are only possible via webmentions.
  1. jaffathecake

    "Offline first" means you code in a way that gives priority to local cached content, then use the network as an enhancement or a fallback. Sure, in the very first load, and for browsers without service worker support, you have to fall back to the network for everything, but your prioritisation is still offline-first, hence the name.

    My reaction to your hatred of the term is pretty much "get over it", but do you have an alternative term in mind? "Offline too" makes the offline part sound like a secondary effort, it doesn't differentiate between offline vs online prioritisation, so it doesn't work.