Note: The points below are a comparison of using vanilla websockets on client and server and using 'em via socket.io and not about why only use socket.io
- Native websockets provide us with only a
sendmethod to send data to the server. Send accepts onlystringinput (not too sure about this). Socket.io lets us emit arbitrary events with arbitrary data (even binary blobs) to the server. - To receive messages on a vanilla websocket you can only assign a handler for the
messageevent. The data you receive is mostly likely to be text (again not too sure about this) and you will have to parse it manually before consuming it. Socket.io lets the server and client both emit arbitrary events and handles all the parsing and packing/unpacking. - Socket.io gives us both a server and a client. Implementing a vanilla websocket server isn't something that you would want to do per project since it's quite painful. You will have to implement RFC6455 to have a compliant websocket server. Here's a gist of what writing one involves. Here's what parsing an incoming packet on the server looks like (all packets from clients should be masked as per the specification).
- Socket.io gives us abstractions like rooms which aren't really part of the websocket spec so you will have to roll your own if you want to use vanilla websockets.
- Vanilla websocket client will not work on browsers that don't support it (think IE8, IE9, Opera Mini) but a socket.io client server pair will since it has fallbacks (found in engine.io/transports).
Good comparison. I created a project to illustrate the difference between vanilla WebSocket and Socket.IO with simple client-side and server-side code examples. It may be useful for your comparison. It's on https://github.com/rsp/node-websocket-vs-socket.io