Re: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

I'm just an application developer monkeying around with WebRTC in my spare
time, so I don't know if I have anything wonderful and new to add to this
discussion. But just my two cents...

I don't really have much interest in streaming media between browsers (at
least right now), but I am quite interested in using data channels for
partially reliable communication with a (headless) C++ server. The SCTP
over DTLS over ICE stack has been... interesting to put together (again,
this is just for fun, so I've been reinventing the wheel), but after a
couple weeks of working a couple nights each week (and with the luxury of
not caring about implementation quality), I've managed to exchange messages
with Firefox 22, and I'm looking forward to doing the same with Chrome
someday.

Honestly, as far as an API goes, all I really care about is having enough
machinery to set up working data channels, and the latest posted editor's
draft gets me there. (I guess I'm lucky I don't need to care too much about
signaling codecs and FEC and whatever else is the hot topic of the day; in
fact, I try to strip all that stuff out of the SDP by refusing media
streams.)

The fact that no browser has really implemented the draft hasn't been a
problem for me; working at "Internet speed," Web developers are used to
working around browser idiosyncrasies and limitations. We've spent years
writing almost completely separate code for Browser X vs. Browser Y and Z,
and while we're always hopeful things will converge someday, we need to
ship something _now_, even if that means a lot more work in the short term.

While I guess it's a failure of the standard process when this happens, if
WebRTC 1.0 fails to gain traction with some browser makers, I don't see
that as a tragedy. Just because something is posted on w3.org doesn't mean
anyone actually cares in practice; just look at the fate of XHTML2 vs.
HTML5, for example. Isn't standardization supposed to trail existing
practice and implementation anyway? Ultimately, success or failure will
come in the community, not sitting around a conference table.

If Browser Y and Z decide to implement WebRTC 1.0, and Browser X only
implements WebRTC 2.0, we Web developers will adapt because we want our
applications to run on as many browsers as possible. And most of this
adaptation will probably be done in a JavaScript library someone throws up
on GitHub, so we probably won't even have to do very much.

And someday, once it becomes apparent how superior WebRTC 2.0 is, we'll all
switch over to that, and the code that supported WebRTC 1.0 will shrivel
away and die from bitrot as WebRTC 2.0 browsers become the dominant
platform.

Until then, while appreciating the efforts to give us developers a
"perfect" API, I'd rather have a terribly flawed standard now and live with
the pain until a better standard comes along later, because at least with
the terribly flawed standard, my Web site can now do something new that it
couldn't do before. (AppCache is probably a good example of how a flawed
standard can still be useful in some cases, and motivate discussions about
doing it "right" the next time; the "worse is better" philosophy.)

So if I'm happy to work with experimental APIs, why care about the standard
at all? Well, developers like me still do appreciate a certain amount of
stability, so we can move on to solving the next part of the puzzle. A
standard API is a promise from the browser makers that they aren't going to
change everything around in the next point release, just because they
thought of a better way to do it. Standards enforce mediocrity at the
expense of innovation, and that's OK.

To make a long story short, I think people like me are the ones driving the
sentiment of "standardize what we have now, fix it later." I'm sure someone
will say that's terribly short-sighted and stupid, and we should get it
right before we have to suffer through using it, but the Web platform is
already filled with short-sighted and stupid API, and yet we still manage
to do some pretty nifty things with it.

Meanwhile, if a browser comes out with a great new way of doing things
(Pointer Events might be a good example), I'm happy to support that, too.
And if that browser lets me do things I can't do on other browsers, I'm
going to be pushing to have those browsers support that new way, too.
That's the beauty of browser competition. But show me the code; win me over
with your great implementation, don't just keep talking about how things
would be so much better if everyone would just open their eyes and follow
you. Give me something I can use, not locked behind a separate download.

--Kahmy