For this sort of thing, albeit only with a .NET backend, I've always used SignalR to handle these browser/server OS incompatibilities. It'll negotiate a common protocol, whether that be WebSockets, SSE, or falling back to long-polling.
However SignalR does not give you access to a raw websocket, in the same sense that socket.io does not give you one. Both are higher level abstractions that can use websockets as a transport, but are not restricted to them. If you want to run a custom protocol on plain websockets, e.g. because it's already well-defined what the other peer speaks/understands, then both are not applicable. If you don't care whether your realtime application is portable to another framework then yes, SignalR and socket.io are very viable solutions.
When I checked probably around 6 months ago, SignalR seemed to have no real story for ASP.NET Core and it also depended on jquery on the frontend, which I found to be simply ridiculous.
Comments
For this sort of thing, albeit only with a .NET backend, I've always used SignalR to handle these browser/server OS incompatibilities. It'll negotiate a common protocol, whether that be WebSockets, SSE, or falling back to long-polling.
However SignalR does not give you access to a raw websocket, in the same sense that socket.io does not give you one. Both are higher level abstractions that can use websockets as a transport, but are not restricted to them. If you want to run a custom protocol on plain websockets, e.g. because it's already well-defined what the other peer speaks/understands, then both are not applicable. If you don't care whether your realtime application is portable to another framework then yes, SignalR and socket.io are very viable solutions.
When I checked probably around 6 months ago, SignalR seemed to have no real story for ASP.NET Core and it also depended on jquery on the frontend, which I found to be simply ridiculous.