Re: Is polyfilling future web APIs a good idea?

[Glen Huang]

Awesome. Now I think I understand the full picture you described.

When trying to offer a feature that is still being specced, prefix the specced 
APIs, and once the spec is stable, for browsers that don't ship these APIs, 
alias the prefixed ones by dropping the prefix. Is that correct?

> On Aug 10, 2015, at 9:33 PM, Brian Kardell  wrote:
> 
> On Aug 6, 2015 11:05 PM, "Glen Huang"  > wrote:>
> 
> > > This assumes you'll match
> >
> > That's a good point. I agree for most APIs it's probably better to simply 
> > use polyfill code for all browsers. But some APIs have some extra benefits 
> > that might not be polyfillable. For example, the native version of web 
> > animations happen in a compositor thread, so google's web animations 
> > polyfill use native APIs when they exist and only provide polyfill when 
> > they don't.
> >
> Right, and if "ABC Co." shipped software a few years ago before that was 
> available they probably used jQuery animations and if they haven't touched 
> their site since then it still works - in fact, it very likely works much 
> better because the trend for performance is always improving.  If they came 
> back later and used the animations polyfill it takes advantage of some 
> additional stuff on the compositor thread in some browsers.  If this is 
> really a polyfill because it is a settled standard then as browsers implement 
> they should automatically get the same boosts because we can ensure future 
> interop - no harm no foul.  You couldn't though have a mix of all of those 
> worlds - we couldn't have old jQuery code, reinvent how it's 
> expressed/capable of on the way to standards and somehow automatically fill 
> the old code - the best you can do there is improve general performance. If 
> there are underlying tools in some browsers that help you solve a prolyfill 
> better, you can use them in the same way - but you can't really prognosticate 
> that that's exactly how it's going to come out the other end when the 
> standard ships.
> 
> > > But it's not deprecated in browsers that don't support it
> >
> > Probably I still don't quite understand how prollyfill works.
> >
> 
> I don't feel like there are standard best practices worked out here - I'm 
> giving you my own perspective as someone who has spent an inordinate amount 
> of time thinking about this, I am not speaking for anyone else here - your 
> mileage may vary - but I'm advocating it's worth developing some.
> 
> 
> > Let's say the prollyfill offered node._foo(), one browser shiped 
> > experimental node.foo(), users ignored that, and used our polyfilled 
> > version. Everyone was happy. Then other browsers are on board, this API 
> > becomes stable. Now, what should the prollyfill do?
> >
> > Should it still ship node._foo() and expect users to use that when most 
> > browsers ship node.foo() and this API has a precise definition?
> 
> > Or it should deprecate node._foo(), polyfill node.foo() for browsers still 
> > don't support it and encourage users to switch to node.foo()?
> 
> Of course when it is a standard, released and interop - it's a polyfill... 
> For the polyfill maker I expect at that point they would simply lose the 
> underscore and, perhaps to make it easy for authors they could just make _foo 
> an alias of .foo (which was my example one liner)...  It's entirely up to 
> authors whether they will even go back and update their code and imports and 
> how they will do so -- their old code will continue to work just fine.  But a 
> lot of authors will be happy to gain perf if there is no rewrite involved 
> (ie, if they happened to use a version that is ultimately compatible with the 
> final standard)  and there's not really a penalty in using an aliased name 
> for a method, so that's the approach I would likely use or at least document. 
>   
> 
> > Or it should do something else?
> >
> > I don't quite understand the oneliner you gave:
> >
> > HTMLElement.prototype.foo = HTMLElement.prototype._foo;
> >
> > Why would you want to overwrite a native API with polyfill? How does that 
> > work for users? Users can choose either native API or prollyfill's prefixed 
> > version and they will both use the polyfill?
> 
> You wouldn't want to overwrite a native API, I'm not suggesting that -- I'm 
> suggesting that if you have a prollyfill implementation already which happens 
> to match the final spec interoperably you can both keep your existing uses 
> working and polyfill with the one-liner above for implementations that don't 
> support it.  I guess I thought that much was implied, sorry for the confusion 
> but - it's meant to be in an if or conditional of some kind.. Could be as 
> simple as adding this to the end of your file at this point (ie, when it is 
> actually a polyfill):
> 
> HTMLElement.prototype.foo = HTMLElement.prototype.foo || 
> HTMLElement.prototype._foo;
> 
> The important part here is that ideas for _foo can compete because it is up 
> to 

