For example, making a sandwich: You have to retrieve exactly two slices of bread after finding the loaf in the fridge. Apply butter uniformly after finding the appropriate knife, be sure to apply about a 2.1mm level of coating. After all of that you will still need to ensure you've calibrated the toaster!"
Also, their alternative is just a library. It's not like they're selling a SaaS, so we shouldn't be mean spirited.
Am I on the right website? checks URL
People find anything to be mean about on here.
It's a tough sell to convince me that a protocol which was designed primarily for resource transfer via a strict, stateless request-response mode of interaction, with server push tacked on top as an afterthought is simpler than something which was built from the ground up to be bidirectional.
The RFC explains it: https://datatracker.ietf.org/doc/html/rfc6455#section-5.3
To me the sticking point is what if the "response" message never comes? There's nothing in the websocket protocol that dictates that messages need to be acknowledged. With request/response the client knows how to handle that case natively
> And the websocket browser API is nicer to work with than, say, EventSource.
What in particular would you say?
Kind of like how you also need to implement app-layer ping/pong over websockets for keepalive even though tcp already sends its own ping/pong. -_-
As for EventSource, I don't remember exactly, something always comes up. That said, you could say the same for websockets since even implementing non-buggy reconn/backaway logic is annoying.
I'll admit, time for me to try the thing you pitch in the article.
Ref: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
This article conflates a lot of different topics. If your WebSocket connection can be easily replaced with SSE+POST requests, then yeah you don’t need WebSockets. That doesn’t mean there aren’t a ton of very valid use cases (games, anything with real time two-way interactivity).
No need for WebSockets there as well. Check out WebTransport.
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
That's a pretty convincing use-case. Why use something standard if it can be non-standard custom instead!
Isn't WebTransport basically WebSockets reimplemented in HTTP/3? What point where you trying to make?
No.
Thanks for your insight.
It seems you need to urgently reach out to the people working on WebTransport. You seem to know better and their documentation contradicts and refutes your assertion.
If you take some time to learn about WebTransport, you will eventually notice that if you remove HTTP/3 from if you remove each and every single feature that WebTransport touts as changes/improvements over WebSockets.
What the author and similar web developers consider complex, awkward or difficult gives me pause. The best case scenario is that we've democratized programming to a point where it is no longer limited to people with highly algorithmic/stateful brains. Which would be a good thing. The worst case scenario is that the software engineering discipline has lost something in terms of rigor.
The real problem with the software engineering discipline is that we are too easily distracted from solving the actual business problem by pointless architecture astronautics. At best because of boredom associated with most business problems being uninteresting, at worst to maliciously increase billable hours.
There are two pervasive themes in software engineering:
- those who do not understand the problem domain complaining that systems are too complex.
- those who understand the problem domain arguing that the system needs to be refactored to shed crude unmaintainable hacks and further support requirements it doesn't support elegantly.
Your comment is in step 1.
And Twitter is just a message board.
Those who do not understand the problem domain complain that systems are too complex.
...and yes, the stack overflow in the JS version was trivially fixable and then the JS version worked pretty well.
There's even a whole spec for that: JSON-RPC, and it's quite popular.
It's pretty much always worth it to have an API like `send(message).then(res => ...)` in a serious app.
But I agree. The upgrade request is confusing, and it's annoying how your websocket server is this embedded thing running inside your http server that never integrates cleanly.
Like instead of just reusing your middleware that reads headers['authorization'] from the websocket request, you access this weird `connectionParams` object that you pretend are request headers, heh.
But the idiosyncrasies aren't that big of a deal. And the websocket browser API is nicer to work with than, say, EventSource.