Linear hat mich in das Local-First-Rabbit-Hole geführt

• Die Nutzung von Linear hat meine Sicht auf die Entwicklung von Webanwendungen deutlich verändert
• Linear arbeitet local-first und bietet sofortige Reaktionen ohne jegliche Netzwerkverzögerung bei Interaktionen
• In diesem Ansatz hat der Client eine unabhängige Datenbank und Änderungen werden asynchron mit dem Server synchronisiert
• Allerdings ist die Implementierung von Synchronisation in verteilten Umgebungen, Konfliktlösung, Offline-Verarbeitung etc. deutlich aufwendiger
• Jazz, Electric SQL, Zero und weitere Lösungen aus dem local-first-Ökosystem entstehen, während die Entwicklererfahrung schrittweise besser wird

---

Überblick

Beim Einsatz von Linear, einem Projektmanagement-Tool, war ich stark davon beeindruckt, wie schnell und wie gut die Benutzererfahrung im local-first-Modell war. Besonders auffällig war, dass Dinge, die man bei herkömmlichen Web-Apps oft erlebt – wie Netzwerklatenz, Ladezustände und Seitenaktualisierungen – hier praktisch nicht vorkamen. Diese Erfahrung hat mich dazu gebracht, mich intensiv mit den technischen Prinzipien und den realen Anwendungsfällen des Local-First-Paradigmas auseinanderzusetzen.

Im Kaninchenloch

Während ich das technische Fundament von Linear untersucht habe, stellte ich fest, dass sie die IndexedDB im Browser tatsächlich wie eine echte Datenbank nutzen. Alle Änderungen werden zuerst sofort lokal verarbeitet und anschließend im Hintergrund über GraphQL und WebSockets synchronisiert.

• Der Begriff local-first kann unterschiedlich verstanden werden: als UX-Strategie für sofortige Reaktionsfähigkeit oder als Philosophie, Daten lokal zu halten und zu synchronisieren
• In traditionellen Web-Apps war der Server die einzige Wahrheit, doch in einer Local-First-Architektur besitzt jeder Client seine eigene Datenbank
• Mit der Verlagerung der Datenbank näher an den Nutzer werden Netzwerkverzögerungen in Nutzerinteraktionen vollständig entfernt

Die Herausforderung: Das ist nicht trivial

Als ich versucht habe, den Ansatz von Linear direkt zu implementieren, wurde mir klar, wie komplex das Thema ist.

• Übergang zwischen Offline- und Online-Modus
• Konfliktlösung zwischen verteilten Clients
• Teilweise Synchronisierung (damit nicht die komplette Datenmenge heruntergeladen werden muss)
• Schema-Migration von Cache-Daten
• Sicherheit und Zugriffskontrolle in verteilten Umgebungen
• In diesen Bereichen sind enorme Entwicklungsaufwände erforderlich

Das Local-First-Ökosystem im Jahr 2025

Zum Stand von 2025 gibt es im Local-First-Ökosystem mehrere starke Lösungen.

• Electric SQL: Sync-Engine auf Basis von Postgres
• PowerSync: auf Enterprise ausgelegte Lösung
• Jazz: Werkzeug, das den Aufbau von Local-First-Apps stark vereinfacht
• Replicache: ehemalige führende Lösung (Entwicklung eingestellt)
• Zero: neue Ausrichtung des Replicache-Teams
• Triplit: Synchronisierung auf Basis von TripleStore
• Instant: mit Fokus auf die Entwicklererfahrung
• LiveStore: bietet eine Echtzeit-Synchronisierungsschicht

Detaillierter Blick: Jazz

Jazz fiel durch das eigene Versprechen auf, „Local-First-Apps so einfach wie Zustandsupdates“ zu machen.

Das mentale Modell

Jazz führt Collaborative Values (CoValues) ein, eine Struktur für Echtzeit-Kollaboration.

• Schema-Definition mit Jazz und Zod: Diese Definition ist keine bloße Typdefinition, sondern ein automatisch synchronisiertes Live-Objekt
• Ohne zusätzliche API-Routen, Request-/Response-Logik oder DTOs genügt es, den Objektzustand zu ändern, und die Synchronisation erfolgt automatisch

So erreicht Jazz das

Die interne Architektur von Jazz ist so aufgebaut:

