HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
phoenixframework
phoenix_live_view
Elixir2019–2024
phoenixframework / phoenix_live_view

phoenix_live_view

Rich, real-time user experiences with server-rendered HTML

38Distinct people
42Mentions
1Explicit recommenders
6.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Rich, real-time user experiences with server-rendered HTML

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

This article reads to me as more of a "Rails vs Node.js" piece, which seems almost too easy—I would be interested in a more thorough comparison of Rails versus other…

clessg used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year42 dated mentions

Observed mentions: 2019-03-14 20:59:25 UTC to 2024-12-04 04:40:34 UTC.

0510152019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 13 mentions; 1 submissions, 12 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 7 mentions; 2 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC13112
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC10010
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC505
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC505
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC725
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Phoenix LiveView Phoenix LiveView enables rich, real-time user experiences with server-rendered HTML. Visit the https://livebeats.fly.dev demo to see the kinds of applications you can build, or see a sneak peek below: Phoenix.LiveView.LiveBeats.Demo.mp4 LiveView ships by default in new Phoenix applications. After you install Elixir on your machine, you can create your first LiveView app in two steps: $ mix archive.install hex phx_new $ mix phx.new demo If you have an older existing Phoenix app and you wish to add LiveView, see the previous installation guide. Feature highlights LiveView brings a unified experience to building web applications. You no longer have to split work between client and server, across different toolings, layers, and abstractions. Instead, LiveView enriches the server with a declarative and powerful model while keeping your code closer to your data (and ultimately your source of truth): Declarative rendering: Render HTML on the server over WebSockets with a declarative model, including an optional LongPolling fallback. Rich templating language: Enjoy HEEx: a templating language that supports function components, slots, HTML validation, verified routes, and more. Diffs over the wire: Instead of sending "HTML over the wire", LiveView knows exactly which parts of your templates change, sending minimal diffs over the wire after the initial render, reducing latency and bandwidth usage. The client leverages this information and optimizes the browser with 5-10x faster updates, compared to solutions that replace whole HTML fragments. Live form validation: LiveView supports real-time form validation out of the box. Create rich user interfaces with features like uploads, nested inputs, and specialized recovery. File uploads: Real-time file uploads with progress indicators and image previews. Process your uploads on the fly or submit them to your desired cloud service. Rich integration API: Use the rich integration API to interact with the client, with phx-click, phx-focus, phx-blur, phx-submit, and phx-hook included for cases where you have to write JavaScript. Optimistic updates and transitions: Perform optimistic updates and transitions with JavaScript commands via Phoenix.LiveView.JS. Loose coupling: Reuse more code via stateful components with loosely-coupled templates, state, and event handling — a must for enterprise application development. Live navigation: Enriched links and redirects are just more ways LiveView keeps your app light and performant. Clients load the minimum amount of content needed as users navigate around your app without any compromise in user experience. Latency simulator: Emulate how slow clients will interact with your application with the latency simulator. Robust test suite: Write tests with confidence alongside Phoenix LiveView built-in testing tools. No more running a whole browser alongside your tests. Learning Check our comprehensive docs to get started. The Phoenix framework documentation also keeps a list of community resources, including books, videos, and other materials, and some include LiveView too. Also follow these announcements from the Phoenix team on LiveView for more examples and rationale: LiveBeats: Building a Social Music App With Phoenix LiveView Build a real-time Twitter clone with LiveView Build a real-time Twitch clone with LiveView and Elixir WebRTC Initial announcement Component systems When you create a new Phoenix project, it comes with a minimal component system to power Phoenix generators. In case you want to enrich your developer experience, there are several component systems provided by the community at different stages of development: Bloom: The opinionated, open-source extension to Phoenix Core Components Doggo: Headless UI components for Phoenix Petal Components: Phoenix + Live View HEEX Components PrimerLive: An implementation of GitHub's Primer Design System using Phoenix LiveView SaladUI: Phoenix Liveview component library inspired by shadcn UI Mishka Chelekom: Phoenix + LiveView UI kit and HEEx components Fluxon UI: Elegant and accessible UI components for Phoenix LiveView LiveDebugger LiveDebugger is a debugging tool built specifically for Phoenix LiveView applications. It provides a real-time view into your LiveView processes, making it easier to understand the component hierarchy, inspect assigns, trace lifecycle callbacks, and troubleshoot issues more efficiently. To get started, follow the setup instructions in the LiveDebugger repository. What makes LiveView unique? LiveView is server-centric. You no longer have to worry about managing both client and server to keep things in sync. LiveView automatically updates the client as changes happen on the server. LiveView is first rendered statically as part of regular HTTP requests, which provides quick times for "First Meaningful Paint", in addition to helping search and indexing engines. Then LiveView uses a persistent connection between client and server. This allows LiveView applications to react faster to user events, as there is less work to be done and less data to be sent compared to stateless requests that have to authenticate, decode, load, and encode data on every request. When LiveView was first announced, many developers from different backgrounds got inspired by the potential unlocked by LiveView to build rich, real-time user experiences. We believe LiveView is built on top of a solid foundation that makes LiveView hard to replicate anywhere else: LiveView is built on top of the Elixir programming language and functional programming, which provides a great model for reasoning about your code and how your LiveView changes over time. By building on top of a scalable platform, LiveView scales well vertically (from small to large instances) and horizontally (by adding more instances). This allows you to continue shipping features when more and more
Read the full README on GitHub

