# Phoenix LiveView: server-rendered HTML with persistent connections

> Phoenix LiveView keeps application state on the server and sends minimal diffs over a WebSocket after the first HTTP render. It suits Elixir teams that want interactivity without a separate client codebase, and it is the wrong tool when the browser has to work offline.

**phoenixframework/phoenix_live_view** — Rich, real-time user experiences with server-rendered HTML

- Repository: https://github.com/phoenixframework/phoenix_live_view
- Website: https://hex.pm/packages/phoenix_live_view
- Stars: 6,826 · Forks: 1,053
- Language: Elixir
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/phoenixframework-phoenix-live-view

## The split between client and server that LiveView removes

Most interactive web stacks ask you to write the same feature twice: once as server code that produces HTML, and again as client code that keeps a DOM in sync with it. Phoenix LiveView's answer is to keep the stateful part on the server and let the browser hold a connection open. The README states the goal plainly: "You no longer have to worry about managing both client and server to keep things in sync." The audience is Elixir teams. If your application is not written in Elixir, the package is not available to you, because the server half is an Elixir library and the client half is a JavaScript file that expects the server's protocol.

The second audience is narrower and worth naming. Teams that already accept a persistent connection per user, such as internal dashboards, admin panels, chat, and live-updating lists, get the most from the model. Teams building a public site that must render instantly on a cold cache, or an app that has to keep working when the network drops, are pushing against the design rather than with it.

## How the diff protocol and HEEx rendering fit together

The mechanism has two phases. First, the page is rendered as ordinary HTML during a regular HTTP request. The README notes this gives quick times for "First Meaningful Paint" and helps search and indexing engines, which is the part that matters if you care about crawlers. Then the client opens a persistent connection, and from that point the server pushes changes rather than the browser asking for them.

What travels over that connection is not a fresh HTML fragment. LiveView tracks which parts of a template changed and sends a diff. The README describes the client as optimizing the browser with "5-10x faster updates, compared to solutions that replace whole HTML fragments." That is the project's own claim, not an independent measurement, and it is the kind of number you should re-derive against your own templates before repeating it.

The template layer is HEEx, described in the README as supporting function components, slots, HTML validation, and verified routes. On the client side, the integration API is a set of attributes: `phx-click`, `phx-focus`, `phx-blur`, `phx-submit`, and `phx-hook` for the cases where you do have to write JavaScript. `Phoenix.LiveView.JS` covers optimistic updates and transitions. The repository layout matches this split: `lib/` holds the Elixir side, `assets/` holds the TypeScript client, and `priv/static/` holds the built JavaScript that `package.json` points at through its `module`, `main`, and `unpkg` fields.

## Installing Phoenix LiveView and rendering a first page

The README's fastest path is to let Phoenix generate the project, because LiveView ships by default in new Phoenix applications. After installing Elixir, the README gives two commands. The first installs the Phoenix project generator from Hex; the second creates an application named `demo`.

```bash
mix archive.install hex phx_new
mix phx.new demo
```

What you should see is a new `demo/` directory containing a Phoenix project with LiveView already wired in. You do not add `phoenix_live_view` to `mix.exs` yourself on this path, and the README does not ask you to.

The case the README treats separately is an older existing Phoenix app. It points to the previous installation guide for adding LiveView manually, and that guide is pinned to an older tag rather than to `main`. That distinction matters: the current README documents the generated-project path, and the manual path lives in a versioned document you should match to your Phoenix version.

For a first real use, the project points at LiveBeats, a demo application at `livebeats.fly.dev`, as an example of the kind of application you can build. The README also links a walkthrough for a real-time Twitter clone and a Twitch clone built with LiveView and Elixir WebRTC. Those are the concrete starting points the project itself offers; the README does not include a step-by-step first-LiveView tutorial in the text.

## Where the server-centric model costs you

Every user with an open page holds a server-side process and a connection. That is the direct consequence of the design, and it is the constraint to plan around. The README describes a persistent connection between client and server and names LongPolling as an "optional" fallback, which tells you the primary transport is a WebSocket. Anything in your deployment path that terminates idle connections, buffers responses, or does not support upgrades becomes your problem, and the README does not walk through proxy configuration.

The second limitation is that the client is thin by design. The README frames JavaScript as the exception, reached through `phx-hook` for "cases where you have to write JavaScript." If your feature depends on heavy client-side computation, offline storage, or a large existing JavaScript component library, you are working against the grain. The README lists community component systems such as Bloom, Doggo, Petal Components, PrimerLive, SaladUI, Mishka Chelekom, and Fluxon UI, and it is explicit that these are "at different stages of development." That phrasing is the project's own, and it means you should evaluate each one's maturity yourself rather than assuming parity with the core.

