LiveView: die Technik, die am besten zu Svelte passt

Die Kombination aus LiveView und Svelte

• LiveView bietet eine einzigartige Methode zum Aufbau von Webanwendungen.
• Der Server hält den Zustand, verarbeitet das Frontend-Verhalten im Backend und aktualisiert das DOM schrittweise.
• Die Komplexität von SPAs entsteht durch die Komplexität verteilter Systeme, und LiveView ermöglicht ein reichhaltiges Client-Erlebnis ohne Frontend-Microservices.

Was an LiveView schwierig ist

• Client-seitiger Zustand ist unvermeidlich, und Latenz zwischen Server und Nutzer lässt sich nicht vermeiden.
• LiveView übernimmt viele DOM-Änderungen auf dem Server, kann aber nicht alles kontrollieren.
• LiveView hat drei Komponententypen: LiveViews, LiveComponents und Components.
• Refactorings zwischen LiveView und LiveComponents sind umständlicher als erwartet.

Die etwas unklare Ausrichtung von LiveView

• LiveView vermittelt oft das Gefühl, dass etwas fehlt.
• LiveView hat viele Gemeinsamkeiten mit modernen Frontend-Frameworks, aber man muss die Unterschiede erkennen und Probleme anders angehen.

LiveView + Svelte

• LiveSvelte ermöglicht das Rendern von Svelte-Komponenten in LiveView.
• Das Backend steuert die Props der Frontend-Komponenten, und sowohl Frontend als auch Backend besitzen Zustand.
• Es gibt einen privaten, bidirektionalen Kommunikationskanal zwischen Frontend und Backend.

Die innovativen Eigenschaften von LiveSvelte

• Die Aufgabenteilung zwischen Backend und Frontend ist klar, und die Komplexität konzentriert sich auf die Serverseite.
• LiveView spielt seine Stärken besonders als Frontend für das Backend aus und stellt einen Backend-Prozess bereit, der Frontend-Komponenten rendert und ihren Zustand erhält.

Meinung von GN⁺

• Die Kombination aus LiveView und Svelte trennt das Zustandsmanagement zwischen Server und Client effizient und ermöglicht es Entwicklern, Anwendungen schneller und intuitiver zu erstellen.
• Diese Technik kann besonders für Webanwendungen nützlich sein, bei denen Echtzeit-Interaktionen wichtig sind, und zur Verbesserung der User Experience beitragen.
• Da Latenz zum Server jedoch die User Experience beeinflussen kann, sind Performance-Optimierung und eine regionale Serverplatzierung wichtige Aspekte.
• Die Kombination aus LiveView und Svelte bietet Entwicklern, die an klassische SPA-Entwicklung gewöhnt sind, ein neues Paradigma, das das Potenzial hat, die Lernkurve zu senken und die Entwicklungseffizienz zu steigern.
• Die von dieser Technik gebotene Echtzeit-Zustandssynchronisierung und bidirektionale Kommunikation kann besonders für Collaboration-Tools, Dashboards oder Anwendungen mit Echtzeitdaten eine attraktive Wahl sein.

[GN⁺]

Hacker-News-Kommentare

• Eines der Muster, die in Multiplayer-Videospielen verwendet werden, ist, dass es Code gibt, der grundsätzlich sowohl auf dem Client als auch auf dem Server ausgeführt wird.

  • Der Client-Code läuft als Vorhersage des Serverzustands.
  • Wenn der Serverzustand empfangen wird, wird der Client-Zustand zwangsweise angeglichen.
  • In Spielen ist „Vorhersage“ ein passender Ausdruck, weil der Client das Ergebnis der Eingaben gut erraten kann, aber nicht sicher sein kann, da er die Eingaben anderer Spieler nicht kennt.
  • Dieses Paradigma kann auch verwendet werden, um sofort auf Client-Eingaben zu reagieren, während auf den maßgeblichen Serverzustand gewartet wird (z. B. Dropdown aktivieren/deaktivieren, Lade-Spinner anzeigen).
  • Es gibt auch viel Client-Zustand, der nicht auf dem Server ausgeführt wird (z. B. Partikelsysteme, Ragdolls – Dinge, die nicht auf allen Clients exakt gleich sein müssen und nicht mit Eingaben/Physik anderer Spieler interagieren).