Re: Is polyfilling future web APIs a good idea?

[Brian Kardell]

On Aug 6, 2015 11:05 PM, "Glen Huang"  wrote:>

> > This assumes you'll match
>
> That's a good point. I agree for most APIs it's probably better to simply
use polyfill code for all browsers. But some APIs have some extra benefits
that might not be polyfillable. For example, the native version of web
animations happen in a compositor thread, so google's web animations
polyfill use native APIs when they exist and only provide polyfill when
they don't.
>
Right, and if "ABC Co." shipped software a few years ago before that was
available they probably used jQuery animations and if they haven't touched
their site since then it still works - in fact, it very likely works much
better because the trend for performance is always improving.  If they came
back later and used the animations polyfill it takes advantage of some
additional stuff on the compositor thread in some browsers.  If this is
really a polyfill because it is a settled standard then as browsers
implement they should automatically get the same boosts because we can
ensure future interop - no harm no foul.  You couldn't though have a mix of
all of those worlds - we couldn't have old jQuery code, reinvent how it's
expressed/capable of on the way to standards and somehow automatically fill
the old code - the best you can do there is improve general performance. If
there are underlying tools in some browsers that help you solve a prolyfill
better, you can use them in the same way - but you can't really
prognosticate that that's exactly how it's going to come out the other end
when the standard ships.

> > But it's not deprecated in browsers that don't support it
>
> Probably I still don't quite understand how prollyfill works.
>

I don't feel like there are standard best practices worked out here - I'm
giving you my own perspective as someone who has spent an inordinate amount
of time thinking about this, I am not speaking for anyone else here - your
mileage may vary - but I'm advocating it's worth developing some.


> Let's say the prollyfill offered node._foo(), one browser shiped
experimental node.foo(), users ignored that, and used our polyfilled
version. Everyone was happy. Then other browsers are on board, this API
becomes stable. Now, what should the prollyfill do?
>
> Should it still ship node._foo() and expect users to use that when most
browsers ship node.foo() and this API has a precise definition?

> Or it should deprecate node._foo(), polyfill node.foo() for browsers
still don't support it and encourage users to switch to node.foo()?

Of course when it is a standard, released and interop - it's a polyfill...
For the polyfill maker I expect at that point they would simply lose the
underscore and, perhaps to make it easy for authors they could just make
_foo an alias of .foo (which was my example one liner)...  It's entirely up
to authors whether they will even go back and update their code and imports
and how they will do so -- their old code will continue to work just fine.
But a lot of authors will be happy to gain perf if there is no rewrite
involved (ie, if they happened to use a version that is ultimately
compatible with the final standard)  and there's not really a penalty in
using an aliased name for a method, so that's the approach I would likely
use or at least document.

> Or it should do something else?
>
> I don't quite understand the oneliner you gave:
>
> HTMLElement.prototype.foo = HTMLElement.prototype._foo;
>
> Why would you want to overwrite a native API with polyfill? How does that
work for users? Users can choose either native API or prollyfill's prefixed
version and they will both use the polyfill?

You wouldn't want to overwrite a native API, I'm not suggesting that -- I'm
suggesting that if you have a prollyfill implementation already which
happens to match the final spec interoperably you can both keep your
existing uses working and polyfill with the one-liner above for
implementations that don't support it.  I guess I thought that much was
implied, sorry for the confusion but - it's meant to be in an if or
conditional of some kind.. Could be as simple as adding this to the end of
your file at this point (ie, when it is actually a polyfill):

HTMLElement.prototype.foo = HTMLElement.prototype.foo ||
HTMLElement.prototype._foo;

The important part here is that ideas for _foo can compete because it is up
to authors to decide what ._foo should look like because they import a
specific definition.  It can evolve, updates can involve breakage, but it's
up to the author to determine whether they are even going to update -- if
the very first pass at ._foo worked for you, it'll keep working in
production when you've moved on to some other contract -- it'll even keep
working once there is a native .foo if that ever happens, but unless you go
and specifically opt in an update, make sure there isn't API breakage - you
won't get native benefits automatically, because we can't peer into a
crystal ball and know that will be the fact.

Re: Is polyfilling future web APIs a good idea?

[Glen Huang]

> This assumes you'll match

