I dunno. I implemented my games'[1] netcode on top of WebRTC and it runs just as well as proper UDP stuff. If you configure it be unreliable and pack everything into small binary commands then it behaves exactly like you'd want for a fast-paced multiplayer game.
Obviously most web games use websockets for networking but it is certainly possible (albeit much more difficult) to have very fast netcode in a browser game.
It's been awhile since I took a crack at WebRTC. Do you still need to go through all the peer negotiation even when you are just trying to get to a known server?
Bleh! I was really hoping they would have smoothed that out by now. I just want a damn UDP socket to my server!
I guess it's easier to piggyback on the security model of the P2P handshake than work out a separate model for client-server communication.
I built a pair of libraries for a nodejs<->browser DataChannel, it was a nightmare at the time though, and I'm sure totally obsolete by now.
Given how long it took for us to get %*@!$ data channels, I guess we'll get a simpler way to connect to a regular server in... 2030? (I watched WebRTC very closely from the Ericsson prototype was released... for awhile I was contemplating trying to pass data in the audio or video streams -_-)
Instead of cramming ecoded json into the data channels, like you'd with websockets, you can build binary buffers with all the data that has to be communicated between server and client. For example movement commands like up/down/left/right alongside some flags like isJumping can be packed into a singe uInt8
actually binary websockets won't do in this case since the underlying protocol is still TCP with automatic retransmission mechanism which kills performance for very fast-paced games. You have to use WebRTC in that case
[1] https://redka.games/mages