Re: Prollyfills and the global namespace / multi-fills

On Fri, Jul 5, 2013 at 10:41 AM, Clint Hill <clint.hill@gmail.com> wrote:
>
>
> On 7/4/13 1:39 AM, "François REMY" <francois.remy.dev@outlook.com> wrote:
>
>>I'm totally with you that the fact a spec can't be prollyfilled is not a
>>good excuse not to build a JavaScript prototype: as you said, this is an
>>experience you can learn a lot from, I'm totally convinced of that. But,
>>as
>>you note, it should be clear to people this is not something they can use
>>in
>>production. In the interoperability bridge team, they use this disclaimer:
>>"Note that as with all previous releases of HTML5 labs, this is an
>>unsupported component with an indefinite lifetime. This should be used for
>>evaluation purposes only and should not be used for production level
>>applications."
>
> This might be my own personal experience talking and not rational
> thinking, however I fear this type of treatment on prollyfills will create
> an immediate and implicit "toy" characteristic. If you put this disclaimer
> on your libraries I believe no one will use them. And that is exactly
> where we don't want to go. We'd rather there be healthy usage and a
> constant feedback cycle. And competing implementations to help influence
> the standardization. I worry disclaimers like this are counter productive
> to that.
>
>

Imagine we had a caniuse sort of repo for a minute, because this
actually illustrates why I have been using that as an example of
something we should have.

Just like caniuse has information about the state of the spec, whether
there are prefixed implementations or flagged implementations, etc - I
think it is kind of the same for prollyfills.  I think, we are really
just trying to change the standards iteration process to decouple
things from the browser and, maybe, help discover or illustrate
missing/useful underlying primitives in the process.

There are a number of places where you can add value at either the
standards end or at the developer end.  Something like my prollyfills
for selectors L4 links provides use in a couple of vectors: First, it
lets users try it and see if they understand it - maybe comment about
it or propose alternatives.  In real life, I've already seen that
pretty much everyone who says "hey, that could be useful" is actually
surprised at what it really does - it's not what they thought at all.
In a quick afternoon back and forth with someone recently I wrote two
alternatives which were both potentially more inline with what people
were expecting for value.  At the other end, you could actually view
inputs and outputs from the specs and find the same sorts of
illuminating discussions that generally only happen during or after
implementation.  You can also write reftests and gain agreement on the
expected outcomes and while the tests themselves can't be used because
they use a different (prefixed) name - it's pretty simple to turn them
into the real thing.

Things like Marcos' are really valuable for informing the spec and
implementation, very high fiedlity to the spec... But can't currently
deliver devs a lot of actual value - it's missing stuff beneath.  It's
useful for experimental purposes and you can write stuff for maybe N
browsers - but you can't probably put it right in production.  As with
things that are experimental, you kind of make the unwritten agreement
that you'll track and adjust your use if you plan to eventually put it
out to prod - maybe eventually as a polyfill, etc.  These sorts of
things really need something of a disclaimer like the one Marcos
added.

Neither is really right or wrong IMO - they are just different.

I think the best case scenario is to avoid some of the worst footguns
and develop good patterns that promote a healthy lifecycle that
accommodates both - I think that is stuff for us to help develop,
define and evangelize.



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

Received on Friday, 5 July 2013 15:46:26 UTC