That's a good point. I agree for most APIs it's probably better to simply use 
polyfill code for all browsers. But some APIs have some extra benefits that 
might not be polyfillable. For example, the native version of web animations 
happen in a compositor thread, so google's web animations polyfill use native 
APIs when they exist and only provide polyfill when they don't.

> But it's not deprecated in browsers that don't support it

Probably I still don't quite understand how prollyfill works.

Let's say the prollyfill offered node._foo(), one browser shiped experimental 
node.foo(), users ignored that, and used our polyfilled version. Everyone was 
happy. Then other browsers are on board, this API becomes stable. Now, what 
should the prollyfill do?

Should it still ship node._foo() and expect users to use that when most 
browsers ship node.foo() and this API has a precise definition?

Or it should deprecate node._foo(), polyfill node.foo() for browsers still 
don't support it and encourage users to switch to node.foo()?

Or it should do something else?

I don't quite understand the oneliner you gave:

HTMLElement.prototype.foo = HTMLElement.prototype._foo;

Why would you want to overwrite a native API with polyfill? How does that work 
for users? Users can choose either native API or prollyfill's prefixed version 
and they will both use the polyfill?

> On Aug 7, 2015, at 7:07 AM, Brian Kardell  wrote:
> 
> On Thu, Aug 6, 2015 at 6:50 PM, Glen Huang  wrote:
>> @William @Matthew
>> 
>> Ah, thanks. Now I think prollyfill is prolly a good name. :)
>> 
>> @Brian
>> 
>> Actually, I had this pattern in mind:
>> 
>> When no browsers ship the API:
>> 
>> ```
>> if (HTMLElement.prototype.foo) {
>>  HTMLElement.prototype._foo = HTMLElement.prototype.foo;
>> } else {
>>  HTMLElement.prototype._foo = polyfill;
>> };
>> ```
> 
> This assumes you'll match, which - again depending on how far you are
> might be a big bet... Personally, I wouldn't use that myself if
> writing something -- Seems a lot like  when people simply provided N
> versions of the same prefixed properties instead of just one, it has
> potential to go awry... No one can actually vary because they've done
> the equivalent of shipping the unprefixed thing inadvertently
> intending it to be an experiment, but it wasnt.
> 
>> 
>> When at least two browsers ship this API:
>> 
>> ```
>> if (!HTMLElement.prototype.foo) {
>> HTMLElement.prototype.foo = polyfill;
>> }
>> HTMLElement.prototype._foo = function() {
>>  console.warn("deprecated");
>>  return this.foo();
>> };
>> ```
> 
> But it's not deprecated in browsers that don't support it, it's a
> polyfill at that point and aside from the console.warn (which again,
> in this case seems incorrect in the message at least) it should be
> generally be identical to the oneliner I gave before - the prototype
> for _foo is the polyfill version.
> 
> 
> 
> -- 
> Brian Kardell :: @briankardell :: hitchjs.com

Re: Is polyfilling future web APIs a good idea?

[Brian Kardell]

On Thu, Aug 6, 2015 at 6:50 PM, Glen Huang  wrote:
> @William @Matthew
>
> Ah, thanks. Now I think prollyfill is prolly a good name. :)
>
> @Brian
>
> Actually, I had this pattern in mind:
>
> When no browsers ship the API:
>
> ```
> if (HTMLElement.prototype.foo) {
>   HTMLElement.prototype._foo = HTMLElement.prototype.foo;
> } else {
>   HTMLElement.prototype._foo = polyfill;
> };
> ```

This assumes you'll match, which - again depending on how far you are
might be a big bet... Personally, I wouldn't use that myself if
writing something -- Seems a lot like  when people simply provided N
versions of the same prefixed properties instead of just one, it has
potential to go awry... No one can actually vary because they've done
the equivalent of shipping the unprefixed thing inadvertently
intending it to be an experiment, but it wasnt.

>
> When at least two browsers ship this API:
>
> ```
> if (!HTMLElement.prototype.foo) {
>  HTMLElement.prototype.foo = polyfill;
> }
> HTMLElement.prototype._foo = function() {
>   console.warn("deprecated");
>   return this.foo();
> };
> ```

But it's not deprecated in browsers that don't support it, it's a
polyfill at that point and aside from the console.warn (which again,
in this case seems incorrect in the message at least) it should be
generally be identical to the oneliner I gave before - the prototype
for _foo is the polyfill version.



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Is polyfilling future web APIs a good idea?

[Glen Huang]

@William @Matthew

