▲ | ossobuco 6 days ago | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I don't know, socket.io already feels like an unnecessary abstraction to me, and this is another abstraction on top of it. I generally dislike APIs that hide what's happening under "magic" abstractions, plus this seems leaky, as it abstracts on socket.io but requires you to know how it works. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | imtringued 6 days ago | parent [-] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
socket.io is probably one of the most unnecessary libraries on this planet. Websockets are already as simple as possible. In fact, websockets work so well I use them as a generic TCP replacement, because the message oriented transport model gives me 99% of what I need with the exception of custom message types. Leaving that out was a massive letdown to me, because you now need to carry a way to identify the message type inside the body, rather than just throwing the message itself into the appropriate protocol parser (e.g. a schema based binary format). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|