3 ms·

Hard to take a "socket.io killer" seriously when it doesn't even implement bare necessities like message_id callbacks: socket.emit('msg', 'hello', (err) =>

Hard to take a "socket.io killer" seriously when it doesn't even implement bare necessities like message_id callbacks: socket.emit('msg', 'hello', (err) => ...) At which point the nice part of using socket.io is that there are a variety of clients (and server impls) so every one of your users doesn't need to implement things like message_id callbacks.

alexhultman 10y ago
µWS is not a Socket.IO killer. In fact, you can use µWS as the low-level engine in Socket.IO. Sadly I cannot (yet) present the pub/sub benchmarks of deepstream.io vs Socket.IO but I promise you: it will be hilarious. Other projects that have been shown to outperform Socket.IO include SocketCluster, which use µWS as the default engine.
josephg 10y ago
That can be implemented with a simple switch statement. Or using node's built in eventemitters in two lines: const e = new EventEmitter(); socket.on('message', msg => e.emit(msg.data.type, msg.data)); Also websockets have far better server and client support. There's websocket implementations in basically every major language as well as most popular load balancers on the market today. When socket.io first came out it was very needed. But now websockets are supported in all major browsers, including mobile: http://caniuse.com/#search=websockets http://caniuse.com/#search=websockets
- always_good 10y ago
  I'm not sure what your snippet is demonstrating, but it's not demonstrating message_id matchup. The client stores its own message_id -> callback mapping, it has to send some sort of reply id for the server or agree on some other mechanism, and it's not something you want to have to build on every project, just like exponential reconnect backaway. And I'm not sure why you'd want to use the native WebSocket API by itself except on toy apps.
  - josephg 10y ago
    You're talking about a light layer on top of websockets to implement a request/response protocol. This can be done pretty trivially on top of websockets in dozens of ways, though if what you want is request/response you should consider using HTTP directly. You never have to "build it again for every project" if you put your code in npm. But I guarantee you there are dozens of libraries like this in npm already. (Just like there are dozens of libraries to do exponential reconnect backoff.) The right approach is to build / use light layers on top of websockets to solve these problems. Socket.io is the wrong solution. Its the wrong solution for every problem.
- deleted 10y ago
  [deleted]

alexhultman 10y ago

µWS is not a Socket.IO killer. In fact, you can use µWS as the low-level engine in Socket.IO. Sadly I cannot (yet) present the pub/sub benchmarks of deepstream.io vs Socket.IO but I promise you: it will be hilarious. Other projects that have been shown to outperform Socket.IO include SocketCluster, which use µWS as the default engine.

josephg 10y ago

That can be implemented with a simple switch statement. Or using node's built in eventemitters in two lines: const e = new EventEmitter(); socket.on('message', msg => e.emit(msg.data.type, msg.data)); Also websockets have far better server and client support. There's websocket implementations in basically every major language as well as most popular load balancers on the market today. When socket.io first came out it was very needed. But now websockets are supported in all major browsers, including mobile: http://caniuse.com/#search=websockets http://caniuse.com/#search=websockets

always_good 10y ago
I'm not sure what your snippet is demonstrating, but it's not demonstrating message_id matchup. The client stores its own message_id -> callback mapping, it has to send some sort of reply id for the server or agree on some other mechanism, and it's not something you want to have to build on every project, just like exponential reconnect backaway. And I'm not sure why you'd want to use the native WebSocket API by itself except on toy apps.
- josephg 10y ago
  You're talking about a light layer on top of websockets to implement a request/response protocol. This can be done pretty trivially on top of websockets in dozens of ways, though if what you want is request/response you should consider using HTTP directly. You never have to "build it again for every project" if you put your code in npm. But I guarantee you there are dozens of libraries like this in npm already. (Just like there are dozens of libraries to do exponential reconnect backoff.) The right approach is to build / use light layers on top of websockets to solve these problems. Socket.io is the wrong solution. Its the wrong solution for every problem.
deleted 10y ago
[deleted]