We've seen a lot of local-first content fly by in the past weeks. But what is local-first? In short, software that works without an internet connection and syncs with the internet when it gets the chance. Nikita Prokopov has a longer short explanation that does the concept more justice.
Linear is admired for its responsive UI. They haven't found a way to send data over the wire faster than the speed of light (as far as we know). Instead, they've built a local-first app. Tuomas Artman, co-founder of Linear, has a talk online on the unexpected benefits of going local-first.
Looking at a traditional app that makes a POST request on every button press, local-first sounds like a huge amount of overhead. A local-first app has an optimistic UI by definition. User clicks button, app marks action as succesful, app makes network call. Depending on the network call result, roll back. Building an optimistic UI is trickier than building a traditional synchronous one that never needs to deal with data that is marked invalid after the fact. With local-first, it's different. Your app doesn't care about the network at all. It manages local data, while a separate sync engine is ensuring your data is fresh and your actions are persisted. This decouples your UI code from the network, which is conceptually much simpler.
From Jim Nielsen: "With localfirst, all logic and data lives on one computer: yours (the client). The second computer (the server) is an optional enhancement to the application that provides data backup as well as sharing functionality. Sync engines tackle the complex problem of coordination across two computers. […] Rather than requiring execution and coordination to work in conjunction across space and time, you split up the execution and coordination into different problems solved by separate solutions. Coordination builds on top of execution, but is not necessarily a required dependency."
