Re: W3C Polyfill service?

On Sun, Oct 23, 2016 at 12:49 AM, Andrew Betts <andrew.betts@gmail.com>
wrote:

> Alex:
> > I'm not sure the W3C is really suited to the task of running
> web-critical, high-performance infrastructure.
>
> Agreed. The angle that intrigued me was the idea of the W3C 'blessing'
> (though co-branding, use of a w3.org subdomain, governance etc) a single
> co-ordinated polyfill effort, but without taking on the responsibility for
> the infrastructure.  Currently Fastly and Heroku run the infrastructure for
> polyfill.io and they seem well suited to it.
>
> Travis:
> > What would be the goal of a polyfil repository? Would they count as an
> implementation of a feature? Could they also be used to help the testing
> effort? If so, then I would love to see them integrated into
> web-platform-tests
>
> Goals are to enable faster adoption of new platform features.  Developers
> can be hesitant if they think the polyfill will bloat their code, or if
> they are not sure if it's any good, etc.  Web platform tests are
> interesting - in many cases polyfills are not perfect replicas of the
> native feature, often due to technical feasibility, sometimes due to lack
> of resources on the part of the author to cover the entire spec.
>
> Building a polyfill is harder than building the feature natively, since
> your code needs to work in all browsers (and by definition not just the
> latest ones) whereas the native impl only has to work in one version of one
> browser.  At the same time polyfill authors are normally individuals with
> limited resources whereas native implementations are created by large teams
> within well funded corporations.  Also, the nature of polyfills means it's
> possible to retrospectively fix bugs in them much more easily - especially
> if they are served from a centrally managed CDN.
>
> In polyfill.io we've looked at the feasibility of testing polyfills with
> web platform tests, but in practice almost all polyfills fail those tests,
> and yet people still use them successfully.  Obviously it's great when a
> polyfill author makes a polyfill that passes WPTs, but since most don't,
> making that a condition of acceptance into a community polyfill library
> would be problematic.  I guess polyfills might help the testing effort in
> other ways?
>
> A
>


I do think that there are several things that W3C and TAG can/should do
regarding a lot of these ideas, I've shared my thoughts in the past and
I've been trying to figure out what the best way to comment because there
are a number of related issues/discussions I see happening that all seem to
confluence around ideas that I've had/private discussions that I haven't
had a chance to assemble into something presentable.  I'm going to skip all
the details and highlight the things that I think something should happen
around, perhaps questions/comments might help me figure out how to best
pursue/present more.


Much of this is centered on the fact that things that are implemented in
JavaScript, along with a draft proposal for standardization are not the
traditional polyfill as defined by Remy Sharp - they have a number of
distinct concerns that are expressly not concerns for real polyfills.  If
we do this well, it is potentially a boon to the ecosystem, and there are
lots of potential followups to make sure that we can make that vibrant and
successful.  If we do it poorly, we actually can harm the ecosystem.

I think that 'thing' _requires_ naming distinction from polyfill.  I also
think it has a perfectly useful one already that has been widely
disseminated in all forms of media, but I don't want to get bogged up in
that in the main argument :)

So one thing that TAG can do, and I thought there was agreement to do this
in another TAG meeting, is to put a note or finding of best practices
around development of this 'thing' that helps achieves its goals and avoid
pitfalls/harm.  I think the most major bits are: a) forward compatibility
in which you don't squat on the name before it is really standard is one
(frequently a leading underscore or $ is enough) b) recognition of the fact
that in order to have value early on, versioning really matters.  c) ways
to express differences and limitations

Another thing (again, I've mentioned this before) is that channeling people
toward safer ones and harnessing this as part of the process becomes useful
to both sides (standards and developers).  Incubation should encourage
having one of these.  It should be linked in the proposal and be required
to follow those best practices.  This would provide some kind of aid for
developers to find such things and have at least some sense of their
quality.

Finding and sense of quality are two areas that I think really matter for
success and I would like to see more on.  Early in the industrial
revolution, no one had a lot of experience with the newly available raw
materials - tinkerers produced a lot of varying quality.  There was, for a
time, a substantial impasse of trust.  Stores were gambling reputations
(lots of consumer laws were not in place) by taking on a product they knew
nothing about, consumers were gambling purchasing a product they knew
nothing about.  Independent signals really helped this problem a lot and
got us past that impasse.  Things like UL listing were a mark that people
could trust.  If you think about this, we do that with tech already.  If
lots of smart people are saying "this thing is good" then I look at it.  If
I come across some random thing I've never heard of, I'm more skeptical.

Ideally, what I would like to see is a vibrant incubation group where the
bar to entry isn't too high or too low - and that incubations include
reasonably good and safe  implementations wherever possible.  That those
proposals and incubations provide a way that they can be indexed and in a
caniuse/chromestatus kind of catalog for proposed standards of a certain
measure of quality as well as information about positive signaling by
vendors.  Invited experts in particular fields should be able to positively
signal too.

If we had these sorts of things, it would be very easy to shepard
developers toward them for standards efforts and participation because it
would make a lot of aspects of their lives a lot easier and engagement more
valuable.  It stops short of W3C "blessing" or "hosting" anything, but it
would make those sorts of efforts considerably more plausible and useful by
simply being somewhat integrated into process.




-- 
Brian Kardell :: @briankardell