Responsive site built via server-side render, with a particular benefit for partial page updates. 90% of the benefit of an SPA but 10% of the code: no api, no moving of system of record for state back and forth between database and browser (it's always db), etc. And you can avoid react.

A common use case: eg in Rails, a user has a table open. you can stream new records to the top of that table as they are created in ~5 lines of ruby (a broadcast on the model, and put the table rows in a turbo_frame with a turbo_stream_from somewhere on the page).

There are real limits to this -- you have to hold the update dependency graph in your head -- but the benefits are huge for small to medium amounts of responsiveness.

My experience has been great with Rails/Turbo and htmx.

> The latency is the same because modern browsers multiplex HTTP requests over a single TCP connection that is left open.

In my experience this isn’t true; firstly you’re relying on an implementation detail of the platform that you’re executing on, of which you have no control over on the client side. Secondly, even if you aren’t opening a new connection per request, you’re still travelling through an entire HTTP stack implementation rather than the incredibly simple WebSocket protocol - effectively a length and a mask to get the contents, rather than some (in http1 land) fuzzy parser.

If you can guarantee you’re hitting http2 or http3 then you might be closer in latency, but due to the complexity of both I would imagine plain http1 negotiated persistent WebSockets provide the best latency.

> What’s wrong with this idea, really? It’s redundant because you can serve HTML to requests with Apache or Ngnix or any other server on the happy path.

Overhead, security, denial of service.

You now have two states to track. Is the web-server up to date with the version the web socket is hosting?

Is monitoring correct? Is your web server going to be alive if the web socket server is offline?

If they're going to follow both the same source of truth why not just use the web-server? Which is more tried and true, easier to cluster and much more reliable than JavaScript and you can actually serve a website without requiring JavaScript.

If corporate firewalls are blocking web sockets you are going to be rendering blank to the client because there isn't any easy way to determine if the client is blocked. How do you detect this? How do you remedy this?

You still need something to serve the JavaScript fronted of the website. Unless you create a WebSocket HTTP server which you've then opened a can of worms you have a web-server sitting idle wasting resources.

I bombard your web socket server with faux requests and take it offline. Not your web-server and now you're rendering nothing. Yet the web server is straining to serve content, how do you determine if the web socket is dead? More complexity.

It's not wrong, but a waste of time and resources and the overhead of it all just isn't worth it because you have to make alterations and tests for n+1.

Definitely a well reasoned counter point to choosing websockets over SSE.