Most web application developers reach for the tried and tested approach of fetching data from their API right when they need it, and they don't give an offline-first approach the consideration it deserves. Perhaps that's because working offline is generally thought of as a specific feature and that it's not necessarily applicable or appropriate for a wide variety of applications. However, there's a lot to be gained from going offline-first, even if your app isn't the "typical" offline application. Hopefully, after reading this article, you'll feel like you're better equipped to answer if working offline-first is right for your app.
When we say "offline-first", we don't just mean a bit of caching that means your user can revisit some pages they've already seen before. Many web apps make heavy use of the browser cache to achieve some basic level of functioning without a working internet connection. We're talking about going well beyond that.
For us, an offline-first web application is an application that is designed to be (close to) fully-functional without an internet connection. Now of course, the application may need an internet connection the first time around to authenticate the user and download some data. However, after that initial sync, it should be able to function without internet connectivity for some period of time. This means that not only browsing data (i.e. read operations) should work, but the user should also be able to create and update data (i.e. write operations) while in a disconnected state.
There are a million and one ways to achieve this kind of offline-first functionality. There's the browser cache, service workers, local storage, IndexedDB and a myriad of other tools that can be brought together to give your users a brilliant offline experience.
Inspired by the offline-first tools we use every day like Superhuman, Figma and Pitch, we've recently been working hard to turn Kitemaker, our product management tool for cross-functional, self-organizing product teams, into an offline-first application. We fetch the data the user may need ahead of time and store it in a local cache. The web application itself operates on that local cache only, and a separate layer takes care of syncing those changes back to the server. Our design was heavily inspired by the work Evan Wallace published about how multiplayer behavior works in Figma. We're currently working on using service workers to download static assets and using IndexedDB to back our cache with persistent storage. We'll do a follow-up blog post on how offline works in Kitemaker, but here's a quick peek at the architecture:
But this is just one example of how to achieve offline functionality. Exactly how you solve it will depend heavily on your application. The important part is that you start to think about whether your app should be offline-first.
You may be thinking that offline functionality sounds nice, but isn't super relevant most applications. We tend to disagree. We think there is a trend to push more and more SaaS products towards supporting working offline, and we think this is absolutely the right idea.
We'd be surprised if you didn't answer "yes" to at least a couple of those questions.
There are a bunch of advantages that come along with making your application offline-first:
While there are numerous advantages to working in an offline-first, it's not a given that you should dive in right away. Think about these things a little first:
We hope this article got your gears turning a little when it comes to offline-first web applications. We don't think appropriate for every application - it can be quite a lot of work to get right and for some applications it just doesn't make a lot of sense. But we just think people should give it some thought when designing and architecting a new application. We've learned from experience that retrofitting this type of behavior can also be quite a lot of work, but we're super happy we did it nonetheless!
And if you're a software product team that aspires to work in a more cross-functional, autonomous, self-organizing and impact-driven way, sign up for Kitemaker. We've built it for teams just like yours.
This is a post about the pain that comes from trying to scale CSS in a large project.
Building an awesome editor for your React-based web application is by no means easy. But with SlateJS things get much easier.