LiveSvelte: Svelte State Inside Phoenix LiveView

Why LiveSvelte Links Svelte and LiveView

LiveSvelte addresses a specific division of responsibility in Phoenix applications. Phoenix LiveView updates server-rendered HTML after state changes by communicating through a WebSocket. That model works well when most interaction follows server events, but Svelte applications often keep meaningful state in the browser. A local animation, filter, selection or form interaction may not need a server request.

LiveSvelte keeps those responsibilities connected. The README describes end-to-end reactivity with LiveView, while the repository examples divide work between the layers. In `examples/advanced_chat`, Svelte handles the chat presentation and LiveView synchronizes server state. In `examples/breaking_news`, the README says item synchronization happens on the server while speed is controlled on the client.

This project is most relevant to developers who have complex local state, want to use parts of the JavaScript ecosystem, prefer Svelte animations or scoped CSS, or already favor Svelte. It is not a general-purpose Svelte package manager. It assumes that a Phoenix application already has a meaningful LiveView boundary and that maintaining both server and client state is intentional.

LiveSvelte's Client and Server Data Path

Phoenix LiveView normally sends state changes through its WebSocket and applies DOM changes without requiring hand-written client code. According to the README, LiveSvelte builds on that model while adding browser-side state management and preserving WebSocket communication.

The resulting application can express state in two places. Server-owned state can follow LiveView events and arrive through the established WebSocket path. Svelte-owned state can respond locally within the browser. The examples indicate that LiveSvelte supports this hybrid arrangement rather than requiring every visual change to originate on the server.

Server-side rendering adds a separate requirement. Node.js version 19 or later must be available in the environment that performs SSR, including production when SSR runs there. Bun may handle dependency installation and Vite execution, but the README explicitly states that production SSR still uses Node.js. SSR can be disabled by omitting `NodeJS.Supervisor` from `application.ex`, which removes that infrastructure requirement at the cost of the documented server-rendered behavior.

The public JavaScript surface also includes type declarations. `package.json` points its `types` field to `./assets/js/live_svelte/types.d.ts` and exports the TypeScript entry point separately from the import entry point. This supports type-aware client integration rather than treating Svelte as an unstructured collection of script tags.

Installing LiveSvelte with Igniter and Vite

The recommended installation path targets Phoenix 1.8 or later and Node.js 19 or later. For a new project, Igniter creates the Phoenix application, installs LiveSvelte, prepares dependencies and builds the assets. Bun can replace npm and npx for installation and Vite builds through the documented `--bun` flag.

Use these commands to create a project and start its Phoenix endpoint:

mix archive.install hex igniter_new
mix igniter.new my_app --with phx.new --install live_svelte
cd my_app
mix setup
mix phx.server

The installer configures `phoenix_vite`, Vite, `app.js`, HTML helpers, SSR, the layout and the `PhoenixVite.Components.assets` helper. The endpoint uses `PhoenixVite.Plug`, so development does not require a separate Vite terminal. Open `http://localhost:4000/svelte_demo` after the server starts to check the generated demo component.

For an existing project, Igniter must already be present in the dependencies. Add the documented dependency to `mix.exs`:

defp deps do
  [
    # ... existing deps ...
    {:igniter, "~> 0.6"}
  ]
end

After fetching that dependency, run the installer and asset commands:

mix deps.get
mix igniter.install live_svelte
mix assets.setup
mix assets.build
mix phx.server

The README says `mix setup` can perform the equivalent setup and build work. For an existing project that should use Bun, the documented installer command is `mix igniter.install live_svelte --bun`. Unlike installation with npm, this flag changes package management and Vite execution, but it does not remove Node.js from a production SSR environment.

Manual Phoenix Integration and Asset Ownership

Manual installation is intended for projects that reject Igniter or need control over each file. The documented dependency set replaces Phoenix's default esbuild dependency and adds both LiveSvelte and `phoenix_vite`:

defp deps do
  [
    # Remove: {:esbuild, ...}
    # Remove: {:tailwind, ...}  # if present
    {:live_svelte, "~> 0.18.0"},
    {:phoenix_vite, "~> 0.4"},
    # ... rest of deps
  ]
end

The application web module must import `LiveSvelte` from its quoted HTML helpers:

defp html_helpers do
  quote do
    # ...
    import LiveSvelte
    # ...
  end
end

The configuration also moves away from esbuild and Tailwind configuration blocks and introduces `phoenix_vite` plus LiveSvelte SSR configuration. This is more than adding one Elixir dependency. It changes the Phoenix asset pipeline, adds an SSR process and expects layouts and endpoints to use the `phoenix_vite` integration.

The repository contains focused examples such as `examples/simple`, `examples/store`, `examples/log_list`, `examples/animated_number` and `examples/simple_dead_view`. These are more useful starting references than the abbreviated manual configuration excerpt because they show how Svelte components and LiveViews are paired in a working example. The README does not document every manual file change in full, so a fresh Phoenix 1.8 project should not be reconstructed from dependency additions alone.

LiveSvelte Features with Practical Boundaries

