Linear hat mich in das Local-First-Rabbit-Hole geführt
(bytemash.net)- 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.
1 Kommentare
Hacker News Kommentar
Zero bietet auch Funktionen wie Electric und unterstützt Mutationen direkt. Der Kernunterschied bei Zero ist die abfragezentrierte Synchronisierung. Man kann Apps auf Query-Ebene entwerfen und synchronisiert einfach nur, was eine Query braucht, ohne vorher festzulegen oder zu konfigurieren, welche Daten synchronisiert werden sollen. Wenn dem Client die benötigten Daten fehlen, geht die Query automatisch auf den Server und synchronisierte Daten sind anschließend sofort für die nächste Query verfügbar. Das ist ziemlich praktisch.
Ich bevorzuge SSR. Ich finde, der Client sollte nur den Session-Token, die aktuelle URL und den DOM als Zustand behalten. Netzwerk und Server werden kontinuierlich schneller. Die Lichtgeschwindigkeit ist konstant, aber wir nutzen sie noch nicht vollständig. Mit Technologien wie Hollow Core Fiber könnten in Zukunft bis zu 30 % der Internetlatenz gesenkt werden. Selbst wenn die RTT 500 ms beträgt, fühlt sich eine per SSR in 16 ms gerenderte Seite deutlich unmittelbarer an als die meisten Webseiten heute. Ich halte es für unmöglich, dass ein Server länger als die Dauer eines 60-Hz-Frames mit dem Rendern der HTML-Antwort braucht. Auf einem Zen5-Kern kann man in dieser Zeit 30 bis 40 MB JSON serialisieren. Für den Server ist das nur ein hübscher UTF-8-String. Solche Dinge sollten im μs-Bereich gemessen werden, nicht in ms. Eine hohe Übertragungsverzögerung ist kein Grund, die CPU-Zeit verschleissen zu dürfen. Mit SQLite habe ich das Millisekunden-Fängnis hinter mir gelassen. Gehostete SQL-Dienste sind eine Fessel, wenn man auf Latenzen unter 1 ms abzielt. Browser-Standards können auch ein paar Navigationslatenzprobleme entschärfen. Siehe auch die Speculation Rules API
Dass Netzwerk und Server immer schneller werden, ist kein allgemeines Argument für SSR. Es zeigt eher, dass es Ausnahmen gibt, in denen SSR notwendig ist, etwa wenn ein Server mehr Rechenleistung hat oder eine Trennung der Logik schwerfällt. In der Praxis ist Client-side Rendering oft schneller. Die Renderlogik ist häufig deutlich komplexer als die Datenmenge, und zusammengenommen können alle Client-Ressourcen teurer sein als die auf dem Server. Wenn SSR die einzige Option wäre, wäre der aktuelle Hype um WebAssembly schwer zu erklären. Ein Artikel über local computation ist ebenfalls lesenswert. Letztlich lässt sich im Voraus nicht sicher sagen, was besser ist; die Auswahl sollte zur Request-Zeit möglich sein.
Right Tool For The Right Job! Reicht es eigentlich, kollaborative Dokumente wie Google Docs oder Google Sheets nur mit Server-Side-Rendering zu betreiben? Wenn man bei SSR bleibt, kann es passieren, dass ein Benutzer mitten im Editieren sieht, dass jemand anderes den Inhalt geändert hat. Solche Tools funktionieren, weil Änderungen klein sind und die Nutzer sofort erkennen, dass sie zusammenarbeiten, da sie Echtzeit-Updates erhalten. Bei einem Hotelbuchungssystem ist Echtzeitsynchronisierung hingegen nicht nötig. Und bei wackeliger Zwischen-Synchronisierung oder schlecht vorgedachter Unternehmenssoftware wird es später durch Domain- und Systemkomplexität ziemlich schwierig, die Konsistenz zu halten.
Wenn man solche Bibliotheken einfach so zu einer bestehenden SSR-App hinzufügen könnte, würde ich sie nutzen:
Das ist echte Happy-Pass-Engineering. Für Menschen außerhalb der Happy-Path ist das in der Praxis oft ziemlich frustrierend.
Der aktuelle und zukünftige Hauptzweck von SSR ist das erste Laden einer Seite, vor allem auf Mobilgeräten. Danach werden nur noch Zustandsupdates im Client benötigt, daher muss alles schneller sein. Bei unzureichenden Engineering-Fähigkeiten bringt selbst SSR nicht viel.
Ich habe eine Open-Source-Task-Management-Software mit CRDT-basierter Local-First-Architektur entwickelt. Der Grund war, dass ich keine Kollaborationsfunktion gebraucht habe und Tools wie Linear für meinen Anwendungsfall zu komplex waren. Die Vorteile dieser Architektur sind:
Von Jazz bin ich stark beeindruckt. Das DX ist exzellent, weil man beinahe synchronen, imperativen Code schreiben kann, was die Entwicklung angenehm macht. Alles fühlt sich sofortig an, und weil Offline-Arbeit möglich ist, ist auch die UX hervorragend. Das größte Problem ist Deployment und Langzeitwartbarkeit sowie dass Datenmenge weiter wächst (die meisten Clients müssen sie nicht komplett sehen, daher mache ich mir darüber kaum Gedanken). Der größte Punkt ist der Mangel an einer guten Lösung für oft wechselnde public Indexes. Theoretisch ist eine öffentlich lesbare ID-Liste möglich, aber wie ich mit Anselm besprochen habe, wird daran gearbeitet. Insgesamt ist Local-First nicht billig, aber wenn Jazz die Hauptschwächen der traditionellen zentralen Server-Architektur behebt, kann es Firestore fast vollständig ersetzen.
ElectricSQL und TanStack DB sind beide sehr gut, aber ich frage mich, warum auf dem Web so stark auf local first gesetzt wird. Auf Mobile ist local-first meiner Meinung nach wesentlich nötiger wegen Offline-Szenarien. Beim Webbrowser sind wir im Alltag ohnehin meist online. Und obwohl diese Local-First-Technologien in der Theorie überzeugend wirken, brechen sie in der Praxis oft auseinander, wenn Konflikte nicht sauber aufgelöst werden. Das ist die Lektion aus dem Bau von Local-First-Apps im Mobile-Bereich, deshalb setze ich auf CRDT.
Eine Local-First-App mit Webtechnologien zu bauen ist im Vergleich zu Native um ein Vielfaches schwieriger. Native-Apps haben Offline-Funktionalität standardmäßig, sobald sie installiert sind. Im Web muss man sie mit AppManifest, ServiceWorker usw. über Umwege irgendwie drangepflanzt bekommen. In nativen Apps ist das freie Lesen und Schreiben von Dateien auf der Platte mit 30 Jahre altem C-Code Alltag. Im Web ist IndexedDB ein echter Alptraum, localStorage ist bei wachsender Größe nicht nutzbar und OriginPrivateFileSystem ist begrenzt. Wenn ein Nutzer einen Monat lang die Seite nicht besucht, löscht Safari den lokalen Browserzustand. Selbst mit JavaScript- oder Emscripten-WASM-Builds bleibt alles ein Balanceakt, um async Web APIs irgendwie durchzuwurschteln. Apple liefert seit 2015 mit der Kombination aus CoreData + CloudKit eine vollständige Local+Sync-Lösung. Auf Googles Seite ist Firebase vermutlich am ehesten vergleichbar.
Als Entwickler bei Replicache und Zero habe ich viel darüber nachgedacht, warum der Fokus auf Web liegt. Ich weiß es noch nicht, aber meine Sicht ist:
Mobile hat wesentlich stärkere native Offline-Basics als Web. Aber die meisten Produktivitäts- und Kollaborationsszenarien laufen im Web, das ist ein deutlich feindlicherer Kontext. Es gibt komplexe Fragen wie tabübergreifende Zustandssynchronisierung oder Speicherlöschungen. Deshalb entwickelt sich Local-First vor allem um Web herum.
Dass sich Sync-Engines zunächst auf Web konzentrieren, liegt daran, dass diese Technologien noch jung sind und häufige Updates haben. App-Updates auf Mobile sind wirklich schmerzhaft, während Web-App-Updates viel einfacher sind. Ich halte PWA-Fähigkeiten inzwischen für ziemlich solide. Auch iOS-PWAs können Push-Benachrichtigungen empfangen, und ich bin mit webbasierten Apps, die wie Mobile-Apps aussehen, vollkommen zufrieden.
Der Punkt ist nicht die Frage, welche Features ich nutzen kann, sondern die Freude an einem unglaublich schnellen und reaktiven Produkt. Deshalb setze ich auf Local-First.
Der kollaborative Aspekt von Local-first-/Sync-Engines scheint mir selten behandelt zu werden. Ich baue derzeit mit Zero ein Projekt, das die Google-Tabelle meines Freundes für Business ersetzt. Wir öffnen in Google Meet gleichzeitig ein Sheet und bearbeiten die Daten zusammen. Solch ein Erlebnis hätte ich früher für eine Web-App nicht einmal für möglich gehalten. Ich habe viele Live-UIs mit WebSockets gebaut, aber es ist extrem kompliziert, eingehende Daten an der richtigen Stelle korrekt zu spiegeln und zu verwalten. Bei Hunderten oder Tausenden von Tabellenzellen ist diese Komplexität kaum vorstellbar. Mit Zero wähle ich Daten per Query aus und ändere sie mit Mutatoren; alles wird sofort für alle Teilnehmer synchron. Das macht die eigentliche Entwicklung wirklich zum Vergnügen.
Als Google Docs das erste Mal veröffentlicht wurde (ich war 12 Jahre alt), dachte ich, mit Echtzeitsynchronisierung und kollaborativen Cursors würden künftig alle Web-Erfahrungen kollaborativ werden. Damals war Cloud Computing ein Buzzword, und ich dachte zwar falsch, aber auch, Echtzeitkollaboration sei die Definition von Cloud Computing. Diese Zukunft ist letztlich aber nicht Realität geworden. 20 Jahre später sind die meisten Web-Produkte immer noch CRUD-Erfahrungen (diese Seite eingeschlossen). Ich dachte immer, die nächste große Innovation sei kurz bevorstehend; ich setzte auf Meteor.js, React usw. und dachte ebenfalls, das würde so standard werden – bisher ist es nicht der Standard. Ich erwarte weiterhin, dass das wirklich Mainstream wird; irgendwann wird es sicher passieren. Es ist nur schwieriger als erwartet, und es gibt keine so erschwinglichen Tools für alle Fälle.
Beispiele für Echtzeit-Kollaboration sind Discord (im Grunde nicht weit weg vom IRC der 90er) und Zoom (jede Videokonferenz), Dass ein Ort wie HN eine CRUD-App ist, ist ein Vorteil. Echtzeit-Updates sind hier eher störend und unerwünscht.
Die Lichtgeschwindigkeit ist tatsächlich eine Grenze. Licht braucht 56 ms für eine halbe Erdumrundung; echte Signale laufen Umwege und zusätzliche Hürden wie Load Balancer, DDoS-Schutz usw. durch, was es noch langsamer macht. In vielen Fällen ist die Latenz heute schlechter als früher.
Ich habe selbst diese anfängliche Magie der Echtzeit gespürt, doch das Zukunftsbild scheint irgendwo weiterzuschwirren. Und trotzdem baue ich gerade ein echtes Google Docs-artiges, sofortiges Messaging-Tool ohne Eingabefeld und Senden-Button: kraa.io/hackernews
Ich glaube an die Zukunft von Local-First und Sync-Engines. Die Tabelle zur Landschaft der Local-First-Frameworks ist ausgesprochen hilfreich. Persönlich fand ich Triplit.dev am hilfreichsten, und man kann es mit TanStack DB kombinieren. PowerSync und NextGraph sind ebenfalls Optionen, die ich erkunden möchte. Ich schaue mir gerade auch den Vortrag zu NextGraph auf dem LocalFirst Conf an: YouTube-Video
Mich interessiert, wie gut diese Tools Datenbankmigrationen unterstützen. Wenn man langfristig Clients ohne Serverzugriff unterstützen muss, ist ein Rollforward-Migration von einem sehr alten Schemastatus wahrscheinlich eine große Hürde. Allein das Debugging von Bugs in einem Single-User-Frontend ist schwer; mit zu berücksichtigendem Schemazustand wird die Komplexität unvorstellbar.
Das erinnert mich an Meteor.
Solche Ansätze sind auch ein bisschen altmodisch.
Ich muss Triplit unbedingt ausprobieren, und ich frage mich, ob jemand InstantDB schon genutzt hat. Ich war auch interessiert, habe es aber noch nicht verwendet.
Ich habe Electrics Ansatz ziemlich gut gefunden und war lange daran interessiert. Electric ist sauber, weil es die Komplexität der Entwickler und API übernimmt. Bidirektionale Sync-Lösungen funktionieren meist gut nur auf dem Niveau einfacher Todo-Apps. Sobald Berechtigungen, Business-Logik-Evolution, Migrationen und Produktwachstum dazu kommen, entstehen Zweifel an der Belastbarkeit. Electric unterstützt Read-Sync nur über Views und behandelt Writes weiterhin über bestehende APIs/REST/RPC, was die Einführung in bestehende Projekte einfach macht.
Ich frage mich, warum CouchDB/PouchDB in der Liste nicht auftauchen. Es ist immer noch ein ziemlich gut funktionierendes Tool.