What Hacker News says

5 sources
I feel that the simplicity of just building on the server and pushing the updates across the wire is where we are heading. So a lot less double up, with regards needing to write both for the server and client. Validation especially will just need to be written once. Although I do feel Phoenix Liveview is a better option because they implement sockets. Also saw this update today they will allow you to trigger javascript on the client without the sever round trip, it's one of the things people get a bit stuck understanding. Generally they think to pop open a modal or menu requires a round trip to the server but really you should be using Alpine.js or similar for such things. This new pending update remove the requirement of needing a framework like Alpine. https://github.com/phoenixframework/phoenix_live_view/pull/1...
In How Laravel Livewire works
> Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view? There's an open GitHub issue on LV which mentions when using live_redirect you're paying a very large penalty in page load speeds due to extra latency being introduced by LV: https://github.com/phoenixframework/phoenix_live_view/issues... Before this issue existed my non-scientific impression was the same. There was something that felt off when using sites that primarily used LV for navigation and loading content. It always felt like I was clicking, waiting a noticeable amount of time and then the content would appear -- even with a decent ping time (< 100ms). I never experienced that type of delay when using Turbolinks and now Hotwire Turbo with comparable ping times to a server.
In Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?
But LV is still in its infancy and there are very real implications of using websockets that are unrelated to open connections. Just the other day someone posted on the Elixir forums about live_redirect causing 2 network round trip connections[0]. Basically there was double the latency to transition between pages due to this "bug". I air quoted "bug" because it's working as intended, it's just not optimal. The creator of Elixir mentioned it was doable to fix the issue but when an issue was open on GitHub[1] it was shot down with a "this is a known tradeoff, you'll need the 2nd route trip for the websocket". I'm not sure what the state of the issue is but it currently stands as closed. I've pinged 80ms to servers where LV was being used and the delay was extremely noticeable (before I even knew about this double network round trip issue).
Read the rest
It feels much worse than a Turbo Drive / Turbolinks driven site (which uses HTTP instead of websockets like LV does). In some cases LV feels slower than a regular site even with the DOM having to re-parse all of your assets. The only time LV feels like a net win to me is when you're on a local connection with 1ms of latency. I wanted to use LV a lot, but backed out because I kept running into bugs and missing features. Plus after feeling a LV site on a non-local connection I can't say that I would want to impose that experience on users. Especially folks who happen to connect from let's say Europe to the US, or even further away. The web is a global place. [0]: https://elixirforum.com/t/shortcomings-in-liveview-are-there... [1]: https://github.com/phoenixframework/phoenix_live_view/issues...
In The future of web software is HTML over WebSockets
In this case I don't see how regular functions would do. It's a way of giving a module specific behavior in a way that fits in with the application structure Phoenix enforces. That aspect of it is very Railsy, but the way it's implemented is totally different. Elixir macros are much closer to Lisp macros than Ruby macros, because they are not object oriented. I personally find them much easier to read and understand as a result. Here's __using__ in Phoenix.LiveView: https://github.com/phoenixframework/phoenix_live_view/blob/v... I think LiveView is a very compelling technology and I'm not sure we would have it if Elixir didn't exist, because Elixir brought a whole raft of different perspectives into the Erlang community. Erlang and Elixir are about as close as two languages can get, and I find complaints from either camp about the other s
Read the rest
illy. It reminds me of Python vs Ruby flame wars. Maybe it's just because I'm used to C# and F# and the way they feel in the .NET world, but Elixir and Erlang both feel like different syntaxes over the exact same underlying language concepts.
In Ten years without Elixir

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.