There's a growing realization that you can completely side-step the need for Single-Page App frameworks like React using websockets and the morphdom library.
Projects like StimulusReflex (Rails) and LiveView (Phoenix) allow developers to build complex, reactive modern apps faster and easier by rejecting the need to even have client state.
https://github.com/hopsoft/stimulus_reflex
https://github.com/phoenixframework/phoenix_live_view
I haven't been this excited for a web technology since Rails came out.
In Ask HN: What's the most valuable thing you can learn in an hour?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
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, 2:17:07 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.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 13 | 1 | 12 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
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 GitHubWhat Hacker News says
13 sourcesI wouldn't say Elixir has more concepts, it is rather different concepts.
You also don't have to worry about performance and concurrency. I would actually argue that you have to worry less about performance and concurrency because you can go further without having to resort to cache layers, tuning, etc.
But ultimately, I don't disagree with you. If you are building CRUD apps, then any technology is likely fine. Perhaps there is a chance Phoenix will start to take a bigger pie of the "CRUD apps space" with LiveView (https://github.com/phoenixframework/phoenix_live_view). If you could produce CRUD apps at the pace you do today, but making them interactive and realtime is orders of magnitude simpler, would that interest you?
In An Interview with Jose Valim, Creator of ElixirI think most people today would use a web front-end to Erlang/Elixir, with events over websockets (cowboy), using WebGL in the browser, with either server-side rendering (Phoenix LiveView) or client-side JS integration (pick your poison).
https://github.com/phoenixframework/phoenix_live_view
These ideas were first proposed by ... joearms, of course, way back in 2009.
https://armstrongonsoftware.blogspot.com/2009/12/comet-is-de...
RIP Joe
In WxErlang: Getting_started [pdf]>First, in my opinion distributed BEAM is mostly intended to run on a network which is fast and more reliable (such as local network). While in theory it can also work on a less reliable/slower network (e.g. geographically dispersed machines connected via Internet), in practice you might experience more frequent netsplits which could cause various problems, such as worse performance or less consistency.
This is exactly why I wasn't excited about LiveView[1]. It felt like a step backwards in terms of human-centric design. Another tool that makes us consider our network bars first and our life second.
In general, I'm kind of disappointed that Elixir isn't leading the way on decentralized and offline-first technology, but I guess it's a limitation of BEAM running on small/low-powered devices?
[1]: https://github.com/phoenixframework/phoenix_
Read the rest
A little off-topic, but one of the most exciting things in my mind about Phoenix LiveView [1] is that you can get some dynamic web applications and not have to navigate this JS-rendering minefield. When a LiveView page is request, the server sends over the full page as just static HTML. The JS half of LiveView then upgrades to a websocket connection, and your page becomes dynamic.
Not a good fit for everything, but it's great if you want to add some fancy form validation to, say, your landing page. You can render whatever you want with LiveView, get your fancy dynamic stuff, without having to worry about making your page more indexable.
[1]: https://github.com/phoenixframework/phoenix_live_view
In Understand the JavaScript SEO basicsAnother lightweight contender, not WASM though, is Phoenix Live View[1]
[1] https://github.com/phoenixframework/phoenix_live_view
In Show HN: Sauron – A web framework in Rust that adheres to the Elm architecturePhoenix Live View[1] fits the gap between server rendered HTML pages and JavaScript rendered front-ends. If you’re after a responsive web UI without needing to learn so many disparate frameworks and technologies it could be a good fit.
[1] https://github.com/phoenixframework/phoenix_live_view
In Elixir, Phoenix, Absinthe, GraphQL, React, and ApolloIf you think along these lines but also want some nice realtime interactivity check out the recently released Phoenix Live View which is a very clever system that allows you to push changes automatically to your client based on server rendered template diffing: https://github.com/phoenixframework/phoenix_live_view
In Building a front end with no JavaScriptEspecially now, with the beta release of https://github.com/phoenixframework/phoenix_live_view
one can be productive writing interactive applications right off the bat. Rails developers should check this out.
I'm stoked about the potential of live view and I'm curating a list of demos of things built with it:
https://tefter.io/zorbash/lists/phoenix-liveview-examples
It took me a couple of hours to build my first demo with it, have a look: https://youtu.be/tTPH4DyUaUk
and I didn't have to write any JavaScript for it.
In I Miss RailsObligatory plug for Phoenix LiveView: https://github.com/phoenixframework/phoenix_live_view
edit: This actually has examples https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
In Ask HN: What happened to server-side rendering?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 frameworks. Here I will attempt a comparison, limited in length as this isn't a blog. :)
My personal favorite up-and-coming framework (and admittedly, my favorite web framework overall) is Phoenix[1], written in Elixir[2], a functional programming language with a focus on concurrency, performance, and developer productivity. In my opinion, Phoenix has almost all of the best parts of Rails without nearly as many of the warts, and adds a plethora of compelling features of its own.
Despite what the author argues, I believe that raw performance and developer performance are equally important, and even intertwined. Why? A slow application results in lost customers and revenue, a f
Read the rest
act that is well-documented. A default Rails application is going to be quite slow, requiring intervention. Of course, most larger Rails apps are not necessarily slow in practice—in my experience, this is largely because the code is littered with brittle caching logic and hacks requiring many human-hours to maintain and debug when things go wrong. Thankfully, Ruby is seeing improvement in the performance realm.
Phoenix achieves massive scalability, raw performance, and developer performance, without requiring significant trade-offs and caching logic littered all over your code. It is an absolute joy to write Elixir. Phoenix is famous for consistently achieving microsecond response times without caching, and being capable of holding millions of websocket connections[3]. Granted, Elixir as a language is not computationally fast, but the typical web app is not performing expensive computations, but instead juggling IO, which Elixir handles extremely well. CPU-intensive tasks can be written in a different language if need be.
Importantly, Phoenix is not your application—Phoenix's job is to provide a web interface into your broader Elixir application. Thus, Phoenix is more of a toolkit than a framework, and yet it provides everything you would expect in any web framework, with strong conventions based on the solid foundation of Elixir. You could migrate to a different framework with relative ease. You can easily integrate different interfaces into your application, such as a CLI frontend. This is in contrast to Rails, where Rails is your application unless you actively fight against the framework.
Ruby and Rails are notoriously bad at handling concurrency and real-time features using e.g. websockets. This becomes progressively painful as using all CPU cores becomes increasingly necessary, and as websockets continue their ascension on the web & mobile. In contrast, concurrency and soft real-time communication are Elixir & Phoenix's bread-and-butter.
As I mentioned, Phoenix brings compelling features of its own. The most interesting to me is the upcoming Phoenix Live View[4], which will allow developers to write rich, interactive, real-time applications without being forced to wade into JavaScript hell. Read the linked article for more information. I could be wrong, but I don't see something like Live View making its way into Rails, especially without significant downsides.
One area where Ruby & Rails trounce Elixir & Phoenix is maturity. Although they have gained significant traction, Elixir & Phoenix are still comparatively immature. Thus, you'll have a harder time hiring, finding third-party libraries, and answers to questions. That said, Elixir is based on Erlang, which is extensively battle-tested and has a huge assortment of libraries available. (You can very easily and naturally use Erlang code in Elixir.)
I could go on, but I think this has gotten long enough.
[1] https://phoenixframework.org
[2] https://elixir-lang.org/
[3] https://phoenixframework.org/blog/the-road-to-2-million-webs...
[4] https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera... (Repo: https://github.com/phoenixframework/phoenix_live_view)
On GitHub: https://github.com/phoenixframework/phoenix_live_view
The previous HN discussion at the time it was initially announced: https://news.ycombinator.com/item?id=18662585
In Phoenix.LiveView is now public on GitHub