LiveView: the half of the SPA we stopped writing

Every SPA carries a hidden tax. You wrote the React component. You also wrote the API endpoint that feeds it, the JSON shape the endpoint returns, the client-side state library that holds it, the optimistic-update logic that pretends the server already responded, the error-recovery path when the optimistic update was wrong, and the loading state that covers the gap. Half the codebase exists to keep two copies of the truth (server, client) in sync.

Phoenix LiveView removes that half.

What it removes

LiveView keeps a stateful server-side process for each connected client. The DOM is diffed on the server, the diff is sent over WebSocket, the client applies it. The client doesn't hold business state. There is no API endpoint between server and view. There is no state library. There is no optimistic update because the server's response IS the update.

In practice that means deleting:

• The REST or GraphQL API layer between page and database.
• The JSON serializer and deserializer.
• The client-side state library (Redux, Zustand, TanStack Query).
• The optimistic-update logic and its rollback path.
• The route-level loading skeletons. LiveView ships small diffs, not new pages.

What it keeps

Server logic, database queries, auth, authorization, business rules, background jobs. Everything you'd write on a normal Phoenix backend stays. The LiveView is a thin reactive layer on top of the same Elixir functions you'd already have.

That's the trick: LiveView doesn't replace the backend. It replaces the frontend duplication of the backend. You write the auth check once. You write the validation once. You don't write a TypeScript mirror of the Elixir Ecto schema because there isn't a JSON contract to mirror.

Where it wins

For these, the team that ships LiveView is half the team that ships React + API + state library, and the code is one codebase, not two.

• Admin tools and internal SaaS. Forms, tables, filters, multi-step flows. The 'we need a CRUD app yesterday' shape.
• Operator dashboards. Multi-user, multi-pane, live data. Same shape we reach for Phoenix on elsewhere.
• Collaborative editors that don't need offline support. Notion-shaped products where every user is online and the source of truth is the server.

Where it loses

• Offline-first. LiveView is a stateful WebSocket; an offline period breaks it. If the product is mobile-first or expected to work on a flaky connection, you want a real client.
• Native parity. Same product across web + iOS + Android means you're back to an API. LiveView doesn't help.
• Public anonymous pages with high traffic. Each LiveView is a stateful process. A landing page with 100,000 anonymous visitors a day shouldn't be a LiveView; it should be statically rendered.
• Teams that need React for hiring. If the next engineer is a React engineer, the LiveView codebase is read-only to them.