HTML over WebSockets: Build Real-Time SPAs with Barely Any JavaScript
HTML over WebSockets: real-time SPAs with barely any JavaScript
The article explores HTML over WebSockets, a pattern for building real-time SPAs with minimal JavaScript by sending pre-rendered HTML from the server. It contrasts this with traditional JSON APIs and compares it to HTTP and SSE variants. The author details advantages like single rendering engine, no API needed, server-side state, and real-time broadcast, while acknowledging drawbacks like resource usage and offline limitations. It includes a landscape of frameworks such as Phoenix LiveView, Django LiveView, and Hotwire, and offers guidance on choosing the right transport.
The same architecture that makes a chat trivial makes it immune to XSS.
- hackingonempty
> The quick rule: if you need bidirectional, low-latency communication (chat, collaboration, games), WebSocket; if you only push from the server, SSE is simpler and cheaper to operate.
For most apps just use SSE and the built-in code for making HTTP requests (Fetch) instead of hacking up your own client side JS to make requests over a WebSocket. The latency is the same because modern browsers multiplex HTTP requests over a single TCP connection that is left open.
Maybe if you are making many client requests per second there is an advantage to not sending full headers/cookies/etc... on each request but not if you're sending requests in response to user clicks/touches.
Any sufficiently complicated SPA contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Fetch.
- xutopia
Funny he mentioned Chris McCord as the originator of this technique with Liveview. The reality however predates that with Sync in Rails that you guessed it... was also Chris McCord's doing. Rails at the time didn't have the capacity to handle it so it was just a tech demo then and a big reason why Chris McCord moved to Phoenix. He was once a prolific Rails developer. That guy is helping the web move forward.
- nchmy
A good response to this post
- gwbas1c
A lot of the people who oppose this technique don't understand context: The right solution to your problem often involves understanding the problem you're trying to solve!
In my case, I work on two Blazor websites: One is standard in-browser WASM with Restful JSON (and some CSV) over http; the other is server-side Blazor that uses the websocket technique that this article describes.
The server-side Blazor approach is for an internal web application that has a lot of quick-and-dirty pages that replace what used to be ad-hoc database queries and ad-hoc scripts. It's not an "industrial strength" web application that requires high scalability, because it's only a handful of employees who use it. It's also a joy to work with. To be specific, we don't need to go through the exercise of designing an API, making sure that contracts serialize, ect, ect, just to slap a UI around what used to be a script.
The WASM page that uses Restful JSON (and csv) is our customer-facing web application: JSON (and CSV) help with debugging; but the cost of making an API is very high. Development on the customer-facing web site moves much more slowly, but it's "worth it" for an industrial-strength site.
Would I build a highly scalable website using HTML over a websocket? Maybe. The issue is time to market: Because you don't have to build an API, you can move faster; but I don't know if scalability issues will arise.
- nzoschke
Close but htmx with SSE and dom swaps and morphing gets you there without reinventing any wheels.
Pretty much every web app I build has this pattern in it from day 1, as they all quickly expand to have a realtime inbox and notifications subsystem to support workflows and agents.
- deepsun
> Place the HTML where it belongs
Well, some drawbacks are not accounted for when replacing HTML parts: input elements lose focus, if some view was scrolled, then it gets unscrolled, jumping under user's pointer etc.
- pjmlp
Love how DHTML, ASP.NET Ajax, JSF Ajax kind of keeps being re-invented.
- zemnmez
>Safer against injection: since the server renders and escapes the HTML before sending it over the channel, an attempt to sneak in a <script> travels as inert text and reaches your neighbor's screen as plain letters, not as code. The same architecture that makes a chat trivial makes it immune to XSS.
I strongly disagree with this point, and in general I've seen the reverse is true. Only the client truly knows how it will interpret especially esoteric kinds of html tags and relying on the server for sanitisation is relying on the system furthest from the authoritative renderer.