MDN-RFC-001: MDN wiki pages shouldn’t be a distributor of polyfills
Polyfills are a valuable part of Web architecture, because they promote the adoption of new features during the implementation process. However, polyfills can also create problems for standardization efforts and therefore for the future of the Web.
MDN authors and distributes polyfills as part of many reference pages. Examples
- The UX is terrible: The polyfills are distributed in the wiki page inside the usual <pre> code blocks which are normally used for static code examples and create a giant blocks of code you normally don’t want to read, but need to copy & paste into your project in order to make use of the polyfill.
- We can’t maintain them: The MDN staff contributors and the core community lacks knowledge and time for of looking after changes to polyfills. Code of polyfills can be really complicated as it implements functions and algorithms described in e.g. the ECMAScript specification or needs to handle weird edge cases. The code aims to be correct and fast, which can be tricky, too. There are bugs filed against MDN polyfills; they remain unresolved.
- Translations outdate, too. I haven’t even looked at how bad polyfills are on outdated wiki translations. (shudder)
We do not conform to the advice for polyfill distributors from the W3CTag:
- We don’t check if we host bad polyfills that are hurting the web. They’re in the wiki and editable at any time.
- We do track spec changes more or less, but we are unable to update the polyfills accordingly.
- We’re not a CDN for polyfills, we don’t bundle them (someone apparently started doing that for us), nor can we guarantee any integrity, or checksums, caching, or anything the like.
- We should remove polyfill code blocks from the wiki pages.
- They need to live in a repository where we can guarantee that we’re conforming to the W3CTag polyfill distribution guidelines (see above).
- We still want to offer polyfills to our readers but we should link to a trusted polyfill source rather than providing our own untrusted ones inline.
- We should investigate if it’s worth creating our own repository (mdn/polyfills) for which we’ll create a community that cares about polyfills, or if we start partnering and linking to existing communities and services like https://polyfill.io or others.