Comment by Klathmon | Hacker News Reader

Comment by Klathmon | Hacker News Reader

Parent Full thread

It's one thing to be the first to implement standards, it's another to completely ignore them for years.

The "Chrome Experiments" was a way to show off the WebGL capability in chrome that no other browsers had at the time. (Now those demos will mostly work in all browsers)

Plus you are forgetting that those are experiments. They were never really meant to be actual "apps". Making an experiment/demo for one browser is fine IMO. Especially when only 1 or 2 browsers have implemented the standard currently.

It's like webRTC. I made a "demo" webRTC app about a year ago, and it only worked in chrome OR firefox (but they couldn't talk to each other). That's not chrome or firefox breaking the web, that's the other browsers not being at the cutting edge, but i don't blame them. WebRTC was (and still is) VERY new, it wasn't even finalized and i was using the app as a bit of a tech demo to see what may be possible in the near future.

The chrome experiments were the same way. WebGL wasn't fully finalized, it was one of the first implementations of it, and people wanted to try it out, so Chrome Experiments was born.

WebRTC is not really new any more - a couple of years old (and existed in other forms long before), and still not widely adopted. In fact, not adopted in a single further browser in that time, and the original two are not compatible.

I'm thinking, its almost time to consider WebRTC 'failure to achieve traction'?

Not an expert, but hopeful that WebRTC will be a success in the end. Maybe I'm just overly optimistic?

> still not widely adopted

Certainly everyone involved with WebRTC wishes that it had the support of IE and Safari, but Chrome + Firefox + Opera is nothing to sneeze at, particularly if you're targeting a savvy audience.

> Original two are not compatible

Maybe I'm confused, are you saying that Firefox and Chrome aren't compatible via WebRTC? I've used them together and had success, but just for basic video calling.

> not adopted in a single further browser in that time

This is fair, but if Microsoft's latest moves come to fruition that will be a big change. There are hints that Edge will likely support WebRTC[0], though I don't think there has been any official word. Maybe that's just for ORTC?

[0]:http://blogs.windows.com/msedgedev/2015/05/13/announcing-med...

All the important scalable features are incompatible - so-called 'bundling' where many streams use a single port etc. Aggregation of error feedback so an MCU can sensibly report bandwidth limits. Slow connect/reconnect times. No 'supernode' support. Pretty much anything that takes it from a toy with 3 or 4 p2p connections, to a product that can handle up to 100 streams with audio/video switching realtime through an MCU or P2P dynamically.

Other products can do this. WebRTC suffers from being based on RTP/RTCP and SIP-style signaling. There's not enough juice there to get the job done.

>All the important scalable features are incompatible - so-called 'bundling' where many streams use a single port etc.

AFAIK this is being fixed. Firefox should support the standard and Chrome is fixing their implementation to conform as well.

Yes, 2 years after it was released. And there are many levels of bundling. Will they both support all of them? Will the MCUs follow quickly? The WebRTC landscape is a disjoint map of features and support that evolves very slowly.

I'm sure as hell not married to the idea of WebRTC, but i desperately want something like it.

The ability to do peer-to-peer communication from the browser is an amazing tool. It allows the creation of client-side-only web apps which can easily send massive amounts of data to others. With WebRTC (or any other service like it) you can add video chat to a web app with very little work, and no real server side infrastructure that is more secure than the alternatives.

If it needs to be re-done in the name of getting it implemented widely that's fine with me and i welcome it, but if it's just NIH syndrome at microsoft holding it back, that's not okay.

Mostly its an unprofessional wad of code written by some PhD's. It went through some hands and ended up at Google, who mercifully refactored it somewhat and renamed it.

I've been dealing with the code base for 5 years, and never liked it. Had to rewrite the APIs every time we got a new source version, to fit our model which isn't the 'conference call' model. I'd be glad to see something more app-agnostic that just dealt with negotiating P2P streams, without so many assumptions about what/why/when the streams are.

IMO this is directly related to the post. WebRTC is a technology that has huge potential on mobile (given phones have cameras etc) but Apple haven't/won't implement it.

WebGL is a good comparison here - it was pretty dead before Apple implemented it. When they did (in iOS8) you started seeing a ton more WebGL things popping up.

New version is being worked on: https://www.w3.org/community/ortc/

Still another conference-call-specific take on p2p communications. Application assumptions are laced throughout the design. Which in my experience is the usual problem with open source IP - its tied up with so many assumptions as to be brittle.

ORTC is basically Microsoft's NIH version of WebRTC.

Maybe some of the good ideas will end up in an improved WebRTC standard, but ORTC itself is not "the new version".

Reply on news.ycombinator.com