Just make a normal website!! You've invented an MPA with extra steps!
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.
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.
Until someone bombs your websocket server and you then have nothing at all.
What’s right with the idea, really? It’s exactly what the tried and true preferences of developers have been shown to be: getting in the way of the happy path for no reason.
Now you can have build steps and put story points in Jira and do it all on the server where we don’t have to see it, and the success condition is that the text gets served. Both sides can be happy now.
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 ?
Then you need to keep the web server inline with the web-socket. Is monitoring correct, is your web server going to be alive if the web socket server is offline?
If they both use the same source of truth why not just use the web-server which is more tried and true and much more reliable than JavaScript.
And you can actually serve a page without requiring JavaScript.
You still need something to serve the JavaScript fronted of the website so unless you create a WebSocket HTTP server which is then you're opening can of worms, you have a web-server sitting idle wasting resources.
I bombard your web socket server and now you're rendering nothing at all yet the web server is still trying to serve content.
Just do regular HTTP(2) requests. Browsers are extremely optimized for that. You don't need to invent your own transport and then manually splat a bunch of dynamic HTML on the dom.
thiagovsdiniz•42m ago