Finally, the README does not document rollback behavior for a failed upgrade, and it does not document capacity planning. Neither is a defect in a README, but both are things you will have to answer from the changelog and your own load testing.

## How LiveView differs from a client-rendered SPA

The obvious alternative is a client-rendered single-page application, where the browser holds the state and the server exposes an API. The difference is not stylistic. In an SPA the network boundary is the API, so every interaction is a request you design, and the client owns rendering, routing, and cache invalidation. In LiveView the network boundary is a diff stream, and the server owns rendering and state.

That flips the failure modes. An SPA degrades into a broken client when the API changes; a LiveView app degrades into a disconnected page when the socket drops, and the README points to "specialized recovery" for form bindings following crashes or disconnects. An SPA scales by serving static assets from a CDN and keeping the API mostly stateless; LiveView scales by holding a process per connected user, which is a different capacity curve and a different cost model. Neither is universally cheaper. If your application is mostly read-only content with a few interactive islands, the server-centric model asks you to pay for connections you do not need.

## Maintenance, licence, and what upgrading actually involves

The repository is not archived, and the last push was on 2026-09-17, five days before this writing. Recent releases are v1.2.12 on 2026-09-16, v1.2.11 on 2026-08-27, and v1.2.10 on 2026-08-20, so releases are arriving on a short cadence. The `package.json` in the repository declares version `1.3.0-dev`, which means the JavaScript client on `main` is ahead of the latest published release. If you install from Hex you get a released version; if you build the client from the repository you get development code. Those are not the same thing, and the README does not describe a supported path for mixing them.

Both halves are MIT licensed: the repository carries `LICENSE.md`, and `package.json` declares `"license": "MIT"`. MIT is permissive, but this is not legal advice, and if you redistribute the built client from `priv/static/` you should read the licence text rather than a summary.

Upgrade cost is dominated by the template layer. HEEx does HTML validation, so markup that was tolerated before a change can fail after it. The repository keeps a `CHANGELOG.md`, and that is where the project records what changed between v1.2.10 and v1.2.12; the README does not summarize breaking changes, so the changelog is the file to read before bumping the dependency.

## Conclusion

Adopt Phoenix LiveView if your team already writes Elixir and your interactive screens can live behind a persistent WebSocket connection; skip it if you need a client that keeps working offline or a JavaScript ecosystem your team already knows. Before committing, verify two things in your own environment: that `mix phx.new demo` produces a working LiveView page on your Elixir version, and that your deployment holds long-lived connections open, since the README's fallback is LongPolling and nothing else. The installation guide for adding LiveView to an existing app is versioned separately from the current README, so check which guide matches your Phoenix version before you start editing mix.exs.

## FAQ

### What is Phoenix LiveView?

It is an Elixir library for building rich, real-time user experiences with server-rendered HTML, using a persistent connection between client and server. It ships by default in new Phoenix applications and uses the HEEx templating language.

### How does Phoenix LiveView work?

The page is first rendered statically as part of a regular HTTP request, then the client opens a persistent connection. After the initial render, LiveView sends minimal diffs over the wire instead of replacing whole HTML fragments.

### What is LiveView in Phoenix?

LiveView is the part of the Phoenix stack that enriches the server with a declarative model and updates the client automatically as changes happen on the server. The README describes it as server-centric, so you do not manage client and server state separately.

### Where can I see a Phoenix LiveView demo?

The README points to a demo at livebeats.fly.dev, described as showing the kinds of applications you can build. It also links a walkthrough for a real-time Twitter clone and a Twitch clone built with LiveView and Elixir WebRTC.

### Does Phoenix LiveView support drag and drop?

The README does not mention drag and drop. It lists phx-click, phx-focus, phx-blur, phx-submit, and phx-hook as the client integration API, and phx-hook is the documented route for cases where you have to write JavaScript.

## Sources

- [License: MIT](https://github.com/phoenixframework/phoenix_live_view/blob/main/LICENSE)
- [phoenixframework/phoenix_live_view on GitHub](https://github.com/phoenixframework/phoenix_live_view)
- [Project website](https://hex.pm/packages/phoenix_live_view)
- [README](https://github.com/phoenixframework/phoenix_live_view/blob/main/README.md)
- [Releases](https://github.com/phoenixframework/phoenix_live_view/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/phoenixframework-phoenix-live-view