If we really want to liberate people from spreadsheets, we need to be able to provide first-class support to the offline scenario.There are two big challenges with building an app that works offline:It has to work when no server is available (duh), which means that it needs to have a full local copy of the data that it needs.When the app does go back online, it needs to reconcile changes that have been made locally with changes that have been made elsewhere.The standard browser/server/database model isn’t well-suited to offline scenarios.Long story short, this isn’t the architecture you would start with if offline usage is a priority..It might be possible to bolt on offline capabilities after the fact, but it wouldn’t be easy and it wouldn’t be pretty.Since we are starting from scratch, we can do better..But we’ll have to rethink things at a more fundamental level.How did we get here?This is the sort of kludge that you get when you’re at a very specific and awkward juncture in the history of technology.Specifically: Since the invention of the computer, the pendulum has swung every few years from putting intelligence on the server, to putting it on the client, and back again..Most recently, we’ve gone from dumb terminals running software on a mainframe, to PC operating systems with software installed, to software as a service delivered in the browser.The original web applications ran entirely on the server, and the browser was just a dumb terminal..Each interaction caused the server to re-render a fully-formed HTML page and send it to the browser..In 2005 AJAX became a thing, allowing us to avoid some of those round trips..Ever since then we’ve been moving intelligence back to the client in bits and pieces.More than a decade later, you can do pretty much anything you want within a browser, and even more if you give the browser big-boy pants by wrapping it in Electron..But we’re still living with a lot of assumptions that come from the days of server-side rendering.What if we only had a client?Let’s take a step back and think about what a “web application” with no web server would look like.The most obvious answer is that we need the server to collaborate with others..If you’re the only one involved in whatever you’re working on, you may not need a web app..But if you’re working with a team of two or more people, you want some way of keeping everyone on the same page, and centralizing the data on a server is an obvious way of doing that.So, yes, this would be a very simple architecture:Simple, but not very useful.But Herb, I hear you saying: This is of no use to us if Client A (Alice) and Client B (Bob) need to collaborate.So let’s put on our “pretend it’s magic” hats.Let’s just imagine for the moment that we had a magical way of automatically and instantaneously synchronizing Alice’s data with Bob’s data, so that when they’re both online, they’re both always looking at the same thing.Simple, but you have to believe in magic.If we had that magical piece, then we’d truly be able to eliminate duplication in our codebase.But wait, you say!.This peer-to-peer setup requires Alice and Bob to be online at the same time..If Alice makes some changes and then goes offline, Bob won’t see them the next time he comes online.OK, no problem — we can just fire up a client on a computer that no one uses, and leave it running all the time.Congratulations, we’ve just re-invented the server!Except this server is really just a special instance of our client — one that no one uses directly, and that lives on high-availability infrastructure.Our headless-client-as-server doesn’t require a separate codebase.. More details