Ah, thanks. Now I think prollyfill is prolly a good name. :)

@Brian

Actually, I had this pattern in mind:

When no browsers ship the API:

```
if (HTMLElement.prototype.foo) {
  HTMLElement.prototype._foo = HTMLElement.prototype.foo;
} else {
  HTMLElement.prototype._foo = polyfill;
};
```

When at least two browsers ship this API:

```
if (!HTMLElement.prototype.foo) {
 HTMLElement.prototype.foo = polyfill;
}
HTMLElement.prototype._foo = function() {
  console.warn("deprecated");
  return this.foo();
};
```

Re: Is polyfilling future web APIs a good idea?

[William Jeffries]

Because it will "probably" become a real polyfill.
Em Thu, Aug 6, 2015 às 4:00 AM, Glen Huang  escreveu:

> Thanks for the detailed explanation.
>
> The only thing I'm not sure I understand is the pattern you described:
>
> ```
> HTMLElement.prototype.foo = HTMLElement.prototype._foo;
> ```
>
> I had this pattern in mind when you talked about prollyfills:
>
> ```
> HTMLElement.prototype._foo = function() {
>   if (HTMLElement.prototype.foo) return this.foo();
>   return polyfill();
> };
> ```
>
> And users are expected to use it like html._foo() My concern was that when
> most browsers ship HTMLElement.prototype.foo, users might want to change
> html._foo() to html.foo() so they can use the native version, and the
> prollyfill is expect to release a new version with
>
> ```
> if (!HTMLElement.prototype.foo) {
>   HTMLElement.prototype.foo = function() {
> return polyfill();
>   };
> }
> ```
>
> I was saying changing html._foo() to html.foo() aren't that different from
> changing foo(html) to html.foo();
>
> Where does HTMLElement.prototype.foo = HTMLElement.prototype._foo fit in
> the picture?
>
> BTW, just curious, how do you come up with the name "prollyfill" :) ? Why
> adding a R there?
>
>
>
>
>

Re: Is polyfilling future web APIs a good idea?

[MOHAN ARUN]

Question all,
Is web remoting web socket built in HTML 5 and above/
Why do we need XMLHttpRequest at all?
Pls. enlighten me.

I am not sure if we should be bothering about
XMLHttpRequest.

L.Mohan Arun
@cintanotes2
I want to write/proofread from home.


On Thu, Aug 6, 2015 at 5:49 PM, Matthew Robb  wrote:
> 'Prolly' is a slang term for probably... At least in the US it is.
>
> On Aug 5, 2015 11:00 PM, "Glen Huang"  wrote:
>>
>> Thanks for the detailed explanation.
>>
>> The only thing I'm not sure I understand is the pattern you described:
>>
>> ```
>> HTMLElement.prototype.foo = HTMLElement.prototype._foo;
>> ```
>>
>> I had this pattern in mind when you talked about prollyfills:
>>
>> ```
>> HTMLElement.prototype._foo = function() {
>>   if (HTMLElement.prototype.foo) return this.foo();
>>   return polyfill();
>> };
>> ```
>>
>> And users are expected to use it like html._foo() My concern was that when
>> most browsers ship HTMLElement.prototype.foo, users might want to change
>> html._foo() to html.foo() so they can use the native version, and the
>> prollyfill is expect to release a new version with
>>
>> ```
>> if (!HTMLElement.prototype.foo) {
>>   HTMLElement.prototype.foo = function() {
>> return polyfill();
>>   };
>> }
>> ```
>>
>> I was saying changing html._foo() to html.foo() aren't that different from
>> changing foo(html) to html.foo();
>>
>> Where does HTMLElement.prototype.foo = HTMLElement.prototype._foo fit in
>> the picture?
>>
>> BTW, just curious, how do you come up with the name "prollyfill" :) ? Why
>> adding a R there?
>>
>>
>>
>>
>

Re: Is polyfilling future web APIs a good idea?

[Matthew Robb]

'Prolly' is a slang term for probably... At least in the US it is.
On Aug 5, 2015 11:00 PM, "Glen Huang"  wrote:

