Offline transcript

Hey everyone... Clint and I have a lot of in-depth discussions online via
skype and I always feel like they are lost and then only later realize that
others weren't included in the details of them.  Clint and I decided to
post the transcript of this one and invite other comments re: forward
compatibility of prollyfills and author prefixing:

[12/18/12 12:45:30 PM] bkardell: prollyfills... you agree that they should
be forward compat via prefix?
[12/18/12 12:56:27 PM] Clint Hill: i'm not sure
[12/18/12 12:57:29 PM] Clint Hill: to be more clear: Yes. But I have
reservations about yet-another-prefix
[12/18/12 1:00:54 PM] bkardell: oh boy
[12/18/12 1:01:21 PM] bkardell: but dude... the rationale of all of this
was that the problem with prefixes are that they are tied to a browser
implentation
[12/18/12 1:01:41 PM] bkardell: how can you prollyfill something that is so
early as if it were native - you just cant
[12/18/12 1:02:11 PM] bkardell: dude - marcos tweeted that article, did you
make any adjustments to it after our convo?
[12/18/12 1:02:42 PM] Clint Hill: no ....

I was going to write something about the lifecycle in a different post.
[12/18/12 1:03:01 PM] Clint Hill: the prefix question feels like the guns
question. The answer to the problem of guns is not "more guns"
[12/18/12 1:03:51 PM] Clint Hill: if we come up with "x-" that certainly
fixes the browser coupling. But it does nothing to change the problem of
"prollyfill -> native" transition.
[12/18/12 1:04:18 PM] bkardell: I dont know why that is a problem per-se
[12/18/12 1:04:42 PM] bkardell: if you write with a prollyfill and it works
for you your biggest concern should be that it doesn't break out from
underneath you
[12/18/12 1:04:59 PM] bkardell: given browser improvements, it will
generally speaking, only get better over time
[12/18/12 1:05:28 PM] bkardell: when a stable API is available and a
prollyfill emerges, you could port it to a pollyfill if you desired
[12/18/12 1:05:36 PM] bkardell: and the pollyfill should be reasonably easy
to write
[12/18/12 1:05:52 PM] bkardell: since it is basically just an unprefixing
of the last known good prollyfill
[12/18/12 1:06:06 PM] Clint Hill: that code change I guess is what I call
the "problem"
[12/18/12 1:07:38 PM] bkardell: I totally disagree with that assessment
unless you can come up with a magic way to guarantee that the native API
will match your original - which you can't
[12/18/12 1:08:03 PM] Clint Hill: wait ...
[12/18/12 1:08:10 PM] bkardell: you also cant guarantee that there are no
surface changes between version 1.0.0 and version 1.1.0 of your prollyfill
[12/18/12 1:08:17 PM] Clint Hill: "native API will match your <prollyfill>"
????
[12/18/12 1:08:20 PM] bkardell: that's why prollyfills rock
[12/18/12 1:08:32 PM] bkardell: ok, let's take an example from history
[12/18/12 1:08:42 PM] bkardell: "matches" in css selectors level 4
[12/18/12 1:09:08 PM] bkardell: this has been implemented in almost every
browser now as a prefixed thing called 'any'
[12/18/12 1:09:21 PM] bkardell: so msAny, webkitAny, etc
[12/18/12 1:09:55 PM] bkardell: and the surface might not ultimately match
the signature of the draft either
[12/18/12 1:10:08 PM] bkardell: a draft was more or less available in 2000
[12/18/12 1:10:20 PM] bkardell: what we ultimately get in 2014 or beyond
won't match that
[12/18/12 1:10:58 PM] bkardell: but we could have had a prollyfill in 2000
 and that would have been great - it could have evolved names, signatures,
versions, etc - all without problem and without risk of it breaking
[12/18/12 1:12:59 PM] bkardell: prollyfills let us help evolve standards
by: a) seperating them from the browser b) making them author-opt'in and
versioned c) keeping our code working into the future without risk of it
breaking -- all of these d) widen the audience and potential use-cases
where we can use them way beyond what can be done in the traditional model
[12/18/12 1:24:40 PM] bkardell: no?
[12/18/12 2:22:19 PM] Clint Hill: sorry - stepped away to a meeting
[12/18/12 2:27:58 PM] bkardell: np... you can respond whenever :)
[12/18/12 2:32:00 PM] Clint Hill: so agreed on all your points. none of
your points however presume the need for a prefix. the matches/any example
is a historical artifact to point out as issue that prefixes bring - but
does not insinuate the need for prefixing now.

