Is socket.io redundant?

Ask coding questions

Is socket.io redundant?

What are the benefits to using socket.io over plain websockets for example? socket.io is 3x slower, the packet sizes are a lot bigger, and in my opinion the library doesn't offer any more functionality.

Despite being able to send messages to all clients without needing to store them in an array, what is socket.io used for?

Voters

Comments

hot new top

It seems like Replers prefer Socket.io either because it's easier, or they have no clue how to use a WebSocket, so if you already know how to use an actual WebSocket, then I personally recommend using actual WebSockets.

Note: socket.io does not always use WebSockets, instead it starts by using long polling, and may upgrade to something similar to the WebSocket protocol*, but not quite WebSocket. Socket.io sends weird chunks of extraneous data that is non-decodable by a normal WebSocket implementation, thus why their packs are larger.
Also, as an added bonus to Socket.io, you bloat your client with a bunch of non-performant, minified ECMAScript.

Also, I'm not sure how I personally used to send mass messages... I think I used a Set instead of an array, because it makes more sense, but use whatever works.

* I'm not sure whether or not it actually uses WebSocket protocol, please feel free to check me on that.

@xxpertHacker mhm socket uses some web socket protocol. Also I see you use deno, how is it? Personally I'm hesitant towards deno since it's basically node without npm, and all the current good npm packages will be put to waste. Ik there's a module that allows you to import npm in deno, but deno was created solely to avoid the npm situation so I'm a bit hesistant

@Pankak It's literally like using the browser, without the DOM, but with file-system access.

If I want a file, I just say Deno.readFile("./myFile.ext");

If I want to work with binary data, simple, I use standard ArrayBuffers and TypedArrays.

I want to import something, I use a simple URL:

import foo from "./foo.ts";
import bar from "https://foo.org/bar.mjs";

I often use asynchronous, concurrent, and parallel code, so I understand ECMAScript's async/await, and Deno already has top-level await, so that's perfect for simplifying control flow and structure.

Also, as everyone moves on, stuff is always put to waste.

If I move from C++ to Rust, all of my C++ just goes to waste... how sad? Just build more and continue.

Most NPM packages simply aren't necessary in Deno, their's either a suitable built-in, or a good equivalent already.

Everything that Deno offers is contained within the Deno namespace, unlike Node.js, where everything was just global.

Node:

Buffer; // global variable

Deno:

Deno.Buffer; // locked within the Deno namespace
globalThis.Deno === Deno;

In the end, it's just another runtime, it has its pros and cons. Whether you use it or not, is up to you.

Personally, I am used to using typed languages and its first-class support for TypeScript is nice. (Yes, you can still use JavaScript, it's still first-class too)
I also prefer ES modules (.mjs), and strict mode scripts, and that's all that Deno has, so it makes it much easier than having to put in the extra typing to make sure everything is a module.
Also, I tend to use Wasm quite often, and they already support the ESM integration proposal, meaning I can simply import Wasm through a URL:

import { clz32 } from "./main.wasm"

Some really old browsers don't support WebSockets, and Socket.io has fallback in those cases.

The really own 'feature' is that it assigns ids and has a 'room' feature. Overall, there is no more functionality, and you can stick with websockets if you want more speed and power.

huh so what is its purpose then? rooms and ids are easily achievable with normal web sockets @Coder100

@Pankak what's the purpose of jquery?