> Thanks for the detailed explanation.
>
> The only thing I'm not sure I understand is the pattern you described:
>
> ```
> HTMLElement.prototype.foo = HTMLElement.prototype._foo;
> ```
>
> I had this pattern in mind when you talked about prollyfills:
>
> ```
> HTMLElement.prototype._foo = function() {
>   if (HTMLElement.prototype.foo) return this.foo();
>   return polyfill();
> };
> ```
>
> And users are expected to use it like html._foo() My concern was that when
> most browsers ship HTMLElement.prototype.foo, users might want to change
> html._foo() to html.foo() so they can use the native version, and the
> prollyfill is expect to release a new version with
>
> ```
> if (!HTMLElement.prototype.foo) {
>   HTMLElement.prototype.foo = function() {
> return polyfill();
>   };
> }
> ```
>
> I was saying changing html._foo() to html.foo() aren't that different from
> changing foo(html) to html.foo();
>
> Where does HTMLElement.prototype.foo = HTMLElement.prototype._foo fit in
> the picture?
>
> BTW, just curious, how do you come up with the name "prollyfill" :) ? Why
> adding a R there?
>
>
>
>
>

Re: Is polyfilling future web APIs a good idea?

[Glen Huang]

Thanks for the detailed explanation.

The only thing I'm not sure I understand is the pattern you described:

```
HTMLElement.prototype.foo = HTMLElement.prototype._foo;
```

I had this pattern in mind when you talked about prollyfills:

```
HTMLElement.prototype._foo = function() {
  if (HTMLElement.prototype.foo) return this.foo();
  return polyfill();
};
```

And users are expected to use it like html._foo() My concern was that when most 
browsers ship HTMLElement.prototype.foo, users might want to change html._foo() 
to html.foo() so they can use the native version, and the prollyfill is expect 
to release a new version with

```
if (!HTMLElement.prototype.foo) {
  HTMLElement.prototype.foo = function() {
return polyfill();
  };
}
```

I was saying changing html._foo() to html.foo() aren't that different from 
changing foo(html) to html.foo();

Where does HTMLElement.prototype.foo = HTMLElement.prototype._foo fit in the 
picture?

BTW, just curious, how do you come up with the name "prollyfill" :) ? Why 
adding a R there?

Re: Is polyfilling future web APIs a good idea?

[MOHAN ARUN]

 Do polyfills like WebReflection's DOM4 look promising?
No. Lets choose to not spoil a text-based markup language by trying to
emulate geometry. etc. There are other tools for geometry. HTML not suited
for  geometry.

'I feel it's more sustainable to bet on spec APIs.'
No. I prefer lets Focus on specific tags. Improve the tags and their
attributes.

MAKE THINGS BETTER BY 1% / AND THE OTHER 95% WILL…

Things I think w3c.org should work out:
CONTENTEDITABLE is an standard attribute.
http://html5demos.com/contenteditable

this thing DATALIST should be part of standard.
http://www.w3schools.com/tags/tag_datalist.asp

On Mon, Aug 3, 2015 at 7:09 AM, Glen Huang  wrote:

> I'm pretty obsessed with all kinds of web specs, and invest heavily in
> tools based on future specs. I was discussing with Tab the other day about
> whether he thinks using a css preprocessor that desugars future css is a
> good idea. His answer was surprisingly (at least to me) negative, and
> recommended sass. His arguments were that
>
> 1. the gramma is in flux and can change
> 2. css might never offer some constructs used in sass, at least with very
> low priority.
>
> I think these are good points, and it reduced my enthusiasm for future
> spec based css preprocessors. But this got me thinking about polyfills for
> future web APIs. Are they equally not recommended? Likewise, the APIs might
> change, and for DOM operations we should rely on React because the native
> DOM might never offer such declarative APIs, at least with very low
> priority. Do polyfills like WebReflection's DOM4 look promising? For new
> projects, should I stick with polyfills that only offers compatibilities
> for older browser, and for future spec features, only use libraries that
> offer similar features but invent their own APIs, or should I track future
> specs and use these "unstable" polyfills?
>
> I'm torn on this subject. Would like to be enlightened.
>
> My obsession with future specs based tools doesn't come out of nowhere.
> Coffeescript used to offer sugars for es5. But then es2015 catches up, and
> it looks obsolete, since its user base is likely migrating to es over time.
> The same goes for GSAP vs Web Animations. So I have this sense of feeling
> that technologies without the blessing of specs/browser vendors are likely
> to be abandoned eventually. So instead of investing on custom designed
> APIs, I feel it's more sustainable to bet on spec APIs. What's your take on
> this topic?
>
> P.S. I called out some projects. I, by no means, slight these projects and
> their authors in any way. The projects usually offer some useful higher
> abstractions and the authors are all extremely talented and I respect them
> a lot. This is more from users point of view, and about how they should
> choose which technologies to use.
>