prollyfill can use "desired to be" syntax without the need of a prefix. the
prollyfill can introduce the syntax as it will be and a library to assure
that syntax works (parser plays this role). upon native implementation it's
a matter of "dropping the parse & script".
[12/18/12 2:37:18 PM] bkardell: wait ... huh?
[12/18/12 2:37:38 PM] bkardell: there can be only one :any() or :has()
signature - right?
[12/18/12 2:37:49 PM] Clint Hill: yes
[12/18/12 2:38:01 PM] bkardell: you agree that you cannot guarantee what
that will be until it arrives?
[12/18/12 2:38:03 PM] Clint Hill: 1 that is drafted and desired to be
prollyfilled
[12/18/12 2:38:20 PM] Clint Hill: today you cannot
[12/18/12 2:38:24 PM] Clint Hill: but with a prollyfill you can
[12/18/12 2:38:29 PM] Clint Hill: that's what we want to change
[12/18/12 2:38:31 PM] bkardell: so what happens when you do :any() and then
they actually implement a native :any with a different signature or even
meaning?
[12/18/12 2:38:44 PM] Clint Hill: you did so without a prollyfill framework.
[12/18/12 2:38:52 PM] Clint Hill: that's what happens without nExt Web.
[12/18/12 2:39:18 PM] Clint Hill: WITH a prollyfill framework you end up
working towards a signature
[12/18/12 2:39:26 PM] bkardell: yes, absolutely
[12/18/12 2:39:38 PM] bkardell: towards being the key word there
[12/18/12 2:39:46 PM] Clint Hill: so ... if that's agreeable ... what
benefit does a prefix bring?
[12/18/12 2:41:11 PM] bkardell: man I just dont get where you are getting
this from suddenly - I so thought we were on the same page with this
[12/18/12 2:41:50 PM] bkardell: "any" as an example... I could have two
competing drafts of it
[12/18/12 2:42:04 PM] bkardell: they have different signatures
[12/18/12 2:42:23 PM] Clint Hill: ok - stop right ther
[12/18/12 2:42:33 PM] bkardell: one of them (or maybe even none of them)
will eventually get a native impl
[12/18/12 2:42:41 PM] Clint Hill: yah - but stop
[12/18/12 2:42:42 PM] bkardell: you cant know which
[12/18/12 2:42:43 PM] bkardell: ok go
[12/18/12 2:44:30 PM] Clint Hill: 2 prollyfills - built and delivered with
nExt Web framework that provides devs tools to author and publish the work.
Drafts/docs/standards lifecycle etc.

What's important is not how to "prefix" these rather what's important is
that the consuming author has a way to point to the prollyfill
implementation/version they want.

consuming authors would _always_ use the word "any". the only thing they
opt-in with is to point to an implementation and version ---- just like
Hitch.
[12/18/12 2:44:59 PM] Clint Hill: IMO - we can do it all without a prefix.
[12/18/12 2:45:04 PM] bkardell: ok so look
[12/18/12 2:45:11 PM] bkardell: you have something that looks like this
[12/18/12 2:45:30 PM] bkardell: :any(basicSelector...)
[12/18/12 2:45:36 PM] bkardell: and another that looks like this
[12/18/12 2:46:19 PM] bkardell: :any(state,basicSelector...)
[12/18/12 2:46:46 PM] bkardell: they have different signature and different
purpose
[12/18/12 2:47:07 PM] Clint Hill: ok - 2 diff prollyfills - 2 diff
signatures
[12/18/12 2:47:09 PM] bkardell: now some day in the future we get an any
[12/18/12 2:47:24 PM] bkardell: it may be one of those - or even a third
thing
[12/18/12 2:47:29 PM] Clint Hill: yes
[12/18/12 2:47:45 PM] bkardell: how on earth do you automatically upgrade
without breaking?
[12/18/12 2:48:01 PM] Clint Hill: :)