The README lists SSR, `svelte-preprocess`, Tailwind support, dead view handling, slot interoperability, TypeScript declarations and a Sigil-based alternative to the LiveView DSL. These features address common friction points when Svelte is introduced into an existing Phoenix application.

TypeScript applies specifically to client assets and the exported public API. That distinction matters because the project does not claim that all Elixir code gains TypeScript typing. Slot interoperability and dead view handling are listed as capabilities, but the README excerpt does not explain their event or lifecycle semantics. Applications with delicate slot ownership should inspect the corresponding guides and examples before relying on those behaviors.

The package exposes a Vite plugin through the `./vitePlugin` export. Its main export provides both an import path and TypeScript declarations. This package layout indicates that the npm artifact contains client integration assets rather than acting as a conventional standalone Svelte component library.

One version detail deserves attention during adoption. The release history includes `v0.18.0`, while the repository's root `package.json` declares version `0.18.0-rc0`. The README does not explain whether that difference reflects separate Hex and npm release workflows. A team selecting exact versions should compare the Hex release with the published npm artifact before locking dependencies.

LiveSvelte Compared with a Separate Svelte SPA

A separate Svelte single-page application keeps its component tree, routing and state machinery on the browser, then calls server endpoints explicitly. LiveSvelte follows a different approach. It embeds Svelte behavior in Phoenix LiveView and uses the WebSocket communication already associated with LiveView for server-driven updates.

The advanced chat example makes the boundary concrete. The README describes the name-entry form as LiveView and assigns the chat experience to Svelte. That division can reduce the amount of browser code required for routine server synchronization while retaining local client state where it is useful. The breaking news example similarly places item synchronization on the server while client code controls speed.

This approach is a poor fit when the application is fundamentally a standalone SPA, does not use Phoenix LiveView or has no need for server-rendered LiveView pages. It also adds operational work: Phoenix must coordinate Vite, client assets, SSR and Node.js. A static Svelte site does not need those components and should remain within the normal Svelte build path.

LiveSvelte is not presented as a general Phoenix-to-Svelte serializer. Its value comes from deliberate LiveView integration, local Svelte state and an SSR-capable asset pipeline. Those requirements are narrower than the phrase “end-to-end reactivity” may initially suggest, but they give the project a clear boundary for Phoenix applications.

LiveSvelte's SSR and Client-Failure Boundaries

SSR is LiveSvelte's clearest source of deployment complexity. The README requires Node.js in production even if Node was otherwise present only during the build step. That can create a mismatch between a build image that contains JavaScript tooling and a smaller runtime image intended to execute the resulting server. The SSR section is explicit about this production requirement, so deploying only the compiled assets is not sufficient when SSR remains enabled.

Disabling SSR by omitting `NodeJS.Supervisor` from `application.ex` is a documented escape hatch. It does not fix other hybrid-state problems. If a Svelte component depends on server-rendered markup that is no longer generated, the application must still load and initialize its client component correctly. The README does not document a separate production health check for that condition.

The WebSocket boundary can also shape application design. LiveSvelte is appropriate when server updates are already modeled through LiveView, but it is unnecessary when each Svelte interaction should call an independent HTTP API. Trying to use LiveView for traffic that has no meaningful server-owned state adds concepts without a corresponding benefit.

These constraints do not make LiveSvelte unsuitable by themselves. They define where it fits. An application with browser-local interaction and a genuine LiveView server state can accept the additional build chain. A static page or isolated SPA generally cannot.

LiveSvelte Maintenance, License and Upgrade Work

The repository is not archived, and its last push was on 2026-10-02. Release history includes `v0.18.0` on 2026-04-17, `v0.18.0-rc0` on 2026-03-19 and `v0.16.0` on 2025-04-18. These dates confirm recent repository activity, but they do not define compatibility with every Phoenix, Vite or Svelte release.

The project is distributed under the MIT License according to the repository metadata and `package.json`. That identifies a permissive license, but applications still need to review included Svelte, Vite, Tailwind and other dependency licenses separately. No project-specific restriction is described in `LICENSE.md` beyond the stated MIT grant.

Upgrades can require more than changing one version number. The README tells existing users to inspect `CHANGELOG.md` for breaking changes. LiveSvelte also spans several toolchains: Elixir dependencies, an npm package, Vite configuration, generated Phoenix files and possibly an SSR Node.js process. An upgrade should therefore be reviewed at each boundary rather than treated as an isolated Hex dependency bump.

The upgrade cost is highest for manual installations because each modified configuration file must be compared with the current setup guide. Igniter automates much of the configuration, but existing application code can still affect generated changes. The repository includes `CHANGELOG.md`, `mix.exs`, `mix.lock`, `package.json` and `package-lock.json`, which are the concrete records to inspect before changing an installation.

Editorial conclusion

Adopt LiveSvelte when a Phoenix LiveView application has substantial local Svelte state while still needing server updates. Do not choose it for a static Svelte site or when the added Node.js, Vite, SSR and Phoenix integration is unjustified. Verify first that your Phoenix and Node.js versions meet the documented requirements, then inspect the generated Vite configuration and production asset workflow.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. woutdp/live_svelte on GitHub