W3C home > Mailing lists > Public > public-nextweb@w3.org > September 2013

Re: conventions for prollyfills

From: Andrea Giammarchi <andrea.giammarchi@gmail.com>
Date: Wed, 25 Sep 2013 10:00:13 -0700
Message-ID: <CADA77mh=SLV37U9KYVpKbPz6V9UTbnQ5WTVsMk2ce+T4Xu=zbg@mail.gmail.com>
To: François REMY <francois.remy.dev@outlook.com>
Cc: Brian Kardell <bkardell@gmail.com>, "public-nextweb@w3.org" <public-nextweb@w3.org>
As archive for anything strictly web related, bower is what npm stays for


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.


On Wed, Sep 25, 2013 at 9:55 AM, François REMY <
francois.remy.dev@outlook.com> wrote:

> > [polyfills end up shipping the same base-polyfills multiple times].
> > [we should have a way to reuse code in this case]
> I agree on the principle. I faced similar considerations at some point,
> wondering how multiple polyfills could reuse the same base infrastructure
> without harming performance or usability.
> I think the only reasonable option is to use a module system. This allows
> to refer to any polyfilled module, and since there are "module packers"
> available, it enables people to create a single js file tailored for their
> real usage, possibly combining multiple polyfills.
> That being said, the more I think about it, the more I believe the global
> namespace is a bad place to live in, even if they are simply cases where
> you need to be there.
> I would be tempted to wait until ES6 is finalized before making any
> recommendation, but I'm pretty sure someone will comes up with an
> ES6-module polyfill and maybe we should settle on that one. In the mean
> time, I would probably advise the use of AMD/RequireJS or something alike.
> Maybe we should recommend building modules for every polyfill from now on
> to favor code reuse across polyfills.
Received on Wednesday, 25 September 2013 17:00:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:54 UTC