how does prefixing "fix" it?
[12/18/12 2:48:07 PM] bkardell: serious?
[12/18/12 2:48:34 PM] bkardell: if you wrote your code today prefixed,
tomorrow it is still prefixed... if it worked yesterday, why would you
assume it wouldn't work today?
[12/18/12 2:48:56 PM] bkardell: if you used <object> for video yesterday -
it still works eventhough we now have <video>
[12/18/12 2:49:17 PM] bkardell: if you used jquery - it still works even
though we have qsa/find
[12/18/12 2:49:43 PM] bkardell: not only that, but in both of those cases -
your code from a few years ago actually got more efficient underneath you
[12/18/12 2:50:18 PM] bkardell: that's part of the problem with prefixes
today -- prefixes are experimental and they _do_ break underneath u
[12/18/12 2:50:36 PM] bkardell: how many css 3 tutorials have you looked at
that are now borked
[12/18/12 2:50:51 PM] Clint Hill: I write my code today: x-any(state,
selector)
tomorrow it's implemented.
my code tomorrow still uses prollyfill due to x-any.
it won't use native until I drop the "x-".

right?
[12/18/12 2:51:41 PM] bkardell: right
[12/18/12 2:51:57 PM] bkardell: and potentially match the API deltas or
implementation/draft deltas
[12/18/12 2:52:13 PM] bkardell: x- is not standard
[12/18/12 2:52:33 PM] bkardell: in most cases, it is not even close early
on - it is a mistake to pretend otherwise
[12/18/12 2:53:05 PM] bkardell: do you point to jquery latest or the
version of jquery you used when you wrote your site?
[12/18/12 2:53:37 PM] bkardell: most people use the version they actually
tested with
[12/18/12 2:54:10 PM] Clint Hill: counter idea -----

If I write my code today: any(state, selector)
If I include a lib for: any-brian-prollyfill.js it uses 1 of the 2
competing prollyfills
tomorrow it's implemented (I'm lucky I chose the good one).
tomorrow I drop the lib: any-brian-prollyfill.js

1 code change in both cases but the implementation code is unchanged.
[12/18/12 2:54:11 PM] bkardell: we need to post this log somewhere for
others to read :)
[12/18/12 2:54:48 PM] Clint Hill: if I happen to choose the loser - well
that's a diff story right? changes everything anyways. prefixed or not
[12/18/12 2:55:01 PM] bkardell: chances are you will pick the loser
[12/18/12 2:55:45 PM] bkardell: because there will be competition and
improvement... by sheer statistics it is impossible to assume that the vast
majority of code will not choose the loser
[12/18/12 2:58:25 PM] Clint Hill: right - so there's code change beyond
prefixing right?
[12/18/12 2:58:29 PM] Clint Hill: (in losing case)
[12/18/12 2:59:01 PM] Clint Hill: So to argue that we want prefixing in
order to save you from that kind of code change doesn't make sense to me.

So again: What benefit does prefixing bring?
[12/18/12 3:09:43 PM] bkardell: in the losing case, your code still
works... in the winning case your code still works... even in the most
winning case there might still be edge cases in the to-native shift that
could cause your site to break
[12/18/12 3:10:26 PM] bkardell: am I missing something?
[12/18/12 3:11:30 PM] bkardell: :x-any is pointing to a prollyfill ...
note, not a pollyfill which has a very reasonable chance of going pretty
smoothly in an auto-upgrade
[12/18/12 3:12:18 PM] bkardell: if we drop :x- and just use :any, then you
have some magic saying "if it's there use that" ... the vast majority - and
I mean the _vast_ majority will break as native comes along... am I wrong?
[12/18/12 3:15:59 PM] Clint Hill: let me say so that you feel better - i
totally agree and understand.

I'm simply arguing that IMO we could do all this without a prefixing
solution. I think Hitch was the right path with the ability to
delcaratively point to an implemention for a hitch. (i know we used
prefixes too).
[12/18/12 3:16:54 PM] Clint Hill: in other words I think this would be
ideal:


use "any()"
point to prollyfill
when native
drop pointer to prollyfill
maybe point to polyfill
[12/18/12 3:17:29 PM] Clint Hill: the risk is - I chose the really shitty
one and need to change signatures etc.

