Re: W3C Polyfill service?

On Sun, Oct 30, 2016 at 3:27 AM, Alex Russell <slightlyoff@google.com>
wrote:

> Hey Brian,
>
> On Sunday, October 30, 2016, Brian Kardell <bkardell@gmail.com> wrote:
>
>>
>>  [snip]

>
>> 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)
>>
>
> There's a pretty big grey area here that I think is just as important:
> when is it reasonable to drop the prefix? When a spec hits CR? PR? Has
> multiple native impls? When most modern browsers support the feature?
>
>

Yes! This is a very good topic that I think needs to be discussed as part
of this., I've been asking the community the same question for some time
(see https://twitter.com/briankardell/status/287204328555548672 for one
example where I asked this very question).  I posit that we've gotten it
wrong in the past in many times simply because these are discussions we've
not really had.

Obviously, the further down the line, the higher the odds of that becoming
the standard rises.  Definitely by the time you hit 'most modern browsers'
that's the original definition of polyfill.  Until then though, honestly,
it's at least a little sketchy. Until we actually have at least
agreements/positive signals in chromestatus terms, we can't know for sure.
See next section reply for more about how vendor prefixes made that worse
even.

I don't have a good definition, but in the least it seems possible to draw
a fuzzy line.

There's been misleading communication to devs in some cases in the least
and I think that that is a bigger deal than a lot of people appreciate.  It
can exacerbate problems rather than help smooth them and sometimes that can
actually harm standards efforts and faith in them.  Thats a bad outcome we
should try to avoid, especially without really good reason to do so.



> 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).
>>
>
> Safety is an interesting concept here; do we mean "avoids premature
> compatibility with a specific grammar or semantic which may be out of sync
> w/ the final spec"?
>


It seems a given to me that by definition an experiment cannot entirely
guarantee the final anything.  It needs to be close enough to give
developers a real good sense of it, and the understanding that it is an
experiment and what expectations that holds for them.

There is clear harm in squatting too early on too generic a name - see
.includes()/.contains() history for an example of that.  As a comparison, I
think it's useful to look at the method used to test whether an element
would test positively with some selector.  Early chrome/webkit shipped with
a prefixed implementation of a proposal for method called matchesSelector -
one by one they followed.  Chrome v1, Firefox 3.6, IE9, Opera 15 and Safari
5 all shipped with prefixed matchesSelector.  Astute observers noted that
querySelector led this in some browsers and thus it was possible to create
an implementation, so they did.  A large number of people downloaded a
'polyfill' which said 'if there is a native .matchesSelector(..)' use that,
otherwise look through the prefixed ones until you find and use that,
otherwise use qsa and see if this element is in the results.  Seems ok,
except that before unprefixing the late decision was made to call it
.matches(..) instead.  This is interesting because the name is so specific
it's unlikely that we will ever want that for something else.  In practice,
it operated more like a prollyfill, the overly complex name let a ton of
developers use it early, give feedback, and think about new ways to use
it.  They wrote and shipped production code that works as good in every way
as it used to, and still benefits from Moore's Law if nothing else.  It
didn't match the final api, but it was damned close.  Turning that into a
polyfill was then the matter of just removing the 'Selector' part.

I really like this example because it demonstrates the other side of that
as well.  jQuery had .is(...) in 2006 and if we'd been doing this in '06,
it seems pretty likely we might have had an .is(...) proposal backed by the
matching bits of jQuery internals.  That would have squatted on a
potentially useful name (is attribute might have been more troubling) and
its semantics for matching might have been different too.  ._is(...) on the
other hand, understood as an experiment could have been relatively safe and
as you moved on corrections in semantics could have evolved correctly
without much harm via versioned opt-in.

I really think devs are more willing to be ok with potential for change as
long as they are in control of it, understand the context and it helps them
ship something that doesn't unexpectedly break without them changing
anything.  Those, at the end of the day are developer's primary goals - and
the goals of those we ship software for.  Very few businesses would trade
that for an unexpected slightly faster lookup potential in a single method.



>
>
>> 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.
>>
>
> I think I've been phrasing this slightly differently: incubation should
> seek to get developer feedback and iterate quickly based on it. There are
> many cases where polyfills don't have enough power to provide a reasonable
> facsimile of the eventual feature. The Houdini APIs come to mind. In these
> cases it'd be a bit of a distraction to say "make a polyfill!" when the way
> to get feedback about how well something like Custom Paint will function
> will be derived from a prototype implementation that devs can target (hence Origin
> Trials
> <https://github.com/jpchase/OriginTrials/blob/gh-pages/explainer.md>).
>

Yes, of course, I qualified earlier in the reply "where possible".  I
believe we may have co-written a document to this effect once :) Houdini is
largely about digging down to/closer to/exposing primitives. Obviously,
that's why we want focus on them, because only browsers can do that.  That
said, there are Houdini APIs where we could - the parser API and Typed OM
spring to mind as excellent examples.  But yes, of course, fundamental
primitives.  And, I support origin trials, but as I mentioned to you they
are definitely for a more limited audience, on purpose.  That's a trade-off
and it's a good one for some cases.  It's not a good one for others. It's
super great for experimenting with primitives in some cases.  In others,
behind a flag works well too.   I don't think that I can unfortunately,
can't ship something for that small contract job for the local pizza joint
with an origin trial because it might well suddenly end, right? With a
prollyfill though I can ship it, solve some development pain, contribute my
experience and feedback back into the system and go to bed at night and
sleep well knowing that if it works today, it will keep working tomorrow
and I won't get upset calls from people who didn't expect to have to keep
re-investing just to keep their website running for no apparent reason.



-- 
Brian Kardell :: @briankardell