什么是 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/,延续至今。

webp

zzpic19728.jpg


<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">程序员小李</figcaption>

战争

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

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">浏览器们放学约架</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 style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">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 style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">世界末日?</figcaption>

扫描二维码关注公众号,回复: 7122774 查看本文章

净化

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

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">“这次可能真的成了!”</figcaption>

诞生

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



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

webp

9eff325416be933216924134f29095d.jpg


猜你喜欢

转载自blog.51cto.com/14516164/2433283