that's still opt-in.
[12/18/12 3:18:26 PM] bkardell: hmmm...
[12/18/12 3:18:50 PM] Clint Hill: IMO - prefixing adds complexity without a
benefit.
[12/18/12 3:19:23 PM] bkardell: ok, let's imagine a flow for a second in
which :matches was there in 2000 as a prollyfill, unprefixed
[12/18/12 3:19:45 PM] bkardell: so we have some import or something
indicating that there is a prollyfill
[12/18/12 3:20:35 PM] bkardell: 15 years go by and now we have a native
:matches which either has the same signature and does something different -
or has a different signature altogether
[12/18/12 3:21:15 PM] bkardell: my import or whatever is still there...
which one gets used?
[12/18/12 3:21:26 PM] bkardell: native or the fill I wrote against?
[12/18/12 3:24:19 PM] Clint Hill: well ... because I've painted myself into
this corner .... the prollyfill
[12/18/12 3:24:30 PM] Clint Hill: and the only way to get native is to
"drop" the fill.
[12/18/12 3:24:47 PM] bkardell: so fill overrides native..? that feels
problematic to me
[12/18/12 3:25:07 PM] bkardell: it will also cause headaches for anyone
trying to read code in the future
[12/18/12 3:25:16 PM] Clint Hill: only if you feel "opt-in" means until big
brother browser bumps me out.
[12/18/12 3:25:33 PM] Clint Hill: opt-in to me means "i declare it this way
so do it this way"
[12/18/12 3:25:51 PM] bkardell: hmm
[12/18/12 3:26:08 PM] Clint Hill: we have said "opt-in" .... so maybe there
is a confusion on my part
[12/18/12 3:26:18 PM] bkardell: opt-in to me means "i declare it this way
so do it this way"
[12/18/12 3:26:24 PM] bkardell: I fully agree with that
[12/18/12 3:26:30 PM] bkardell: that is my point actually
[12/18/12 3:26:51 PM] Clint Hill: seems to me that prollyfill wins in the
native vs. fill question.
[12/18/12 3:26:52 PM] bkardell: and I think the implication the other way
round is more convoluted
[12/18/12 3:27:33 PM] bkardell: if I was reading something with :matches
right now - I expect it to match the :matches I know - with all of the
signature,rules and subtlety
[12/18/12 3:27:43 PM] bkardell: I dont expect to have to go hunting for an
import to find what it does
[12/18/12 3:27:55 PM] bkardell: but if I see :x-matches ... I know what to
do
[12/18/12 3:28:29 PM] Clint Hill: hmm
[12/18/12 3:28:34 PM] Clint Hill: i fully agree
[12/18/12 3:28:45 PM] bkardell: i see easily that it is from a specific
early fill - even which version
[12/18/12 3:29:09 PM] bkardell: and figuring out an upgrade path (if I even
care for one) should be totally documented - perhaps even scriptable
[12/18/12 3:31:29 PM] Clint Hill: hmmm
[12/18/12 3:31:33 PM] Clint Hill: really though?
[12/18/12 3:31:53 PM] Clint Hill: the prefix gives you all that info?
[12/18/12 3:32:05 PM] bkardell: the prefix tells you that it is imported
[12/18/12 3:32:13 PM] bkardell: some kind of import has to tell you which
version
[12/18/12 3:32:43 PM] bkardell: given that, you should be able to pull up
the draft and see the state of it
[12/18/12 3:33:30 PM] bkardell: mapping that to what was really done should
be doable...
if you can do it once, there is at least a chance you can lay down rules to
preprocess upgrade others
[12/18/12 3:41:00 PM] bkardell: regardless of whether you can script it -
the pattern gives you the information you would need to understand how it
works in its current state - and if one of those became native it should
include a link to the current draft which gives you everything you need to
upgrade should you choose to do so
[12/18/12 3:41:30 PM] bkardell: the other nice thing about that is that it
doesn't prevent you from keeping your old code around while starting to
introduce the native version
[12/18/12 3:41:55 PM] bkardell: :x-matches
and
:matches

can coexist in the interim, which is really helpful if you are upgrading

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