Re: conventions for prollyfills

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".
>