Don't use unnecessary polymer custom elements in WebRTC samples

[jan-ivar]

#1144 (review) introduced dependencies on polymer custom element stuff that shouldn't have been introduced in samples IMHO. The samples don't even load on Edge anymore.

Samples should be simple and accessible, without unnecessary dependencies, and these dependencies are clearly unnecessary. I suggest they be reverted.

[fippo]

Also that PR adds recording which is not supported in Edge (if it was loading).
Additionally we have striven to promote the spec in the past, showing the non-getDisplayMedia way in Firefox would have been a no-go.

As a long time contributor to this repository I am concerned about the shift in values (see also #1147 or here)

[jan-ivar]

showing the non-getDisplayMedia way in Firefox would have been a no-go.

Thanks @fippo I missed that. Yeah getDisplayMedia is already shimmed by adapter.js, so this piece of feature-detection code is truly redundant and should be removed.

Also a heads-up about webrtcHacks/adapter#896.

[dagingaa]

As a web developer and occasional bug reporter I can't tell you how useful it has been to be able to point to WebRTC samples in the past in bug reports or when asking for feature support to link to the sample showing a reference implementation without any cruft or stuff. It has also been a good way to test if the reference implementation has the same bug as I observe in my own application, to get a check for if it's my problem or not.

Moving to polymer feels like the wrong move as it has no place in WebRTC-land, and given that Edge breaks with it, we remove the one reference implementation that strived to work across browsers.

Please keep app frameworks out of the WebRTC samples (or at least use one of the more popular ones that has broad cross-browser support if you must)

[ErikHellman]

Good feedback. The input I got from other developers is that a contextualised sample that shows how to use the APIs in a more realistic application is more appreciated.

Choosing Polymer was done as it builds on the native Web Components support and didn't require packaging like webpack or similar.

I'm all for reverting this if this is what the people using the samples feel is right.

[jan-ivar]

@ErikHellman I think the samples should communicate to people with as little up-front knowledge as possible. So far we've been able to do this with plain JavaScript for the broadest possible impact, without needing dependencies on third-party libraries.

Is there a particular obstacle or problem that warrants a change from this policy? If not, I don't see why requiring people to learn and understand custom elements in order to learn how screen-sharing works, adds value, and I'd vote to revert this.

[jan-ivar]

In particular, I'd hate for anyone to get the impression polymer is somehow required for screen-sharing.

[ErikHellman]

@jan-ivar This relates to who is the target audience for these samples. Web developers with little experience from WebRTC need some kind of context. This is my experience from teaching as well as what I've heard after speaking with other web developers. In my opinion, these samples are part of the developer relations effort around WebRTC and should aim for as many developers as possible.

The choice of Polymer is simply for technical reasons around publishing this on GitHub pages. I'd love to have samples that use React, Vue.js or Angular as well, I just haven't had time to write those as well.

[jan-ivar]

With all due respect, the premise that plain JavaScript doesn't reach the most web developers, seems false.

I must also agree with @fippo that changing the sample to only show screen-sharing in the context of recording, is a bad idea. Not only because it doesn't work on all browsers, but because it adds confusion about the realtime aspects of these APIs.

Recording isn't the primary use-case, sharing one's screen live in a web conference is. I'd recommend showing off the combined effect in a separate example instead.

[ErikHellman]

I can agree that this sample could be better. The first version had some other issues as displaying the screen capture locally made for a very poor demo. I missed testing this on Edge before deploying and would have waited if I had discovered the bug there (the Polymer bug seems to be a glitch in unpkg. Looking into that separately).

I'd like to suggest two changes;

• Change the name of this sample to better reflect what it does (e.g. Screen Recording)
• Republish the previous version that only does screen sharing to a local video element (is it was before)

[jan-ivar]

Could work, but doesn't address that polymer is unnecessary to make even this new sample run. If the new sample could live at the new url, then I suppose my interest in opposing it would be less.

[fippo]

FWIW, unpkg breaks when trying to load locally. See https://bugs.chromium.org/p/webrtc/issues/detail?id=10768

Once upon a time these samples could be relied on.