什么是 Obsolete Webpack Plugin？

起源

20 世纪 90 年代初期，图灵奖得主 Tim Berners-Lee 缔造了计算机领域最伟大的发明之一 —— 万维网，实现了 HTTP 代理与服务器的第一次通信。他定义了 Web 的三大基础技术 URI、HTTP 和 HTML：URI 解决文档的路由表示和寻址；HTTP 协议解决文档的传输形式；HTML 解决文档的组织形式。从设计原则上说，他想到应当尽可能得降低文档开发和发布的复杂度，建立自由、开放和互联互通的分布式系统。网站部署方式应该简单、高效，且用户无需自行下载，仅仅通过 HTTP 代理软件 —— 浏览器，即可快速获得想要的资源。在这种设想下，Tim Berners-Lee 在自己的 NeXT 电脑（Steve Jobs 创立）上架设了世界上第一个 Web 服务器和 Web 浏览器，域名为 http://info.cern.ch/，延续至今。

zzpic19728.jpg

<figcaption >程序员小李</figcaption>

战争

随后，如大多数人所预见，浏览器被卷入了无休止的商业战争中，第一次浏览器大战、第二次浏览器大战、第三次浏览器大战……。在利益的趋势下，各种阴险狡诈的手段层出不穷：操作系统捆版浏览器、浏览器捆绑搜索引擎、浏览器捆绑门户网站、***病毒修改主页、流氓安全软件修改主页、国产“自主研发”浏览器骗补贴……。同时，竞争也催生了越来越多的程序员品种，前端工程师、网络工程师、PHP 工程师、优化工程师……；竞争加速了产品的改进与更替，事物优胜劣汰，Mosaic、Netscape、IE 浏览器相继死去，安全、美观、高性能的浏览器脱颖而出；竞争加速了技术的迭代与进步，无数的排版引擎、脚本解释引擎应运而生，KHTML、Webkit、Trident、Gecko、Blink、Presto……，Chakra、Carakan、JavaScriptCore、SpiderMonkey、V8……。不得不说，没有战争，没有竞争，就没有现在前端圈的繁荣与繁华。

<figcaption >浏览器们放学约架</figcaption>

革命

然而，事情并非这么顺利，竞争与迭代带来了很多兼容性遗留问题。新型浏览器为了表示它们完全支持旧浏览器提供的特性，在 UA 标志上动手脚，伪装成目标浏览器，并增加自己的独特标志。浏览器厂商为了提升市场份额，以差异化为准则不断改进产品，提升竞争力，却没有一套统一的标准来约束基础技术架构。为此，以 Tim Berners-Lee 为首的人在 1994 年创建了非营利组织 W3C，作为中立机构，致力于 Web 标准化的制定，指导浏览器正确地工作，推动技术稳定有序地发展。但是，历史总是在曲折中前进，其中有一段时间 W3C 甚至剑走偏锋，意图放弃 HTML 转而推广 XHTML，受到厂商和用户的一致反对。因此，由 Opera、Mozilla 基金会、苹果这些浏览器厂商成成了 WHATWG 工作组，继续编写和扩展 HTML 标准。直至今天，W3C 和 WHATWG 两个机构同时在运作。WHATWG 制定的标准称为 Living Standard，W3C 制定的标准成为 Recommendation；WHATWG 只负责跟进最新的标准，W3C 会对历史版本标准进行归档；WHATWG 制定的标准更加激进，W3C 只提供成熟、稳定且大部分已经被浏览器实现的标准；WHATWG 社区更加活跃，W3C 会复制粘贴他们的成果。另外，即使有标准的制定和约束，但并非强制性要求，浏览器厂商可以根据自己的情况选择性支持其中之一。

<figcaption >W3C/WHATWG 拳打脚踢</figcaption>

危机

唯物辩证法指出，一切存在的事物都由既相互对立、又相互统一的一对矛盾组合而成：标准制定者与浏览器开发者、浏览器开发者与 Web 开发者、Web 开发者与 Web 用户群体。标准制定者抱怨浏览器开发者不按照他们所制定的标准来实现，后者抱怨前者太过偏激、草率；Web 开发者抱怨浏览器开发者解析执行代码效率过低，后者抱怨前者调用姿势错误；Web 用户群体抱怨 Web 开发者写的界面太丑、交互不合理、BUG 太多，后者抱怨前者用户行为诡异、不按常理出牌。虽然说矛盾推动了技术的发展，但同时也带来了更大的危机和冲突。浏览器各种功能和特性的差异化给 Web 开发者带来了极大的困扰与痛苦，不得不采取各种 hack 手段、兼容手段，让代码在任一浏览器内无差错执行。开源社区也涌现了大量的解决方案，致力于抹平浏览器之间的差异。core-js 基于 ES3 的语法提供 ES5、ES2015+ 的特性 Polyfill；Autoprefixer 基于 caniuse-db 来决定是否添加浏览器私有样式前缀；Babel 基于 compat-table 来编译高阶语法到低阶语法；Browserslist 基于 BrowserStack 来统计市场份额以及提供浏览器产品列表。即使如此，仍存在一些不可抗力因素，使得 Web 开发者没有办法弥合或彻底消除这些差异。比如，Service Worker、Web Worker、WebAssembly、Web Bluetooth、Proxy、Grid Layout、<dialog> Element、CSS Houdini 等这些特性，我们没有办法通过上诉方式解决。

<figcaption >世界末日？</figcaption>

净化

痛点并不是完全无法解决。我们的诉求是需要一种手段来解决产品差异化带来的问题，一种手段是兼容低版本浏览器；另一种手段是只适配高版本浏览器，并且告知用户应该升级他们的浏览器，才能正常使用我们的服务。无论使用哪种手段，我们都应该要去避免这种情况：页面加载后一片空白或者点击某个按钮完全没有响应，页面布局错位、页面脚本执行错误，然而用户并不知道我们的网站不兼容他们的浏览器。为了解决这个问题，我们可以想到有很多方案，一种简单的方案是使用条件注释，比如 <!–[if lt IE 9]>...<![endif]–>；一种方案是基于特性的检测，检查全局对象 window 是否存在某个对应属性；另一种更好的方案是使用 UA 判断，在页面运行期间检测当前代理是否满足开发者的要求，遗憾的事实是社区中并没有一个很好的通用方案来实现这个目标。因此，我们按照后者的设想，致力于提供一个工具，并集成于现有的前端工具链中，来达到目标。

<figcaption >“这次可能真的成了!”</figcaption>

诞生

Obsolete Webpack Plugin 是笔者在业余时间开发的工具，检测用户浏览器是否支持网站代码。方法很简单，当页面处于 Idle 状态时，检测 UA 是否满足开发者预设的目标浏览器。如果配对失败，则执行脚本，把预设的模板插入 DOM 树中，来提醒用户他们的浏览器不支持，应该升级或者下载一款新的浏览器，避免一片空白茫然不知所措的局面。工具上手难度、配置复杂性很低，我们基于社区中最普遍、广泛依赖的基础库 Browserslist 来作为输入预设，无缝整合到当前的前端工具链中，所以最后决定选择 Webpack 插件作为切入点，打包时额外生成一份兼容 ES3 语法的脚本，结合 HTML Webpack Plugin 一起注入到 HTML 中。

历史的车轮滚滚向前，最后，祝所有的 Web 开发者有一个愉快的开发体验，让技术牵动用户使用更好的浏览器，而不是让用户阻碍了技术的进步。

9eff325416be933216924134f29095d.jpg