// HACKER NEWS — CYBERSECURITY

HTML over WebSockets: real-time SPAs with barely any JavaScript

Published: 08/12/2026, 04:51 PM

Building a SPA (Single-page Application) is a complex puzzle: a JavaScript framework that draws the view, an API serving JSON, and 2 independent codebases forced to understand each other through contracts. It is an accepted, professionalized scenario. But being a standard does not make it the only way. I want to show you another approach, one that is not new but has gained traction over the years: HTML over WebSockets. The idea is this: instead of sending JSON and assembling the HTML in the browser, the server sends the HTML already built and the client just places it where it belongs. All the rendering logic stays in the Back-End, in a single language, with no need for contracts or an API. This pattern is known as hypermedia or HTML over the wire. What matters about how the HTML travels is that it determines the latency and the bidirectionality of the communication. There are three variants: The channel is so important that it determines the application's architecture and its communication pattern. In this article I am going to talk about HTML over WebSockets: the real-time and bidirectional variant of the family. The one that lets you build a SPA with barely any JavaScript, in a single language, with no contracts and a single rendering engine. We will see what it is, how it works and when it pays off compared to its HTTP or SSE cousins. Chris McCord, creator of Phoenix (the most popular framework in the Elixir ecosystem), presented at ElixirConf 2019 a technology called LiveView. In just 15 minutes he built a Twitter clone that worked in real time without adding any rendering JavaScript or a popular framework (React, Angular, Vue...) to manage the View, proving that you could stay in the Back-End and be productive with a sweet hint of good performance. Since then the solution has grown popular, inspiring other developers to build HTML-over-WebSockets implementations in other languages. You can go back to the Back-End without giving up the good parts of the Front-End. Even though it might not seem so at first, JavaScript is used on the client. Its job is not to render but to create a communication channel with WebSockets and place the received HTML in the right spot. Plus other secondary tasks like animations, event handling, etc. McCord's solution is not to send the Front-End a JSON, but HTML that needs no preprocessing. That way we move the rendering load, and all its logic, to the Back-End. OK but... how do we get the server to send us new content immediately and without making a request? Easy: with WebSockets. Let's review the traditional system from the introduction. From the web I make an HTTP request, the browser starts the action and gets a JSON with all the raw information in response. The next step is to interpret it and build the corresponding HTML. With HTML over WebSockets, that same request travels over a permanent channel and the response is already assembled HTML, with no JSON in between. And since the channel never closes, the server can even get ahead and send changes without the client asking. The flow with WebSockets is now the following, ignoring the initial connection and authentication, which happen only once when the channel opens: