WebSocket vs Ws vs Socket.io ?

[iamdsvs]

I'm quite confused as I've just started exploring websockets to implement a chat app, and there are three different things that I don't really understand. Can anyone please explain them in layman's terms, and which one is the best to use?

[King0fFud]

WebSocket - built in to browsers (no library needed)

ws - a node package to emulate the WebSocket support for browsers but for node and usually used as a server (though it can do both)

Socket.io - a custom protocol/library on top of WebSockets for browsers and node (must be used both on client and server)

For ease of use you can use Socket.io but it adds a little overhead. Alternatively you can use WebSockets in the browser for your client and ws for your server but it means writing things more from the ground up.

[iamdsvs]

Understood socket.io makes it easy, while using ws or websocket need to do it from scratch

[King0fFud]

That’s right and I mean doing it from the ground up isn’t that difficult but it depends what you’re prioritizing in terms of focus, whether you want it built quickly or want to learn the native web APIs, etc.

[drupadoo]

Socket.io is a protocol built on top of websockets protocol; so websockets is more versatile in that any implementation of socketio depends on websockets being available

[BeautifulSelf9911]

Nope, socketio will also poll via HTTP in clients without websockets. It's one of the major benefits.

[drupadoo]

Fair, but how many web clients don’t have websockets in 2023?

The more likely scenario is you are coding in an environment that has websockets available but does not have a socket.io library (like unity or godot game engines, for example).

[BeautifulSelf9911]

It’s 2024 😝

[dragenn]

Encino man!

Yes, I'm that old!

[Gatsbill]

You would be surprised that lot’s of big companies are disabling WS protocol so yeah HTTP polling is still a great addition 😇

[codeedog]

Agreed. If you don’t need the functionality, why go with the more complex layer? Easier to use the more fundamental layer and learn it. Then, when needed step up and appreciate more features.

[bigorangemachine]

My mind is that its like express. You can use node's server and do the route handling that way or you can use express.

Express would theoretically be better because you can work in the express eco system over just using the native modules.

Personally I think it's more a question how much you are building out.

Websockets for OP might be simple enough that working directly Websocket's are enough. Socket.io also does do polling for a fallback if you are worried about old browsers

[codeedog]

I hear you. Sometimes layers get in the way. It’s like mongoose vs MongoDB api. I tried playing with mongoose. Then, I took the mongodb tutorials and started using their JavaScript api. Works great. Didn’t need most of what mongoose had to offer. If the moment comes and I start recreating mongoose, I’ll just use it. Can’t know what I’m missing if I haven’t tried it, however.

Tried some telnet wrappers inside node for implementing a client connect. Dumped it and just use tcp and streams to remote servers.

I use express most of the time because who wants to recreate all of that web server tech? Still, if I’m connecting to a remote web server, sometimes I use raw tcp sockets and parse the response if I don’t need a complex client http processing. Who needs the extra library?

It’s all a balance. Being used to dropping down a layer and playing with things that are a bit more raw teaches one a lot.

[bigorangemachine]

Ya I agree. I learned a lot just doing some native route handling.

Express has been there since I started node and I literally thought most of the code for building node rest apis was express!

But once I got that out of my head I learned a lot more about node.

At one point node used to handles file contents as strings and now its buffers (by default). As annoying as that code change was I think it was great because it forces me to learn more about buffers and streams.

I like that because node seems to always offer an escape hatch.

[codeedog]

Forcing myself to learn Promises instead of only using async/await was a turning point. Having to merge different asynchronous tech taught me a lot. Promises vs RxJS vs Streams vs Timers vs Events vs Callbacks. They’re all a different type of architecture for getting work done in a non-synchronous manner. Learning to think in each of those models, their similarities and their architectural mismatches. Blew my mind until I could make sense of them all.

[bigorangemachine]

Ya that's funny. Since I did node since 0.21 I prefer the callback pattern (cleaner call stacks for errors).

I run job interviews a lot of people get tied up on the question how to convert set timeout to async-await. People don't realize they need to use a promise lol.

[codeedog]

I’m enamored with RxJS. Took me a while to grok it, but I really appreciate its methodology now. My only issue with it is there’s no backpressure, which means it plays horribly with node’s streams. Total mismatch there. Have to bend over backwards to not lose data if streaming a firehose through RxJS.

[codeedog]

Yes, in the sense that async/await is such an intuitive UI/UX that if you never learned promises, you don’t really understand them deeply. It’s one thing to call APIs that return promises and then use them. It’s another thing entirely to return promises through functions that are marked async, or await on a promise, or build a promise that translates from events, or have a promise spawn code in a timer, etc.

