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

Elke SPA sleept een verborgen last mee. Je hebt de React-component geschreven. Maar 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 geantwoord, het error-recovery pad voor als die optimistic update fout zat, en de loading state die het gat overbrugt. De helft van de codebase bestaat alleen om twee versies van de waarheid (server, client) gelijk te houden.

Phoenix LiveView haalt die helft weg.

Wat het wegneemt

LiveView houdt per verbonden client een stateful server-side process aan. De DOM wordt op de server vergeleken, de diff gaat over de WebSocket, de client past hem toe. De client houdt geen business state bij. Er zit geen API-endpoint tussen server en view. Er is geen state library. En er is geen optimistic update, want het antwoord van de server ís de update.

In de praktijk schrap je daarmee:

• 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 het bijbehorende rollback-pad.
• De loading skeletons op routeniveau. LiveView stuurt kleine diffs, geen nieuwe pagina's.

Wat het behoudt

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

Dat is de truc: LiveView vervangt de backend niet. Het vervangt de kopie van de backend die je anders in de frontend zou bouwen. Je schrijft de auth-check één keer. Je schrijft de validatie één keer. Je schrijft geen TypeScript-spiegel van het Elixir Ecto-schema, want er is geen JSON-contract om te spiegelen.

Waar het wint

In die gevallen is het team dat LiveView oplevert half zo groot als het team dat React plus API plus state library oplevert, en is de code één codebase, geen twee.

• Admin tools en interne SaaS. Formulieren, tabellen, filters, flows met meerdere stappen. Het type 'we hadden die CRUD-app gisteren al nodig'.
• Operator-dashboards. Meerdere gebruikers, meerdere panes, live data. Hetzelfde type waarvoor we elders naar Phoenix grijpen.
• Editors waar mensen samenwerken en die geen offline-support nodig hebben. Notion-achtige producten waar elke gebruiker online is en de server de bron van waarheid is.

Waar het verliest

• Offline-first. LiveView is een stateful WebSocket; zodra je offline gaat, breekt hij. Is het product in de eerste plaats mobiel of moet het werken op een wankele verbinding, dan wil je een echte client.
• Native pariteit. Hetzelfde product op web, iOS én Android betekent dat je terug bent bij een API. Daar helpt LiveView niet bij.
• 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; die hoor je statisch te renderen.
• Teams die React nodig hebben om mensen te kunnen aannemen. Wordt de volgende ontwikkelaar een React-ontwikkelaar, dan is de LiveView-codebase voor hem of haar alleen-lezen.