两年多前，我从伦敦一家初创公司离职，在那里，我负责开发基于 React 的大型电子商务前端。离职后，我加入了谷歌，从事 Chrome DevTools 的工作。我最初的工作重点是引入 Web Components，这是一个新的测试基本构建块，用于开发新的 DevTools 特性和用户界面。由于最近面板和其他面板的发布，现在，DevTools 中的很大一部分几乎都是 Web Components。
我曾经预计，当我离开以为中心的角色后，会发觉转型很困难，并会怀念 React 所提供的东西。结果，我发现转型要比预期容易得多，并且我真的很享受更接近平台原语的工作，对我所编写的软件保持了更多的控制，在本文中，我想分享一下这个原因。
首先，以防引发歧义和争论，我想先清楚地阐明本文不是什么：
虽然我会用 “React” 作为我的比较，但你可以合理地将其替换为任何大型现代框架。
使用平台
近年来，“使用平台”已经成为一个有点被过度使用和滥用的短语，但是它的核心原理却让我产生了共鸣：我们能不能利用浏览器和 JavaScript 中的 API，在无需第三方依赖项的情况下，为我们的用户开发特性？
保持控制
当我刚开始使用 React 时，我最担心的就是如何适应自定义元素，但是我真的很喜欢用它们工作。
自定义元素可能会让你更容易写出更多的代码，但是，如果你以前用过任何一个流行的组件库，那么你就可以创建出一些令人惊讶的、熟悉的东西，但是有一个关键的区别：你不会放弃控制。
React 不允许你自行决定如何以及何时将你的组件渲染到页面上。你使用它的结构来编写代码，它决定何时渲染。10 次中有 9 次——甚至 100 次中有 99 次或更多——这完全符合你的预期。但是 Web 平台并非十全十美，我猜想大多数 React 开发者都会遇到过这样的情况：你很渴望能够调整自己的组件的渲染方式。
如何放弃对渲染过程的控制，将会导致混乱，正如Gary Bernhardt 所发的这条推文一样：
在软件开发中，这被称为控制反转（Inversion of Control）。当你使用像 React 这样的框架时，你的代码将不再直接控制组件（或函数）何时被调用。你的组件并不直接告诉 React 何时重新渲染它们，而是由 React 决定。你的组件已经把控制让给了 React。
我们的自定义元素解决方案不会有这种控制的倒置；我们通过明确地调用一个函数（在 lit-html 的例子中，它是一个名为的带标签模板源文本）来控制每一次渲染。
没有使用 React 这种框架的不利之处在于，你必须考虑重新创建那些原本内置的部分，比如，确保我们批量渲染的基本调度器，或者使这些组件更容易测试的测试助手库。在这种情况下，你必须仔细考虑你的选择：如果我们避免使用 React，但最终重新实现了它提供的大部分内容，那么我们使用框架会可能会更好。在我们的案例中，我们依然认为这样的决策是合理的，因为我们不必重新构建一个具有 React 的所有复杂性的调度器：我们可以构建一个小型的、独立的实现，只实现我们所需要的东西。
在构建了我们的基本调度器之后，我们可以清楚地知道每个组件的渲染原因和时间，并且当我们需要偏离标准路径时，我们就能够实现。这种感觉很有价值：我所开发的每个软件项目中，都有至少一种组件需要做一些不同的事情来处理奇怪的边缘情况。
选择可以轻松替换的依赖项
自定义元素缺乏的一个领域是某种形式的 HTML 模板解决方案，它提供了高效的 HTML 重渲染。我肯定会建议使用一个库来解决这个问题，而我们选择了。lit-html 的魅力在于，它只是我们解决方案中的一小部分。我们本可以选择 Lit，一个基于自定义元素形成的功能更全面的组件库，但是这样做，会导致我们增加依赖项，同时也会失去一定的控制（重申我在这篇博文前面提出的观点：这不是对 Lit 的批评，对很多人来说 Lit 是正确的选择！）。
Lit-html 可以确保我们的 HTML 被有效地渲染，并且提供了一套很好的指令，让我们可以轻松地完成常见的任务，如有条件地应用类。虽然没有 JSX 那么完美，但是也非常的接近。
最重要的是什么？它是一个非常小的依赖项（3.3kB gzipped），更重要的是，如果我们需要的话，可以很容易地被替换。这听起来很消极，甚至很悲观，但当我们采用一个新的依赖项时，我们要问的一个主要问题是：“如果它消失了会怎样呢”？
假定 React 已经消失（这并不是说我认为它会消失）。我们处理这个问题的代价是什么？我们有几个选择：
这与自定义元素和 Lit-html 形成了鲜明对比。我们可以有很好的信心，自定义元素不会突然消失；它被嵌入到浏览器中，并且向后兼容是 Web 平台的一个核心原则。
替换 lit-html 将是一项工作，但比替换 React 要少得多：它在我们的代码库中纯粹是用来让我们的组件（重新）渲染 HTML。替换 lit-html 仍然意味着我们可以保留我们的业务逻辑，最终保持它们为最终用户提供的价值。Lit-Html 是我们系统中的一块小的“乐高砖”，React（或 Angular，或类似）是整个“盒子”。
第三方依赖项的成本
第三方依赖，无论大小，都会有一系列的成本，你的用户和/或开发人员将为此支付。每个人对这一成本是否值得的看法会有所不同，这取决于你的应用程序和技术栈，但当我考虑添加新的依赖项时，会出现以下一组成本：
总结
这篇文章并不是说你不应该接触依赖项。在回应 Jeremey Keith 关于信任和第三方依赖项的帖子时，Charles Harries 提出，跨浏览器兼容性在历史上是依赖项的驱动力。
作者介绍：
Jack Franklin，谷歌工程师，负责构建 Chrome DevTools。
原文链接：
