原文地址：dev.to/webpadawan/…
原文作者：dev.to/webpadawan
发布时间：2019年7月3日 ・7分钟阅读
Web组件仍然是一个争论的话题。自然，现在当它们被所有的常青浏览器支持时，有些人就会问自己，那是不是应该是 "新时代"。然后发现，新的标准并不是万能的，并不能满足某人的期望，并不是所有的bug都被修复了，网络平台的某些部分还需要进一步改进。
我在之前的博文（1，2）中描述了很少的这样的问题。然而，某些对JS生态系统有一定影响的意见领袖却倾向于批评整个想法，他们声称Web Components是基于错误的假设，没有实际作用。这些说法有其道理，但它们在社区中产生了很多误解。
你可能还没有意识到这一点，但事实上，Web Components现在在行业中最惰性的部分：企业UI开发中正经历着令人印象深刻的增长。大公司对长期的解决方案感兴趣，其中一些公司在过去吸取了许多惨痛的教训。这就是为什么现在他们对web标准表示强烈的支持迹象。
在这个系列中，我将概述几个企业平台的商业Web应用开发，采用了Web组件作为编程模型的一部分。我们将看到它们是如何在引入变化的同时，随着时间的推移向web标准发展的，它们给开源生态系统带来了什么价值，以及我们可以从它们的经验中吸取什么教训。
Salesforce
Salesforce是一家提供CRM平台和一套企业网络应用的软件公司。这些应用中的许多来自收购，这也是市场扩张的常态，并使用不同的堆栈进行构建。同时，客户可以使用Salesforce平台及其提供的工具构建自己的应用程序。
在Google I/O 2019上，Kevin Schaaf和Caridy Patiño在演讲中提出了Web Components在Salesforce的案例。Arthur Evans的文章中列出了演讲的要点。Salesforce选择Web Components的原因包括需要一个通用的组件模型，以确保一致的外观和感觉以及向后兼容。
然而，在该列表中还有其他有效的观点，我个人认为这些观点更为重要--特别是，对专有解决方案的担忧，被遗留技术困住的风险，以及对留在封闭生态系统的围墙花园中的恐惧。这就是 "这里没有发明 "的症状在快速变化的前端世界中的明显表现。
2018年底，Salesforce宣布了Lightning Web Components，作为平台中UI开发的新组件模式，充分利用了Web标准的优势。其中特别强调了与之前的模型Aura组件的共存和无缝互通，并建议逐步考虑向Lightning迁移。
几个月后，Salesforce开源了Lightning Web Components框架，并展示了MIT授权的仓库、新的网站和允许创建新项目的lwc-create-app CLI工具。Salesforce的开发者布道者们也在写博客文章，介绍相关的前端技术，比如用Jest对组件进行单元测试和调试。
甲骨文
甲骨文公司是一家提供各种企业软件产品的公司，包括客户端的网络应用。这些应用程序中的许多都是用Oracle JET（即JavaScript扩展工具包）构建的，该工具包在开源UPL许可下可用。请注意，"工具包 "一词代表并强调了模块化结构。JET不是一个框架，而是一组库。
2017年，Oracle在JET的4.0版本中引入了对自定义元素的支持。这一决定的动机是作为努力的一部分，以更好地与HTML标准和现代规范保持一致。同时，JET UI组件的新架构被呈现给UI设计师和开发人员的受众，因为它具有更好的语法，更加直观和自然的工作方式。
此前，在JET 3.2.0发布之前，所有的组件都是以jQuery UI widgets的形式包装的。实现了新的 "语法 "与现有模型并存，升级到新版本时，明确表示不需要迁移到新的语法。但所有的新功能、开发者指南更新等只针对新的web组件。
注意，摆脱jQuery并不是使用Custom Elements的动机。在大改版两年、3个大版本之后，Oracle JET仍然在使用jQuery，以及其他不那么花哨的库，比如RequireJS和Knockout（在FAQ中甚至有 "为什么要使用Knockout "一节）。JET中从Sass到CSS自定义属性的过渡也是缓慢进行的。
而这也是我们可以吸取的下一个教训：在企业规模上，逐步迁移是必须的。大公司无法承受从头开始重写一切，同时又要维护项目多年。Oracle JET似乎在传统和技术更新之间保持了合理的平衡，同时也考虑到了生态系统，对未来有自己的愿景。
SAP
SAP是一家提供企业软件的公司，包括ERP系统。对于前端开发者，SAP提供了Apache 2.0开源许可下的OpenUI5框架。UI5定位为企业级JavaScript工具包，用于构建几乎在任何浏览器上运行的Web应用，以jQuery为基础，遵循Web标准。
2019年初，SAP宣布推出UI5 Web Components库的测试版，作为UI5进化项目的重要支柱提出，旨在实现UI元素的独立消费。从另一篇博文中可以看出，SAP开发人员从2014年开始评估Web Components。而现在他们看起来真的很乐观："时间已经到了，Web已经准备好了！"
在最初宣布的几个月后，在写这篇文章的时候，RC1已经发布了，正好可以在UI5 Con上展示。除了保持良好的实际开发节奏外，SAP还发布了一个网站，里面有互动游乐场、入门教程、多个演示应用和一集UI5首席架构师的新闻节目。
关于UI5 Web组件，有一个重要的注意点，就是与OpenUI5这个现有产品相比，它们的定位是怎样的。有一个特殊的章节将新组件描述为 "补充性产品"，而不是OpenUI5的后续产品。从这里我们可以学到的教训是，在架构更新的同时，明确表述信息的重要性。
还有一件事，与上面的观点有关：摆脱jQuery。我们又来了：有时候架构师必须向用户解释他们做出的决定。我强烈推荐阅读SAP的Andreas Kunz的这篇评论，以了解大公司是如何仔细考虑他们所使用的工具的实际价值和他们所做的决定的影响的。
小结
最近，Web Components已经达到了广泛的浏览器支持。Custom Elements和Shadow DOM于2018年10月在Firefox 63中发货，基于Chromium的Edge现在已经在Canary和Dev频道中提供。尽管如此，某些企业公司已经选择Web Components作为其UI开发平台的基础。
Salesforce、Oracle和SAP就是这类公司的例子。他们的前端解决方案是使用不同的方法创建的，而且他们都处于采用新组件模型的不同阶段。对这些进行比较并不是这篇博文的主要目标，所以让我概述并简要地制定我认为我们应该从他们的成就中学习的经验。
-
自主权。倾向于网络标准而不是专有解决方案的目的是为了避免厂商锁定或被困在封闭的生态系统中。专注于网络标准可以降低新开发者的进入门槛，同时还可以完全控制技术栈，促进内部能力的增长。
-
逐步迁移。能够将Web Components与其他库结合起来，是确保两种开发模式之间顺利过渡的关键。一种新的方法，最初是以 "补充方案 "或 "替代语法 "的形式引入的，必须不断发展，经得起时间的考验，才能最终取代旧的模式。
-
决策的影响。大公司在升级技术栈时，会仔细评估自己的选择，这一点对于快速发展的JavaScript生态系统来说尤其重要。在企业UI开发中，任何一个新功能都要经过漫长的验证阶段，这也是Web标准发挥作用的地方。
在本系列的第二部分，我将从一个稍有不同的角度继续概述用Web Component构建的前端工具箱。我们将探讨三个不同的开源平台，它们本身就是作为产品提供的，伴随着商业服务--希望能从它们身上学到一些其他的经验。敬请期待!
