I also played with the idea of using WebRTC data channels for client server applications. From a system design perspective it looks good, since it can provide l

I also played with the idea of using WebRTC data channels for client server applications. From a system design perspective it looks good, since it can provide lots of concurrent flow controlled streams (like HTTP/2) with a potentially lower latency. However from the pure engineering side things don't look so great for the reasons Matheus28 already mentioned: WebRTC (even data channels only) is a big stack of massive complexity. It's not something you want to implement or understand fully on your own within a reasonable amount of time (like you could do with WebSockets). The most reasonable way to get WebRTC support seems like integrating Googles native WebRTC library. However one downside is that it's a big dependency with which a lot of people might be uncomfortable bringing in (although you say you are working on making it smaller). The other downside is that it's not only big but a native dependency, which I and other people want to avoid wherever possible in non C/C++ land. The alternative solution would be to develop a pure Go/.NET core/Java/etc. WebRTC data channel solution. However for this most of the required subcomponents are missing. Imho neither of those even support the required DTLS encryption in the (extended) standard libraries, and there are also no libraries for SCTP on top of UDP around. Therefore getting this to work is a serious effort, and anybody who approaches it must ask himself if the effort is justified or if Websockets and HTTP streaming are not good enough. For the latter one the performance might even reach WebRTC data channel performance if QUIC gets standardized and widely deployed. I think the situation might be different if WebRTC data channels would only have standardized a UDP or possibly encrypted UDP. Anybody who would have needed it could still be able to implement streams and multiplexing on top of it on server and client(JS) side. The current solution provides a nicer out of the box API, but supporting it outside of the browser is hard.