精读《Web Components 的困境》 about weekly

[alcat2008]

鲁迅先生说：**人一向是拿来主义的，什么都用什么都信，骨子是地地道道的实用主义。

这种评价在技术领域同样适用。

因为业务，有了需求，有了技术，有了各种各样的抽象。

还记得 15 年底，Angular 一家独大， React 初露峥嵘。当时的团队需要进行移动端的项目。在做技术选型时，考虑到之前一直用 Angular 进行 Web 端的业务迭代，也曾用过 ionic 的方案做过 webapp 的开发，然而对其模块化方案一直都不甚满意，系统很 “重”。当时也曾仔细分析过 Web Components，然而标准终究是标准，到实践落地仍存有很大的横沟，在缺乏生态的情况下，很难覆盖现有的业务需求（或者说成本很高），所以果断绕过这个黑洞，最终拿来了相对实用的 “React”。

但从前端的发展角度来看，这应该是暂时的。现阶段普遍采用的 构建 => 运行 方案有很多待以提升的空间，本来属于 html、css 的模块化却是由 js 来弥补。就像 @ascoders 所说，“未来的 html css js 一定是并驾齐驱的，现在出现的畸形在未来都会消失”。

Web Components 作为先驱，自有它的历史地位及价值。

[rccoder]

对 Web Component 多年来没有进展这个黑点没有任何办法可以洗地，Rob Dodson 的回应也难以让人拾起自信。

Web Component 作为一个标准，骨子里的进度就会落后于当前可行的技术体系。再加上浏览器厂商的支持程度和浏览器这种存在很多兼容问题的场景下，即使真的有一天这个标准建立起来，在有 React、Vue 等这种 “Web Component” 的前提下也不一定会有人理睬这个 “未来标准”。

未来会如何？永远是个谜。我选择站在 JS 的船上等待未来黎明的到来。

[ascoders]

情理之中的回应

Rob Dodson 的回应在情理之中，站在浏览器开发商的角度，开发者使用的框架是不稳定，不长久的，而 web components 特性需要被浏览器支持，必须有平缓的过渡，良好的兼容，以及成熟的方案，因此推进速度一定比前端框架缓慢。

但正如 @camsong 所说，整篇回应读下来，让我理解浏览器开发者的无奈，但这最多让我对 web components 的未来充满希望，但当下很长一段时间，它解决不了什么问题。同时，对标准的未来充满希望也是理所应当的，原文重点在如何解决当下的问题，我们开发者关心的也是如何解决当下问题，显然，然而
web components 没能很好的解决当下问题。

为什么对 web components 讨论不断

俗话说，成也萧何，败也萧何。正如原文提及的，现在网页规模越来越大，需求也越来越灵活，html 与 css 的能力已经严重不足，我们才孤注一掷的上了 js 的贼船：JSX 和 Css module，因为 web components 依托在 html 模版语言上，当然没办法与 js 的灵活性媲美。

但使用前端框架的问题也日益暴露，随着前端框架种类的增多，同一个框架不同版本之间无法共存，导致组件无法跨框架复用，甚至只能固定在框架的某个版本，这与前端未来的模块化发展是相违背的，我们越是与之抗衡，就越希望 web components 能站出来解决这个问题，因为浏览器原生支持模块化，相当于将 react angular vue 的能力内置在浏览器中，而且一定会向前兼容（这也是 web components 推进缓慢的原因）。

展望

作为前端开发者，关注的是当下问题如何解决，我们都已经在 js 的贼船上了，虽然与兼容 web components 并不违背，但如果不全面使用 web components，没必要套着框架使用 web components。

未来的 html css js 一定是并驾齐驱的，现在出现的畸形在未来都会消失，但我们不可能这几年，甚至十几年之内让业务停止，等着 web components 成熟。因为，业务不可能等着技术。

[camsong]

这两篇文章对比着来看很过瘾。首先是原文喷 Web Components 从2011年到2017年这6年间毫无进展，我想大概没有比努力做了6年的事却被人说啥都没做这样的评价更低了。然后是 Rob Dodson 的洗地文，看完虽不再绝望但仍失望。

挑一些我比较关注的点说一下：

浏览器支持度

Web Components包括4个部分：Templates、Custom Elements、Shadow DOM、Imports
放一张 webcomponents.org 官方的图片：

可以看出Chrome和Safari已经支持的比较完善，其它浏览器通过Polyfill也能解决。虽然现在支持还不理想，但过两年还是比较乐观的。

不需要 vendor 的自定义组件间调用

在 Webpack 大行其道的时代，想在运行时做到组件即引即用变得很困难，因为这些组件大多是通过 React/Vue/Angular 开发的。不得不考虑引入一大堆 Vendor 包，这些 Vendor 里可能还必须包含 React 这类两个版本不能同时使用的库。目前我们团队在做组件化方案时就遇到这个问题，只能想办法避免两个版本的出现。你可以说这是 React 或 Webpack 引入的问题，但并没有看到 Web Compnents 标准化的解决方案。

未来

2015年由于Angular2支持Web Components而React不支持。React在团队内部遇到很大挑战，正如作者所说 React 已经给出了全套解决方案，Web Components只有给出更好的方案才能让人满意。也有人认为Web Components做为浏览器底层特性不应该拿出来和React这类应用层框架相比较。我想未来Web Components会做为浏览器非常重要的特性存在。API偏低层操作，易用性不够，在很长时间内开发者依旧会使用 React/Vue/Angular/Polymer 这样的框架，Web Components可能会做为这些框架的底层来做Component间的互相引用的方法。还有值得一提的是Web Components号称有更好的性能。

[jasonslyvia]

其实这期的讨论最适合 @fanhc019 来参与，因为他是《Learning Web Component Development》（中译名《Web Component 实战》）的核心译者。

作为一个从 14 年就开始使用 React 技术栈，并接受过 Angular 2 beta 版洗礼的人，对 Web Component 一直都是一个观望的态度。最早的 Shadow DOM 和 Scoped CSS 概念确实很吸引人，但是始终处于『传说中的技术』的状态，看了这篇文章才了解其中发展的曲折。

正如文中所说，浏览器厂商 ship 一个新功能是很严肃的，很可能会影响到一票的线上业务，甚至会影响到一个产业（遥想当年 Chrome Extension 禁用 NPAPI 时的一片哀鸿遍野，许多返利插件都使用了这种技术）。那么 Web Component 的缓慢推进也在情理之中了，甚至到今天，曾经 React、Angular 和 Web Component 的三驾马车，在很多人眼里，Web Component 早已经被 Vue 替代。

Web Component 推进的意义在我看来是一种官方标准的实施和落地，有了规范和标准，也就会少一些各种各样的社区花式实现，对新进入社区的人来说就会少一些迷茫（还记得 #13 里入坑 React 时的不知所措吗），对整个社区的稳健发展来说也是有积极意义的。