I loved reading this document! One thing I found missing, though, was advice for library authors who use polyfills.

For instance, consider PouchDB. We ship various polyfills as part of the library: Promise, Map, Set, Object.assign, etc. In each case we do the "right thing" – we prefer the native implementation, and we ship the polyfill in such a way that it doesn't overwrite any globals (i.e. a "ponyfill").

But imagine that someone is using PouchDB, as well as Library B, Library C, and Library D, each of which does the same thing and ships their own polyfills for Promise, Map, Set… We could avoid a lot of this bloat if each library merely shipped code using the bare Promise, Map, Set, etc., but it's difficult to do so in such a way that doesn't aggravate users who want something that "just works."

So most library authors seem to take the path of least resistance, and just ship their own polyfills to avoid any burden on their users. Hence: library bloat.

Now, I'm sure PouchDB could ship two versions of its codebase using some Babel/Rollup/whatever transform to inject polyfills for one version but not the other, and we could advise our advanced users to use the bare version and then Bring Your Own Polyfill, but this is a lot of extra effort and I fear nobody would do it unless 1) there were clear instructions for the various module bundlers – Browserify/Webpack/Rollup/Closure/RequireJS/etc. – on how to do this correctly, and 2) a large number of library authors actually got on board and did it. It may also require some kind of ad-hoc standard, e.g. a "polyfills" field inside of package.json laying out exactly which globals are required. I dunno.

Without asking folks who are more familiar with bundlers/transpilers than I am, I'm not sure what advice exactly to give. But it may be worthwhile to at least acknowledge the problem in the document. (Unless you have some ideas for how to crack this nut, which I don't. 😃)

/cc @TheLarkInn @hzoo @Rich-Harris who have probably thought about this a lot more than me.