Polyfills是一种保证使用现代代码的绝佳办法，同时还能支持旧版浏览器。但是目前polyfills使用起来很困难，因此我们开发了一种全新的服务以便简化其使用方法。在此，邀请读者使用并改进它。
挑战
下面是我们正在尝试解决的一些问题：
开发者对哪些特性需要使用polyfill不是很清楚。例如你在某个旧版本的IE浏览器（因为你有很大数量的用户还在使用它）中载入网站，发现网站不工作，你不得不慢慢调试来搞清楚到底是哪个特性导致了这个问题。有时候问题很清楚，但大多时候并非如此，尤其是旧版浏览器往往缺少好的开发者工具的时候。
针对每个特性都有很多polyfill可供选择。很难确定哪一个能最忠实地模拟缺少的特性。
有一些大的polyfill捆绑着很多你不需要的polyfill，例如ES6，它全面覆盖了一系列的特性集。为了解决一个简单的问题而向浏览器植入所有的这些代码其实是不必要的。
较新版本的浏览器不需要polyfill，但一般来说polyfill可用于所有种类的浏览器。虽然这是为了提高与旧版浏览器的兼容性，但这也降低了新版浏览器的性能。我们不愿意做出这种妥协。我们更愿意在原本不具备某个特性的浏览器上使用polyfill。
我们的解决办法：以polyfill为服务
为了解决这些问题，我们开发了polyfill服务。这有点像是验光师先对你的眼睛验光检查，然后针对你的视力问题配置眼镜。我们将对浏览器做同样的事情。下面解释它是如何工作的：
开发人员在他们的页面中插入一个脚本标记作为导入polyfill服务的端点。
该服务分析浏览器的user-agent标头和必需特性列表（或是使用一个默认的可使用polyfill服务的列表），然后搭建浏览器所需的polyfill列表。
按照正确的依赖顺序表定制polyfill。
通过CDN 压缩服务包并提供服务（对此我们衷心感谢Fastly的支持）。
我们真的需要这个解决办法吗？你可以这样思考：Modernizris是一个大型的特性检测包，所有对它的合理使用都得益于自定义的安装配置，但是很大数量的Modernizris用户仅仅使用了它的默认安装，这常常是来自于 cdnjs.com 或是 html5boilerplate 的某个部件。但是，如果不使用Modernizris的特性检测功能，那你为什么安装这个工具呢？可能你误解了库文件的功能，单纯地以为Modernizris会“修补东西”？不得不承认，第一次听到这个名字的时候笔者正是这样想的，以至于后来发现Modernizris不但没有起到作用，反而拖了现代浏览器的后腿，笔者感到有些失望。
然而，Polyfill服务却是真正起到了作用。不想花时间去深入了解旧版本浏览器缺点的你一点儿错也没有。让别人先弄明白问题所在，然后我们在不需要了解细节的情况下就能直接受益。
如何使用
最简单的使用情况是：
<script src="//cdn.polyfill.io/v1/polyfill.min.js" async defer></script>这包含了我们默认的 polyfill设置。这个默认设置是我们人工挑选的一个特性列表，我们认为这个列表中所包含的特性对于现代网络开发来说不可或缺，而且相对应的polyfill相当小且十分精确。如果你想指定添加某个polyfill特性，只需要这么做：
<!-- Just the Array.from polyfill --><script src="//cdn.polyfill.io/v1/polyfill.min.js?features=Array.from" async defer></script><!-- The default set, plus the geolocation polyfill --><script src="//cdn.polyfill.io/v1/polyfill.min.js?features=default,Navigator.prototype.geolocation" async defer></script>
如果有必要在解析自己的代码之前加载polyfill的话，你可以移除async和defer属性，或是使用一个脚本加载器（不需要任何polyfill的加载器！）
测试与文档特性支持
我们所支持特性的完整表格在特性矩阵中。为了搭建这个网格，我们使用了Sauce Lab的自动测试平台，它截获了polyfill在每个浏览器中的测试，然后记录结果。
User-Agent 分析？ 你确定？
是的，我们确定。下面是为什么UA分析要比特性检测好的原因：
在一些情形中，针对同一特性我们有多个polyfill可供选择，这是因为一些浏览器提供非顺从实施方式，因此只需要你敲打成型即可，而其他浏览器则没有提供任何的实施。但若是有UA检测，你能够选择相应的polyfill。
有了UA检测，第一个HTTP请求就能直接由polyfill代码应答。如果我们使用了特性检测，第一个请求将会为特性检测代码服务，而第二个请求则需要用于获取特定的polyfill。
几乎所有的大型网站都使用UA检测。这并不是说与之相关的特征就是不好的。显然，好的UA规则要比差劲的UA规则更难编写。而且我们并没有排除借助特性检测使用该服务的可能。
从IE10+浏览器开始，所有浏览器就原生提供了Base64编码、解码方法，不仅可以用于浏览器环境，Service Worker环境也可以使用。方法名就是 atob 和 btoa ，具体语法如下：
IE8/IE9的polyfill
当下，仍有不少PC项目还需要兼容IE9，所以，我们可以专门针对这些浏览器再引入一段ployfill脚本或者一个JS文件即可。
[if IE] 表示所有IE浏览器，由于IE10+浏览器已经放弃了著名的IE条件注释的支持，Chrome等浏览器本身就不支持这个IE私有语法，因此，很天然的，上面一段script引入只在IE9-浏览器下有效。而我们本来就希望只IE8，IE9浏览器引入ployfill，于是正好完美衔接上。
也就是原生支持atob和btoa方法的浏览器认为就是一段无需关心的HTML注释，不支持atob和btoa的IE9及其以下浏览器则会加载我们的base64-polyfill.js，使浏览器也支持 window.btoa 和 window.atob 这个语法。
开源的 base64.js ，使用很简单，浏览器引入该JS文件，然后Base64编码这样：
解码就调用 decode 方法，如下：
ES5 及更高版本直接用 String 对象自带的 trim() 方法就可以了。
var str = ' hello world 'console.log(str.trim())
再低版本的需要先自行引入 polyfill：
if (!String.prototype.trim) {String.prototype.trim = function () {
return this.replace(/^[\s\uFEFF\xA0]+|[\s\uFEFF\xA0]+$/g, '')
}
}
