React Helsinki February 2020

Linear's write ups / talks on real-time sync are also very good, if a bit old now. 1. ▶ this video 2. [link] Also see this overview of related tech here: 3. [link] And c.f. automerge from ink & switch: 4. [link]

in “How Figma’s multiplayer technology works (2019)” · View on HN

Replicache ( [link] ) and clientdb ( [link] ) are the only productized versions of this architecture I'm aware of (please do let me know if anyone is aware of others!). But the architecture itself has been used successfully in a bunch of apps, most notable of which is probably Linear ( [link] , I remember watching an early video of their founder explaining the architecture in more detail but I can't seem to find it anymore (edit: found it! ▶ this video )). Basically the way authorization works is you define specific mutations that are supported (no arbitrary writes to client state, so write semantics are constrained for ease of authorization and conflict handling), with a client-side and server-side implementation for each mutation. The client side gets applied optimistically and then sync'ed and ran on the server eventually, which applies authorization rules and detects and handles conflicts, which can result in client state getting rolled back if authorization rules are violated or if unresolvable conflicts are present. Replicache has a good writeup here: [link]

in “The Future of the Web Is on the Edge” · View on HN

We created Linear[1] as local-first product. Back in to 2019 there wasn't much anything available so we created our sync engine. Today we have several thousands companies, from early stage to public companies as paying customers (companies such as Vercel, Replit, Substack, Square..) Our co-founder did talk about sync engine back in 2020 and recently did updated talk about scaling it [3]. The scaling has definitely taken lot of work and optimizing as datasets for company wide workspace with potentially thousands of users ands object they created can become quite large. 1: [link] 2: ▶ this video 3: [link]

in “Some notes on local-first development” · View on HN

(Cofounder here) The app is fullstack typescript react application with custom realtime sync engine for instant updates and offline readiness. Our cofounder did a talk about our sync few years back: ▶ this video The app works both in the browser and we also distribute it with Electron wrapper for macOS and Windows, but it's essentially the same experience.

in “Linear.app” · View on HN

I mostly agree, but having used Linear.app which has a crazy good and fast UI based on a local database synced with their cloud database, I'm not sure anymore: ▶ this video . I think it's important to define early in a project if the app is "cloud-based" or "local-based". If it's cloud-based, then only the server mutates state and sends views to the clients, as you wrote. Everything is simple. If it's local-based, then all data are available locally and mutated locally. The cloud is only used as mirror/backup and can support for some advanced features like full-text search. That's also a very clear architecture. That's how Linear works. Things become hairy and unnecessarily complex when no clear choice is made between those two options, then it's not clear where the state is.

in “React's UI State Model vs. Vanilla JavaScript” · View on HN