Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Pretty much. In this case, WebSockets is simpler to implement than HTTP2; it's closer to raw TCP, you just send and receive raw packets... It's objectively simpler, more efficient and more flexible.

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.



I fixed a few bugs in a WebSocket client and was blown away by the things they do to trick old proxies into not screwing it all up.


I would be interested in those tricks


A big one is 'masking' all client requests that a proxy can't effectively cache the response since the request always changes.

The RFC explains it: https://datatracker.ietf.org/doc/html/rfc6455#section-5.3


Aren't websockets the only way to some sort of actual multi-core and threaded code in JavaScript, or is it still subject to the single background thread limitation and it just runs like node does?





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: