ideas & ramblings

Wither offline mode?

One of the major driving factors for the move to Single-Page Applications (SPAs) over the past decade has been the potential to allow offline (or low-connectivity) usage. When any given interaction within an app has the potential to require a network request, having a fast, reliable internet connection is critical.

SPAs trade the need for constant connectivity into a desire for constant connectivity, offsetting that requirement by pre-loading code and data up-front for future use. If you can wait just a few seconds longer at the start of your session, the logic goes, then you’ll have a faster and more responsive user interface that also happens to be capable of working offline.

Whether or not this trade-off makes sense depends on a wide variety of factors, most obviously how long user sessions actually last for, but also how much time is invested in building a compelling offline experience in the first place.

Just how complete is the offline support?

SPAs don’t instantly and magically become fully offline-capable applications just by virtue of existing. Somebody needs to decide which features—is it all of them? just mission-critical ones? a random, unknowable subset?—will work offline, and which ones won’t. What happens when you try to use a non-offline-capable feature? Does it fail gracefully or just…kind of break? How will a user know why something isn’t working or isn’t available right now? How much effort do we want to put into user education and onboarding for an edge case?

The offline tax

Managing the loading of data, how it gets cached, how it gets invalidated, and just what happens when there’s no connectivity at the moment all requires substantial thought and investment.

The sorts of engineers who spend their time thinking about data flow, reconciliation, and cache invalidation are certainly not in the majority at the average tech co. At best, a large product team could hope to have one or two domain experts who think about “offline mode” as a concept, with the remaining team members breaking it from time to time, as you’d expect with any other niche feature.

At best, pervasive offline support exists as a sort of tax on all other feature development. The same can be said for things like accessibility & localization, but unlike with those two things, offline mode is not a moral imperative for enfranchising large groups of humanity1.

Who actually needs this feature?

At a prior employer, some of the loudest voices for offline mode (both internally and externally) were executives who spent a lot of time trying to get work done while traveling. Even this fairly unrelatable use case offers an increasingly less persuasive argument for implementing a full-featured offline mode, since decent internet connectivity on airplanes, in airports, and on the road is virtually guaranteed in many parts of the world.

Depending on the geographical location of your users, some base level of connectivity can be assumed, and the shift from “no connectivity” to “low connectivity” can actually be fairly profound. In a low connectivity environment, an application that leans on a remote server to do the heavy lifting can actually lead to a better user experience overall.

Wither offline mode?

The difficulty of implementation, the ongoing maintenance costs, and the vanishing user base all add up to a feature that just doesn’t make sense a lot of the time. At some fundamental level, offline mode just isn’t part of the web’s DNA, and—for a lot of us—it’s probably time to let it go.

Without the distraction of offline mode, more HTTP-first programming models such as HTMx start to look more viable. Web browsers have had millions, if not billions, of dollars of collective investment over the past three decades. They are some of the most capable and ambitious pieces of software ever written—and yet it’s commonplace for small teams of developers to toss aside large pieces of built-in browser functionality in favor of doing everything from scratch.

This is folly. Web browsers are incredible, and building web applications against powerful servers is a proven, scalable, and efficient technique. It’s time to return to the old ways and let our JavaScript garbage collectors take a bit of a breather—they’ve earned it.

Appendix: Counterarguments

I highly respect the thinking of the Ink & Switch folks, and they make a compelling argument for local-first (and inherently offline-capable) applications. A recent blog post from Jim Nielsen described offline as just “online with extreme latency”, which is pithy and funny but also insightful.

However, I find myself increasingly skeptical. Although our devices are astoundingly capable and getting better on an annual basis, local-first software does not seem like the future to me: the benefits of the cloud are simply too great, and the average person just does not care about abstract ideas like data sovereignty.


  1. An argument could be made against this statement, given that pervasive high-speed internet connectivity is not a given in many parts of the world. This is certainly outside my area of expertise, but it seems to me that people in those markets are not the most likely target audience for the average VC-funded SaaS web application circa 2023. ↩︎