Re: Is polyfilling future web APIs a good idea?

[Brian Kardell]

On Tue, Aug 4, 2015 at 8:22 PM, Glen Huang  wrote:

There's actually a lot of questions in here, so let me take them one
at a time...

> On second thought, what's the difference between prollyfills and libraries
A major difference is that it's hard to translate libraries into
standards regardless of the approach they use.  We just don't do it.
We have libraries like jQuery that are as successful as we can ever
reasonably expect anything to get - it's inarguable that jQuery is
used more than any single browser, for example - and yet we didn't
just standardize jQuery.   What's more, we wouldn't for lots of
technical and political reasons.  jQuery wasn't made with becoming a
standard in mind and it didn't propose things in same standards sense
before hand or early -- a lot of the approach/style matter too (see
below).  Aspects of it could have been - jQuery has individuals
representing in standards committees (me, for example) and prollyfills
give us a way to do this - ecma, for example, produces a lot of
prollyfills as they go and actually get use and feedback before it's
way too late.

> exposed web APIs in a functional style (e.g., node1._replaceWith(node2) vs 
> replaceWith(node2, node1)? Or in a wrapper style like jquery does? Prefixing 
> APIs doesn't seem to be that different from using custom APIs?

It could be, but the further you get from the actual way it will be
used, the more we will debate on what will happen if you change its
surface.  A prollyfill is as close as we can approximate to the real
proposal without shooting ourselves in the foot.  It lets developers
and standards people work together, answer questions about uptake and
confusion, identify use cases and edgecases, etc.

>You might say the prefixing approach resembles native APIs more closely, but 
>when changing your code to use native APIs, modifying one character or several 
>doesn't really make much difference (they are the same if you find & replace), 
>as long as you have to modify the code.

Definitely not as simple if you change the whole pattern - asking
someone to grep an entire codebase is a bigger ask than a nice simple
pattern that lets you just say something like:

// Hey, our prollyfill matches native, now it's a polyfill!
HTMLElement.prototype.foo = HTMLElement.prototype._foo;



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Is polyfilling future web APIs a good idea?

[Glen Huang]

On second thought, what's the difference between prollyfills and libraries 
exposed web APIs in a functional style (e.g., node1._replaceWith(node2) vs 
replaceWith(node2, node1)? Or in a wrapper style like jquery does? Prefixing 
APIs doesn't seem to be that different from using custom APIs? You might say 
the prefixing approach resembles native APIs more closely, but when changing 
your code to use native APIs, modifying one character or several doesn't really 
make much difference (they are the same if you find & replace), as long as you 
have to modify the code.

Re: Is polyfilling future web APIs a good idea?

[Brian Kardell]

On Mon, Aug 3, 2015 at 9:07 PM, Glen Huang  wrote:
> Brian,
>
> prollyfills seems pragmatic. But what about when the logic of an API changes, 
> but not the name? The node.replaceWith() API for example is about to be 
> revamped to cover some edge cases. If the prollyfills exposed 
> node._replaceWith(), what should it do when the new node.replaceWith() comes? 
> Expose node._replaceWith2()? This doesn't seem to scale.
>

Why would it need to?  Just like any library, you import a version and
deal with incompatibilities when you upgrade?


> But I do see the benefit of prefixing in prollyfills. node.replaceWith() used 
> to be node.replace(). If we exposed _replace() earlier, we can swap the 
> underlying function with node.replaceWith() when we release a new version, 
> and old code immediately benefit from the new API. But over time, prollyfills 
> are going to accumulate a lot obsolete APIs. Do you think we should use 
> semver to introduce breaking changes? Or these obsolete APIs should always be 
> there?
>

Yes, I think authors will opt in to an API and that API may contain
breaking changes or backcompat changes, I think that's up to people
implementing and maintaining to experiment with.  Too early to say
what will be more successful, but I don't forsee things growing
forever - at some point people remove polyfills too in practice... In
theory you could use something like FT-labs polyfill as a service to
make any browser 'normalized' but that gets really heavy if it isn't
targeted and goes back too far in practice.  No one is even writing
polyfills for IE6 anymore - most don't even go back to IE8.


> And if we are going this route, I think we need blessing from the WG. They 
> have to promise they will never design an API that starts with the prefix we 
> used.

We have that in web components already (no native element will be a
dasherized name - in most practical terms, attributes too), for all
things CSS (-vendor-foo just has no vendor and becomes --foo) and when
you're talking about DOM - yeah, we dont have one, but no DOM will
contain an leading underscore, I can just about promise that without
any agreements - but I agree it'd be great if we just had one.



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Is polyfilling future web APIs a good idea?

[Glen Huang]

Brian,

prollyfills seems pragmatic. But what about when the logic of an API changes, 
but not the name? The node.replaceWith() API for example is about to be 
revamped to cover some edge cases. If the prollyfills exposed 
node._replaceWith(), what should it do when the new node.replaceWith() comes? 
Expose node._replaceWith2()? This doesn't seem to scale.

But I do see the benefit of prefixing in prollyfills. node.replaceWith() used 
to be node.replace(). If we exposed _replace() earlier, we can swap the 
underlying function with node.replaceWith() when we release a new version, and 
old code immediately benefit from the new API. But over time, prollyfills are 
going to accumulate a lot obsolete APIs. Do you think we should use semver to 
introduce breaking changes? Or these obsolete APIs should always be there?

And if we are going this route, I think we need blessing from the WG. They have 
to promise they will never design an API that starts with the prefix we used.

Let's say we write a prollyfills for the node.replace API. So our lib exposes 
node._replace
> On Aug 3, 2015, at 10:16 AM, Brian Kardell  wrote:
> 
> On Sun, Aug 2, 2015 at 9:39 PM, Glen Huang  wrote:
>> I'm pretty obsessed with all kinds of web specs, and invest heavily in tools 
>> based on future specs. I was discussing with Tab the other day about whether 
>> he thinks using a css preprocessor that desugars future css is a good idea. 
>> His answer was surprisingly (at least to me) negative, and recommended sass. 
>> His arguments were that
>> 
>> 1. the gramma is in flux and can change
>> 2. css might never offer some constructs used in sass, at least with very 
>> low priority.
>> 
>> I think these are good points, and it reduced my enthusiasm for future spec 
>> based css preprocessors. But this got me thinking about polyfills for future 
>> web APIs. Are they equally not recommended? Likewise, the APIs might change, 
>> and for DOM operations we should rely on React because the native DOM might 
>> never offer such declarative APIs, at least with very low priority. Do 
>> polyfills like WebReflection's DOM4 look promising? For new projects, should 
>> I stick with polyfills that only offers compatibilities for older browser, 
>> and for future spec features, only use libraries that offer similar features 
>> but invent their own APIs, or should I track future specs and use these 
>> "unstable" polyfills?
>> 
>> I'm torn on this subject. Would like to be enlightened.
> [snip]
> 
> TL;DR: Yes, I think they are good - really good actually, with some
> best practices.
> 
> CSS is a slightly different beast at the moment because it is not
> (yet) extensible, but let's pretend for a moment that it is so that a
> uniform answer works ok...
> 
> This was why I and others advocated defining the idea of/using the
> term "prollyfill" as opposed to a polyfill.  With a polyfill you are
> filling in gaps and cracks in browser support for an established
> standard, with a prollyfill you might be charting some new waters.  In
> a sense, you're taking a guess.  If history is any indicator then the
> chances that it will ultimately ship that way without change is very
> small until it really ships in two interoperable browsers that way.
> There's more to it than slight semantics too I think:  Polyfill was
> originally defined as above and now for many developers the
> expectation is that this is what it's doing.  In other words, it's
> just providing a fill for something which will ultimately be native,
> therefore won't change.  Except, as we are discussing, this might not
> be so.  Personally, I think this matters in a big way because so much
> depends on people understanding things:  If users had understood and
> respected vendor-prefixed CSS for use as intended, for example, they
> wouldn't have been much of a problem -- but they were.  Users didn't
> understand that and things shipped natively, so vendors had to adjust
> - things got messy.
> 
> Debates about this took up a lot of email space in early extensible
> web cg lists - my own take remains unchanged, mileage may vary:
> 
> It is my opinion that when possible, we should 'prefix' prollyfilled
> APIs - this could be something as simple as an underscore in DOM APIs
> or a "--property" in CSS, etc.  Hopefully this makes it obvious that
> it is not native and is subject to change, but that isn't the reason
> to do it.  The reason to do it is the one above:  it *may* actually
> change so you shouldn't mislead people to think otherwise - it
> potentially affects a lot.  For example, if something gets very
> popular masquerading as native but no one will actually implement
> natively it without changes - they are stuck having to deal with
> shitty compromises in standards to keep the web from breaking.  Also,
> what happens when devs "sell" a standard with the promise that it's
> going to be native and then we rip that rug out from underneath them.
> 
> For me then, following a nice pattern 

Re: Is polyfilling future web APIs a good idea?

[Brian Kardell]

On Sun, Aug 2, 2015 at 9:39 PM, Glen Huang  wrote:
> I'm pretty obsessed with all kinds of web specs, and invest heavily in tools 
> based on future specs. I was discussing with Tab the other day about whether 
> he thinks using a css preprocessor that desugars future css is a good idea. 
> His answer was surprisingly (at least to me) negative, and recommended sass. 
> His arguments were that
>
> 1. the gramma is in flux and can change
> 2. css might never offer some constructs used in sass, at least with very low 
> priority.
>
> I think these are good points, and it reduced my enthusiasm for future spec 
> based css preprocessors. But this got me thinking about polyfills for future 
> web APIs. Are they equally not recommended? Likewise, the APIs might change, 
> and for DOM operations we should rely on React because the native DOM might 
> never offer such declarative APIs, at least with very low priority. Do 
> polyfills like WebReflection's DOM4 look promising? For new projects, should 
> I stick with polyfills that only offers compatibilities for older browser, 
> and for future spec features, only use libraries that offer similar features 
> but invent their own APIs, or should I track future specs and use these 
> "unstable" polyfills?
>
> I'm torn on this subject. Would like to be enlightened.
[snip]

TL;DR: Yes, I think they are good - really good actually, with some
best practices.

CSS is a slightly different beast at the moment because it is not
(yet) extensible, but let's pretend for a moment that it is so that a
uniform answer works ok...

This was why I and others advocated defining the idea of/using the
term "prollyfill" as opposed to a polyfill.  With a polyfill you are
filling in gaps and cracks in browser support for an established
standard, with a prollyfill you might be charting some new waters.  In
a sense, you're taking a guess.  If history is any indicator then the
chances that it will ultimately ship that way without change is very
small until it really ships in two interoperable browsers that way.
There's more to it than slight semantics too I think:  Polyfill was
originally defined as above and now for many developers the
expectation is that this is what it's doing.  In other words, it's
just providing a fill for something which will ultimately be native,
therefore won't change.  Except, as we are discussing, this might not
be so.  Personally, I think this matters in a big way because so much
depends on people understanding things:  If users had understood and
respected vendor-prefixed CSS for use as intended, for example, they
wouldn't have been much of a problem -- but they were.  Users didn't
understand that and things shipped natively, so vendors had to adjust
- things got messy.

Debates about this took up a lot of email space in early extensible
web cg lists - my own take remains unchanged, mileage may vary:

It is my opinion that when possible, we should 'prefix' prollyfilled
APIs - this could be something as simple as an underscore in DOM APIs
or a "--property" in CSS, etc.  Hopefully this makes it obvious that
it is not native and is subject to change, but that isn't the reason
to do it.  The reason to do it is the one above:  it *may* actually
change so you shouldn't mislead people to think otherwise - it
potentially affects a lot.  For example, if something gets very
popular masquerading as native but no one will actually implement
natively it without changes - they are stuck having to deal with
shitty compromises in standards to keep the web from breaking.  Also,
what happens when devs "sell" a standard with the promise that it's
going to be native and then we rip that rug out from underneath them.

For me then, following a nice pattern where authors opt in and provide
whether or not to prefix is ideal.  Since authors opt in, just like
they do with a library and it can work in all browsers, it can
version, and it's way better than vendor prefixes on native.  Yes,
your code won't "automatically" run faster if it is implemented
natively- but depending on how far along the track you are, it might
be very long odds that it will ship just like that.  If you get very
lucky, your last version of "prollyfill" becomes "polyfill" and if a
site wants to use the native, they can tweak a single arg and it's off
to the races.

Realistically, I think that prollyfills are probably the only way to
strike the right balance of incentives and disincentives that allow
the standards community to do good things, create a good feedback loop
that developers can actually be involved in and measure something
experimental before we ship it.

-- 
Brian Kardell :: @briankardell :: hitchjs.com