The post pitches a server-driven way to build "single-page" apps without a big frontend framework. Instead of shipping a lot of JavaScript and talking to a JSON API, the server keeps state, renders HTML fragments, and pushes them over a WebSocket so the browser can swap them into the page. The appeal is obvious: one source of truth, less frontend code, and real-time updates without building a separate client app.
Most of the useful reaction was not "this is impossible". It was "we already know this pattern, and the transport choice is the weak part of the argument." A lot of people recognized this as the same family as Phoenix
LiveView, Rails
Turbo,
Hotwire,
htmx, Livewire, Symfony Live Components, old Ajax-era partial rendering, and even earlier server-driven UI ideas. That made the discussion less about novelty and more about tradeoffs. The consensus landing point was that server-rendered HTML updates are often a good fit for internal tools,
CRUD-heavy apps, admin surfaces, notifications, and moderate real-time features. They cut API surface area, keep state on the server, and let small teams move fast.
Where people pushed back hard was the claim that WebSockets are the obvious wire format. Many argued that if the server mostly pushes updates and the client still uses normal HTTP requests for user actions, Server-Sent Events gives you the same architectural benefit with fewer operational surprises. Browser reconnection behavior, HTTP-native tooling, and simpler deployment kept coming up. Several commenters also said the article overclaimed on performance, because modern
HTTP/2 and
HTTP/3 narrow the latency gap for many normal interactions, and caching often matters more than shaving protocol overhead. The sharper criticism was that custom WebSocket request handling tends to rebuild chunks of HTTP and browser behavior badly.
People also drew a practical boundary around where this style breaks down. Once a page has many tightly coupled reactive elements, rich client-side state, or offline and caching needs, the "
DOM as output of server templates" model can turn into scattered update logic and fragile partial swaps. At that point, data-first frontend models like Vue, React, or Svelte still make more sense. There was also skepticism toward claims that server-rendered HTML is inherently safer against injection, since the browser remains the final interpreter and sanitization mistakes do not disappear just because rendering starts on the server.
The overall picture is that HTML-over-the-wire has clearly graduated from fringe trick to established technique. What did not land was the attempt to present raw WebSockets as the default way to do it. The more grounded takeaway was to pick the simplest transport that matches the app’s interaction pattern, and to lean on mature libraries instead of rolling your own protocol and swap logic.
en.andros.dev