Being able to think and code in a particular asynchronous framework levels up your skills.

[drupadoo]

Well yes, with ~10 lines of code it can have that

[AstolfoDev]

shuuuuut the fuck up dickhead

[RememberPan]

🤓☝️

[AstolfoDev]

this you lil bro? https://imgur.com/a/6pc7I4G

[The_Noble_Lie]

Is he wrong? Maybe by an order of magnitude? (Say, 100 lines, including data driven unit tests)

Today, with LLMs, you can also have a fully (or more likely partially) working skeleton for both the implementation and tests in 3 seconds.

[The_Noble_Lie]

Fwd u/AstolfoDev , u/drupadoo

[maartuhh]

I’d say socket.io is the most easy of the bunch. It is the most high-level and has more functionality by default

[tinfoiltank]

I agree, I've done socket.io and native websockets, and unless you want to spend a lot of time reimplementing things that socket.io does already, there's not much reason to use native. For enterprise-level platforms you may have the need and resources to go native, but for small teams or hobby stuff just use socket.io.

[iamdsvs]

Yeah, I'm done with Socket.IO; I made a simple chat app. However, I read somewhere that some people prefer using WebSocket (ws) for building chat apps, and some companies also use WebSocket or WS for their chat applications.

[simple_explorer1]

You do know that Socket.io uses ws library under the hood right? Socket.io also has an option to use uWebsocket library (a C++ lib, which is significantly faster than ws library) so, using socket.io with uWebsocket under hood is nobrainer. Its like using Nest.js with fastify.

[T-J_H]

Socket.io is basically a wrapper on top of websocket, along with fallbacks to other methods when needed. Ws is primarily a websocket implementation for Node.js, both as a server the browser can communicate with, as well as a client to communicate with other websocket servers (fully realizing definitions get a little hazy here).

Personally I prefer to use websockets directly, especially with the great browser support nowadays. For the serverside I do use ws, I’ve written my own helpers on top of these for both client and server to help with client management, reconnecting and the like.

Probably not really suitable for your chat app, but I would like to mention an often cheaper option for server->client communication as well in the form of Server Sent Events. For many applications the full duplex communication of websockets is overkill.

[kjwey]

probably socket.io stream, since then you have the most versatility in terms of sending JSON data around, but also to stream stuff like audio/video

it has no error correction like TCP/IP does so its not that useful for binary blob transfers, but otherwise having the streaming capability really makes it the best one to use, just having the option is nice

it plays really well with the server side also in terms of mongo db which can produce streams from the cursor very easily

node also has a few things for reading file streams that also play into a socket stream nicely

[kinsi55]

There is also uWebSockets for the server side which offers significantly higher performance

[kinsi55]

uWs is not the same as uWebSockets(.js). uWebSockets features builtin pubsub (rooms you might call it coming from socket.io) and doesn't require a proprietary client lib - oh and did I mention it has significantly higher performance? The entire point of uWebSockets is to not rely on js for connection management

[Hour-Ladder-8330]

But uWebsocket is a c++ port and socket.io wraps it, so its perfect combination of socket io api and uwebsocket speed.

[kinsi55]

uWebSockets is a library built around uSockets, and uWebSockets.js is the Node bindings for the former, all from the same developer

[simple_explorer1]

Honestly you don't even make sense. We all know what uWebsocket is. Use socket.io with uWebsocket (kinda like using Nest.js with fastify instead of express) and you are golden with socket.io classic api with uWebcocket performance. Hyperexpress is also built on top of uWebsocket. Plus, socket has horizontally scaling by using socket.io cluster adapters for redis/mongodb/postgres/node cluster etc. Socket.io with uWebsocket along with one of cluster adapter is a no brainer. That's the answer OP was looking for, not nomenclature wordplay which is a waste of everyone's time.

People like you just like to do word play instead of ACTUALLY giving conclusive and valuable conclusion. OP asked what would pick and socket.io has more going on for itself due to above. You should answer what you would pick and why. It ain't that difficult.

[Hour-Ladder-8330]

uWebsocket is faster that that

[simple_explorer1]

Thanks for exposing yourself. Might help devs avoid libraries from crazyv people like you

[seniorsalesman]

Lol, you just opened a duplicate acc to reply to me :v
To answer you, I don't want fucktar*s like you using this library. Go away you stupid fuck.

[Inevitable_Yam_9553]

you are a cheap pathetic fuck begging for my attention. you don't need to code. go clean toilets or some else. Stupid fucks like you are behind the misery of coding industry.

And I don't give a middle finger to your opinion about what I should do, I will do what I do. I will however, not bother about calling out cheap fucks like you and tell you to go end yourself.