LiveView Is Best with Svelte

Original Article ↗ Hacker News Discussion ↗

What LiveView + Svelte Is Aiming For

  • Use LiveView as a “backend-for-frontend” while Svelte handles richer client-side state and interactions.
  • Intended for pockets of complex UI (e.g., dropdown dependencies, chat UX, games) while keeping most of the app in standard LiveView components.
  • Big draw: access to the larger JS/Svelte component ecosystem and Svelte’s tooling (files, intellisense, prettier), which LiveView alone lacks.

When to Prefer Pure LiveView vs Svelte

  • Several people advise: start with Phoenix + LiveView; add Svelte only when client-side state becomes painful.
  • LiveView hooks or simple JS/Alpine/Stimulus are often sufficient for small enhancements; bringing in Svelte only for a trivial widget is seen as overkill.
  • Some teams report production success with LiveView + Alpine or Stimulus, keeping total JS very small.

Comparisons to Other Approaches

  • Next.js / React Server Components: some see strong overlap; others insist LiveView is distinct because of persistent server processes over websockets and BEAM’s runtime model.
  • Blazor Server, Laravel Livewire, Meteor, htmx/Hotwire, Inertia, Electric Clojure, and “full‑stack databases” are cited as similar or alternative paradigms for shared state and realtime updates.
  • Opinions split on how unique BEAM is: some argue the runtime is crucial; others point to non‑BEAM implementations as evidence the pattern generalizes.

Performance, Latency, and Offline Behavior

  • LiveView’s round‑trip latency can make UIs feel laggy over long distances or poor networks; HTTP navigation (e.g., Rails+Turbo) may feel snappier in those scenarios.
  • LiveView reconnection and state restoration are praised; offline support is absent by default but can be layered on (e.g., PWA + CRDTs or local‑first databases).
  • SSR via Heex is faster than Svelte SSR via Node; LiveSvelte’s SSR adds small overhead.

State Management and UX Concerns

  • Thread revisits core tension: state on client vs server, transient vs persistent, and complexity of keeping them in sync.
  • Optimistic updates and “prediction” patterns from games are discussed as ways to hide latency, with caveats about correctness and user confusion.
  • Realtime table row insertion is flagged as dangerous for line‑of‑business UIs; some prefer explicit “data changed, click to refresh” banners.

Critiques and Skepticism

  • Some see LiveView+Svelte as an unnecessary, messy mashup and prefer SvelteKit or plain Phoenix/LiveView.
  • Others argue that if you feel the need for Svelte with LiveView, you’re misusing LiveView; while many counter with concrete cases where richer client-side state really helps.