[mrmoka]

Simply look at present state of WebRTC adoption by back-end services for use in server-client cases. Fist of all it is not designed for server-client cases. Second, after so many years, it is still not well adopted and used for server-client cases due to it's complexity on both sides - back-end implementation and front-end usage.

If you compare it to speed of adoption of WebSockets, variety of WebSockets implementations and how much it is used commercially.

There are many conversations by many developers who as well attempted using WebRTC for server-client communications, and it is apparent trend.

One of the developers of WebRTC team at Google who worked on DataChannel and network code admits himself that their team is aware of complexity and difficulties with WebRTC in server-client cases: https://news.ycombinator.com/item?id=13266874

[TD-Linux]

>Fist of all it is not designed for server-client cases.

WebRTC is specifically designed for server-client cases. In the case of video and audio, the server is called a "mixer" or MCU. This is extremely important for large multi-user conferences - if it weren't for a mixer, you'd have to upload your video once for every user, burning all of your upload bandwidth. Examples of services using this are Appear.in Premium and Cisco Spark.

Note that games are the #1 use case mentioned in the Datachannel draft [1]. It's perfectly fine to argue that the standard is bad, but it was designed for these use cases.

The Google developer you linked seems to be arguing for improving the WebRTC C++ library, not changing the protocol.

[1] https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-1...

[mrmoka]

> You can't compare WebSockets with WebRTC because the first one has a much larger implementation base across browsers than the later.

This is exactly what I pointed out: WebSocket has much larger implementation base across browsers and back-end due it's simplicity.

> There is also a list of various transparent fallbacks that can be implemented like long polling which WebRTC doesn't have.

Those fallbacks were temporary solutions during adoption of WebSockets which today are obsolete as WebSockets are well adopted and pure WebSockets implementation is fairly simple.

This is what we want from WebUDP for server-client cases, which we can fallback to WebSockets if WebUDP is not supported.

[LunaSea]

You can't compare WebSockets with WebRTC because the first one has a much larger implementation base across browsers than the later.

There is also a list of various transparent fallbacks that can be implemented like long polling which WebRTC doesn't have.