• Ich habe auf der ElixirConf 2022 einen Vortrag darüber gehalten, wie man LiveView und Svelte kombiniert, und die Mitwirkenden von live_svelte haben dazu beigetragen, dies Realität werden zu lassen.

  • Client-seitiger Zustand ist immer nötig, besonders in Apps mit reichhaltiger UX.
  • In New York City ist insbesondere unterwegs eine Netzwerkverbindung nicht garantiert.
  • Die Möglichkeit, mit dem PubSub von Phoenix serverseitige Zustandsänderungen, die auf anderen Servern entstehen, reaktiv an den Client zu pushen, ist sehr mächtig.

• Wenn neue Zeilen hereinkommen, aktualisiert LiveView den Client, also muss man sie nur in die Tabelle pushen.

  • Für Business-Apps mit interaktiven Zeilen würde ich davon abraten.
  • Es kann zu kognitiver Verzögerung kommen, sodass Benutzer auf das Falsche klicken, dem falschen Kunden eine E-Mail senden oder die falsche Transaktion erstatten.
  • Eine gute UX ist es, ein Sticky-Banner zu verwenden, das mitteilt, dass sich die Daten geändert haben, oder in dringenden Fällen nur neue Zeilen hinzuzufügen, ohne die Scroll-Position zu verändern.

• In BeaconCMS verwenden wir Svelte zusammen mit LiveView.

  • Dafür gibt es gute Anwendungsfälle, wenn man die UI auf dem Client feiner steuern möchte.
  • Auch wenn man Phoenix verwendet, ist LiveView nicht immer die Antwort; manchmal ist eine statisch gerenderte Seite völlig in Ordnung.
  • Ich würde davon abraten, bei allem mit einem Alles-oder-nichts-Ansatz vorzugehen.
  • Wie im Artikel angemerkt, gibt es einige gute Anwendungsfälle dafür, vom „LiveView-Weg“ abzuweichen.
  • Wenn es eine Roundtrip-Zeit von 1000 ms gibt, kann es andere Überlegungen geben, aber geografisch verteilte Server sind aus Kostengründen usw. möglicherweise nicht nutzbar, sodass das Hinzufügen von Client-seitigem Zustandsmanagement die Lösung sein kann.

• Anstatt den Zustand auf dem Client zu verwalten, verwaltet man den Zustand sowohl auf dem Client als auch auf dem Server.

  • Es ist schwer, das als Verbesserung zu sehen; es erspart zwar den Aufbau einer weiteren API, aber das macht es nicht automatisch besser.

• Die Grenze dieses Ansatzes liegt in der Lichtgeschwindigkeit: Es gibt Grenzen dafür, wie nah der Server am Benutzer sein kann.

  • Der nächste Schritt ist, den Server nach WebAssembly zu kompilieren und an den Client zu senden, um optimistisch Antworten zu rendern, bis der echte Server zurückkehrt.
  • Das mag ein wenig verrückt klingen, aber ich habe das in einem Projekt tatsächlich erfolgreich umgesetzt, und es fühlt sich magisch an.

• Als jemand, der LiveSvelte gebaut hat: Wenn ihr Fragen habt, sagt Bescheid.

• Im Allgemeinen wollte ich Apps nach diesem Modell bauen: ereignisorientiert, bidirektionale Echtzeit-Updates und Server, geordnete Ereignisse, lokaler und entfernter Zustand ...

  • Ich kannte LiveView nicht und hatte nie eine Sprache aus der Erlang-Familie verwendet, aber sie haben da offenbar etwas entdeckt.
  • Das traditionelle Request-Response-Modell verursacht viele Probleme mit Konsistenz und veralteten Daten.
  • Ein hoffnungsvoller, aber vermutlich kontroverser Gedanke: Wenn es in den letzten 10 Jahren darum ging, FP-Konzepte in Mainstream-Sprachen zu integrieren, dann hoffe ich, dass es in den nächsten 10 Jahren darum geht, nachrichtenorientierte (reaktive?) Programmierung mit Zustand in den Mainstream des gesamten Full-Stacks zu integrieren.

• Ich verwende in Apps wiederverwendbare Stimulus-Controller zusammen mit LiveView, und auch das funktioniert reibungslos.

  • Im Allgemeinen ist das Entwickeln mit LiveView eine Freude, aber je mehr man es in realen Szenarien einsetzt, desto mehr erkennt man auch die Vorteile zustandsloser HTTP-Frameworks.
  • Frameworks wie Hotwire bieten bessere Performance und mehr Robustheit bei Wiederverbindungen und vermeiden die Notwendigkeit, Server näher beim Benutzer zu platzieren.

• Tolles Projekt! Ich habe gerade eine Svelte-Radio-Episode dazu veröffentlicht.