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 <bkard...@gmail.com> wrote: > > On Sun, Aug 2, 2015 at 9:39 PM, Glen Huang <curvedm...@gmail.com> 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
