Re: conventions for prollyfills

On Sep 25, 2013 10:44 AM, "Andrea Giammarchi" <andrea.giammarchi@gmail.com>
wrote:
>
> I think there's no such thing as real interoperability between different
modules, even if exposing similar APIs.
>
> A classic case is Zepto, claiming to be a sort of drop-in replacement for
jQuery but AFAIK and IIRC does not pass all jQuery tests cases/suite.
>
> "You", as developer, don't want @ANY/DOMLibrary to do the job, you want
jQuery or Zepto or maybe you just want `function
$(c,p){return[].slice.call((p||document).querySelectorAll(c))}` 'cause
`$('select').forEach()` is all you need.
>
> A thin abstraction able to expose only fewer methods and grant these will
work as expected from jQuery/Zepto user expectations would be another
module/library that could fit into the @ANY/DOMish concept but will
inevitably be a module a part with its repo, wrappers, etc etc.
>
> About Promises? I'd use the one that has been promoted, maintained, and
influenced ECMAScript the most (regardless the fact I don't personally like
Java/Scala influence in JavaScript), the one [in here](
http://promises-aplus.github.io/promises-spec/), since that's gonna be the
closest to future standard/implementation.
>
> I would never recommend any other library so `@ANY/Promisesish` might be
seen as a disaster prone approach (I mean, promises are in charge of
business logic, not just a couple of CSS transitions ;-) )
>
> My 2 cents
>
>
>
> On Wed, Sep 25, 2013 at 10:25 AM, François REMY <
francois.remy.dev@outlook.com> wrote:
>>
>> > As archive for anything strictly web related, bower is what npm stays
>> > for node.js.
>> >
>> > http://bower.io/
>> >
>> > Most if not all modules in there are based indeed in RequireJS and AMD
>> > where both solved the "don't want to load many times the same thing" a
>> > while ago and no prollyfill is needed ;-)
>> >
>> > You might use both services together or just bower or just requirejs
>> > configured for your own needs.
>>
>>
>> That looks great. I guess it solves the versioning problem, if polyfills
expose their modules correctly.
>>
>> There's still the open question of allowing your code to work with
multiple polyfills for the same web feature, and not just one of them. We
may have to think about that.
>>
>>
>>
>> Maybe we should just propose modules to have an alias like
"@ANY/Promise" in addition to their real name, so that authors can choose
to require either a certain kind of Promise polyfill, or just any kind
using "@ANY/Promise". That way, people can just do things like:
>>
>> #   require.specified('@ANY/Promise') ? require('@ANY/Promise') :
require('promise-lib-2')
>>
>> What do you think?
>>
>>
>>
>> This is kinda the "RequireJS global namespace".

>
>
yeah, I think perhaps I have been just slightly misunderstood.. we have
talked about a modernizeresque thing and a caniuse style repository.  it
would be in that vein that I am asking. my question doesn't presuppose any
technical solution and would recommend the best solution per the draft,
assuming it is ready.  if there was a more up to date, complete dist I
would favor that.