LiveView: de helft van de SPA die we stopten met schrijven

Elke SPA draagt een verborgen belasting. Je hebt de React-component geschreven. Je hebt ook het API-endpoint geschreven dat hem voedt, de JSON-vorm die het endpoint teruggeeft, de client-side state library die hem vasthoudt, de optimistic-update logica die doet alsof de server al heeft gereageerd, het error-recovery pad voor als die optimistic update fout zat, en de loading state die het gat afdekt. De helft van de codebase bestaat om twee versies van de waarheid (server, client) in sync te houden.

Phoenix LiveView haalt die helft weg.

Wat het wegneemt

LiveView houdt een stateful server-side process per verbonden client. De DOM wordt op de server gediff'd, de diff gaat over WebSocket, de client past het toe. De client houdt geen business state. Er is geen API-endpoint tussen server en view. Er is geen state library. Er is geen optimistic update omdat het antwoord van de server DE update is.

In de praktijk betekent dat schrappen:

• De REST- of GraphQL-API-laag tussen pagina en database.
• De JSON-serializer en deserializer.
• De client-side state library (Redux, Zustand, TanStack Query).
• De optimistic-update logica en zijn rollback-pad.
• De route-level loading skeletons. LiveView verstuurt kleine diffs, geen nieuwe pagina's.

Wat het behoudt

Server-logica, database queries, auth, autorisatie, business rules, background jobs. Alles wat je op een normale Phoenix-backend zou schrijven blijft. De LiveView is een dunne reactieve laag bovenop dezelfde Elixir-functies die je al zou hebben.

Dat is de truc: LiveView vervangt de backend niet. Het vervangt de frontend-duplicatie van de backend. Je schrijft de auth-check één keer. Je schrijft de validatie één keer. Je schrijft geen TypeScript-spiegel van het Elixir Ecto-schema omdat er geen JSON-contract is om te spiegelen.

Waar het wint

Voor deze gevallen is het team dat LiveView levert de helft van het team dat React + API + state library levert, en is de code één codebase, geen twee.

• Admin tools en interne SaaS. Formulieren, tabellen, filters, multi-step flows. De 'we hebben gisteren al een CRUD-app nodig' vorm.
• Operator-dashboards. Multi-user, multi-pane, live data. Dezelfde vorm waarvoor we elders naar Phoenix grijpen.
• Collaboratieve editors die geen offline-support nodig hebben. Notion-vormige producten waar elke gebruiker online is en de bron van waarheid de server is.

Waar het verliest

• Offline-first. LiveView is een stateful WebSocket; een offline-periode breekt hem. Is het product mobile-first of moet het werken op een wankele verbinding, dan wil je een echte client.
• Native pariteit. Hetzelfde product over web + iOS + Android betekent dat je terug bent bij een API. LiveView helpt niet.
• Publieke anonieme pagina's met veel verkeer. Elke LiveView is een stateful process. Een landing page met 100.000 anonieme bezoekers per dag hoort geen LiveView te zijn, hij hoort statisch gerenderd te worden.
• Teams die React nodig hebben voor hiring. Wordt de volgende engineer een React engineer, dan is de LiveView-codebase voor hen alleen-lezen.