企业级 Web 组件。第一部分：Salesforce、Oracle、SAP

Web 组件一直是备受争议的话题。如今，所有主流浏览器都已支持 Web 组件，自然有人会自问，这是否应该成为“新时代”的开始。然而，事实证明，新标准并非灵丹妙药，并不能满足某些人的期望，并非所有 bug 都已修复，Web 平台的某些部分也需要进一步改进。

我在之前的博客文章（1、2 ）中描述了一些这样的问题。然而，一些对 JS 生态系统有一定影响力的意见领袖倾向于批评整个理念，声称 Web 组件基于错误的假设，并且没有实际用途。这些说法有其道理，但却在社区中引发了许多误解。

你可能还没有意识到，但事实上，Web Components 正在行业最冷门的领域——企业 UI 开发——经历着令人瞩目的增长。大公司们对长期解决方案感兴趣，其中一些公司在过去吸取了许多惨痛的教训。这就是为什么他们现在强烈支持 Web 标准。

在本系列中，我将概述几个采用 Web 组件作为编程模型一部分的企业级 Web 应用开发平台。我们将了解它们在逐步向 Web 标准迈进的过程中如何引入变革，它们为开源生态系统带来了哪些价值，以及我们可以从它们的经验中汲取哪些教训。

Salesforce

Salesforce是一家软件公司，提供 CRM 平台和一套企业级 Web 应用程序。这些应用程序大多来自收购（这在市场扩张中很常见），并且采用不同的技术栈构建。同时，客户也可以使用 Salesforce 平台及其提供的工具构建自己的应用程序。

Salesforce 使用 Web 组件的案例在 2019 年 Google I/O 大会上由 Kevin Schaaf 和 Caridy Patiño进行了演讲。Arthur Evans 的文章列出了此次演讲的要点。Salesforce 选择 Web 组件的原因包括需要一个通用的组件模型来确保一致的外观和体验以及向后兼容性。

然而，这份清单中还有其他一些观点是合理的，我个人认为这些观点更为重要——尤其是对专有解决方案的担忧、被遗留技术困住的风险，以及对被困在封闭生态系统的围墙花园中的担忧。这就是“非我发明”在快速变化的前端世界中清晰体现的方式。

2018年底，Salesforce宣布推出Lightning Web Components，作为其平台UI开发的新组件模型，充分利用了Web标准的优势。此次更新特别关注了Lightning Web Components与旧模型Aura组件的共存和无缝互操作性，并建议用户考虑逐步迁移到Lightning。

几个月后，Salesforce开源了Lightning Web Components 框架，并发布了基于 MIT 许可的存储库、新网站和lwc-create-app用于创建新项目的 CLI 工具。Salesforce 的开发者布道者们也在撰写关于相关前端技术的博客文章，例如使用 Jest 对组件进行单元测试以及调试。

甲骨文

Oracle是一家提供各种企业软件产品的公司，包括客户端 Web 应用程序。其中许多应用程序都是使用Oracle JET（JavaScript 扩展工具包）构建的，该工具包遵循开源 UPL 许可证。请注意，“工具包”一词代表并强调了其模块化结构：JET 并非一个框架，而是一组库。

2017 年，Oracle在 JET 4.0 版本中引入了对自定义元素的支持。这一决定是为了更好地与 HTML 标准和现代规范保持一致。同时，JET UI 组件的新架构也以更优的语法、更直观、更自然的使用体验呈现给 UI 设计人员和开发者。

此前，直到 JET 3.2.0 版本发布之前，所有组件都被包装为 jQuery UI 小部件。为了与现有模型兼容，我们实现了新的“语法”，并且明确指出升级到新版本时无需迁移到现有模型。但所有新功能、开发者指南更新等都仅针对新的 Web 组件。

请注意，放弃 jQuery 并非使用自定义元素的初衷。在重大变革发生两年并发布了三个主要版本后，Oracle JET 仍在使用 jQuery，以及其他一些不那么高端的库，例如 RequireJS 和 Knockout（常见问题解答中甚至还有“为什么选择 Knockout ”部分）。JET中从 Sass 到 CSS 自定义属性的过渡也进展缓慢。

我们可以汲取的下一个教训是：在企业级规模下，逐步迁移是必须的。大公司无法承受从头重写所有内容，同时还要维护多年的项目。Oracle JET 似乎在遗留系统和技术更新之间保持了合理的平衡，同时也兼顾了生态系统，并对未来有着自己的愿景。

树液

SAP是一家提供企业软件（包括 ERP 系统）的公司。对于前端开发人员，SAP 提供了基于 Apache 2.0 开源许可证的OpenUI5框架。UI5 定位为企业级 JavaScript 工具包，用于构建几乎可以在任何浏览器上运行的 Web 应用程序，它以 jQuery 为基础并遵循 Web 标准。

2019年初，SAP宣布推出UI5 Web Components库的测试版，该库是UI5 Evolution项目的关键支柱，旨在实现UI元素的独立使用。另一篇博客文章指出，SAP开发人员从2014年开始评估Web Components。现在，他们看起来非常乐观：“时机已到，Web已经准备好了！”

在首次发布几个月后，也就是本文撰写之际，RC1 版本已正式发布，恰逢 UI5 Con 大会。除了保持良好的实际开发节奏外，SAP 还发布了一个包含互动游乐场的网站、一个入门教程、几个演示应用程序以及一集 UI5 首席架构师参与的新闻节目。

关于 UI5 Web 组件，一个重要的点在于它们与现有产品 OpenUI5 的定位。官方有一个专门的章节将新组件描述为“补充产品”，而不是 OpenUI5 的继任者。从中我们可以学到的教训是，在架构更新的同时，清晰地表达信息也至关重要。

还有一件事与上面的观点相关：放弃 jQuery。我们再说一遍：有时架构师必须向用户解释他们做出的决定。我强烈建议阅读 SAP 的 Andreas Kunz 的这条评论，以了解大公司如何仔细考虑他们所用工具的实际价值以及他们所做决策的影响。

概括

Web 组件最近才获得广泛的浏览器支持：自定义元素和 Shadow DOM 已于 2018 年 10 月在 Firefox 63 中发布，而基于 Chromium 的 Edge 现已在canary 和 dev 通道中可用。尽管如此，一些企业公司已经选择 Web 组件作为其 UI 开发平台的基础。

Salesforce、Oracle 和 SAP 就是这类公司的例子。他们的前端解决方案采用不同的方法创建，并且都处于采用新组件模型的不同阶段。比较这些公司并非本文的主要目的，因此，让我概述并简要阐述我认为我们应该从他们的成就中吸取的教训：

1. 所有权。优先选择 Web 标准而非专有解决方案，是为了避免被供应商锁定或困于封闭的生态系统。专注于 Web 标准可以降低新开发人员的入门门槛，同时还能提供对技术栈的完全控制，并促进内部能力的提升。

2. 逐步迁移。能够将 Web 组件与其他库结合使用是确保两种开发模式之间平稳过渡的关键。一种新方法，最初作为“补充解决方案”或“替代语法”引入，必须不断发展并经受住时间的考验，才能最终取代旧模式。

3. 决策的影响。大型公司在升级技术栈时会仔细评估自己的选择，这对于快速发展的 JavaScript 生态系统尤其重要。在企业 UI 开发中，任何新功能都要经历漫长的验证阶段，而这正是 Web 标准发挥作用的地方。

在本系列的第二部分中，我将继续从略微不同的角度概述使用 Web Component 构建的前端工具包。我们将探索三个不同的开源平台，它们本身以产品形式提供，并附带商业服务——希望能够从中汲取一些新的经验。敬请期待！