GoKawiilBuilding 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:
Over HTTP , request by request, like htmx or Unicorn.
, request by request, like htmx or Unicorn. Over SSE , opening a one-way, continuous channel from server to client, like Datastar.
, opening a one-way, continuous channel from server to client, like Datastar. Over WebSockets, a permanent, bidirectional channel, like Phoenix LiveView or Django LiveView.
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.
Origin
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.
How does it work?
... continue reading