3 ms·
Reconsider your statement, replacing "WebSocket" with "TCP socket". Why do so many networking and messaging libraries exist when you can communicate with anoth
by neomantra 11y ago
Reconsider your statement, replacing "WebSocket" with "TCP socket". Why do so many networking and messaging libraries exist when you can communicate with another socket endpoint in a few lines of code?
This specification describes two common network design patterns (RPC, PubSub) and establishes a reusable heterogeneous framework for using them. If somebody needs those patterns, they can just pick this up and use it, and also interoperate with other clients/routers that use the same specification. Since there is this implementation-agnostic specification, client APIs and routers can be implemented within whatever language and context (embedded system, server, web browser, whatever) and they will all work together.
The WebSocket is a transport. One can put many sorts of subprotocols over it and this is one effort to make a common , useful one.
- fenesiistvan 11y agoIt takes a lot of time to implements fast/robust/scalable sockets. However this is not true with websockets. With websocket you don't have to play with various models, OS API's and threading. You just have to interpret/format the received/sent bytes as described in the RFC. Of course, you can put any app logic over websocket, but this has less to do with the websocket itself (then we enter the word of "app servers" for which we have endless other solutions if somebody favors a certain framework)