• Eindeutigkeitsgarantie: Automatische Zuweisung einer eindeutigen ID für jeden Datensatz
• Event Sourcing: Änderungen werden als Ereignisse gespeichert, was die Effizienz der Echtzeit-Synchronisierung verbessert
• End-to-End-Verschlüsselung: Vor der Synchronisierung wird auf dem Client verschlüsselt. Der Server sieht nur verschlüsselte Blobs
• Gruppenbasierte Berechtigungsmodelle: statt klassischer ACLs werden Berechtigungen gruppenbasiert verwaltet; Zuständigkeiten sind klar getrennt

Die Trade-offs

Dieses Design ist für Prototyping und schnelles UI-Entwickeln sehr produktiv. Es gibt aber einige Punkte, die wegen gewisser Eigenschaften berücksichtigt werden müssen.

Dein Server ist blind

Durch die End-to-End-Verschlüsselung kann der Server die Nutzerdaten nicht lesen. Wenn vorab nicht klar definiert ist, auf welche Daten der Server zugreifen muss, entstehen Beschränkungen bei der Verwaltung, etwa bei Überwachung oder dem Schutz vor missbräuchlicher Datenspeicherung.

Time Travel ist obligatorisch

Durch Event Sourcing wird die gesamte Änderungsgeschichte dauerhaft gespeichert. Das macht Undo/Redo sehr bequem, bringt aber den Nachteil mit sich, dass Löschen unter rechtlichen Anforderungen wie der DSGVO schwierig ist.

Storage geht hoch

Da kaum gelöscht wird, steigt der Speicherverbrauch Schritt für Schritt. Bei kleinen Projekten ist das oft okay; bei großen SaaS-Anwendungen kann es jedoch deutlich teurer werden.

Lokalentwicklung hat immer noch Tücken

Die Authentifizierung basiert standardmäßig auf Passkeys. Beim eigenen Ausbau oder in lokalen Umgebungen gibt es zu Beginn jedoch Umstände wie HTTPS, Zertifikatsverwaltung und Schlüsselübergabe. Verbesserungen wie die geplante Better Auth-Integration sind jedoch vorgesehen.

Aber ehrlich gesagt: immer noch sinnvoll

Trotz dieser Beschränkungen ist die Entwicklererfahrung und Produktivität von Jazz sehr beeindruckend. Die Lösung ist noch in einer frühen Phase, aber viele dieser Probleme werden vermutlich schrittweise gelöst.

Erkundung: Electric SQL und Zero

Im Unterschied zu Jazz verfolgen Electric SQL und Zero einen inkrementellen Ansatz.

• Bestehende Postgres-Tabellen können direkt weiterverwendet werden
• Electric SQL kann Teile einer Tabelle über eine reactive query (Shape) abonnieren und so die UI synchronisieren
• Die Behandlung von Mutationen unterscheidet sich von Jazz, und es gibt zahlreiche Optionen wie die Integration von LiveStore
• Zero ist Electric ähnlich, bietet aber eine eingebaute Unterstützung für Änderungs-Synchronisierung

Wann macht Local-First Sinn?

Geeignet:

• Kreativwerkzeuge (Design, Schreiben, Musik etc.)
• Anwendungen mit Kollaborationsfunktionen
• Mobile Apps mit Offline-Unterstützung
• Entwicklerwerkzeuge
• Persönliche Produktivitäts-Apps

Herausfordernd:

• Große serverseitige Business-Logik
• Strenge Audit-Anforderungen
• Große Analysesysteme
• Tief integrierte bestehende Systeme
• Systeme, in denen der Server Anfragen häufig ablehnt

Ausblick

Local-First bedeutet eine Paradigmenverschiebung in der Webentwicklung. Linear hat bereits die Wirksamkeit im Nutzererlebnis eindrucksvoll gezeigt. Entwickler sollten prüfen, ob diese strukturellen Kompromisse zu ihrem Projekt passen.

Mit einer persönlichen App basierend auf Jazz erfahre ich aktuell die echten Stärken und Grenzen der Abstraktion. Das Ökosystem ist noch jung; in Zukunft werden Werkzeuge und Muster wahrscheinlich reifer und besser werden. Der Vorteil, Daten lokal zu halten, ist jedoch klar und wird nicht verschwinden.

Wenn man die Einschränkungen eines neuen Projekts akzeptieren kann, lohnt sich ein Ausprobieren von Local-First auf jeden Fall. Im schlechtesten Fall lernt man ein neues Architekturmuster, im besten Fall lässt sich eine bis dahin unmögliche Nutzererfahrung realisieren. Im Wettkampf um Reaktionszeiten im Bereich von 300ms ist das ein entscheidender Vorteil.