所以我来自 Angular，想看看如何创建 vanilla Web components。
现在来自 Angular，我们倾向于将事情分开：组件（充当 HTML、CSS 和一些 javascript），然后是“服务”，主要负责诸如收集数据和执行“硬后端”工作之类的工作。不应该发生在组件中。
虽然我知道 Web 组件和诸如 Angular 之类的框架不是一回事，但我想知道您将如何构建项目。
我在 Web 组件上找到的所有文章都只解释了最基本的内容（Shadow-dom、模板和自定义 HTML）
它们并没有真正向您展示如何使用该技术创建企业级应用程序。
所以我的问题有两个：
【问题讨论】：
标签： javascript architecture web-component
我越来越倾向于说“Web Components”是language construct。
它被称为 Custom Elements API，因此与 Fetch API 或 MutationObserver API 没有什么不同
那么您的问题是：如何使用 [name here] API 构建应用程序？
Lit、Hybrids、HyperHTML、Lego、Stencil 等工具都有 polyfill 背景，在浏览器不完全支持自定义元素 API 的古老时代，它们使“Web 组件”成为可能.
他们已经发展到所有人都声称“这是开发 Web 组件的最佳工具”
从这个意义上说，它们可以与 jQuery 进行比较。
曾经是 Web 开发人员的必备品，
然后选择器等成为 W3C 标准的一部分。
随着 IE9 在 2011 年的出现，不再需要 jQuery。
现在，Edge 在 Chromium 上运行，微软默认推送 Edge。所有现代浏览器都与自定义元素 API 相提并论
为了让 jQuery 比较在历史上更进一步。 10 年前有几十个 jQuery 替代品。如果你碰巧投资了“错误”的工具，你最终不得不转换为 jQuery（或者如果 IE9 是你必须支持的最古老的浏览器并且你理解 W3C 标准（几乎）总是赢，那么你只能转换为 Native JavaScript）
Lit、Hybrids、HyperHTML、Lego、Stencil 和所有其他产品也会发生同样的情况。
Angular、Svelte 或 Vue 都可以 100% 地与自定义元素 API 配合使用
https://custom-elements-everywhere.com/ 的 React 得分为 71%
60% 的 React 负责人会说 W3C 标准不支持 React。
如果您已经存在足够长的时间（> 20 年），您就会明白 React 可以与 ECMAScript-4（never made it 的 W3C 标准）进行比较
伟大的技术，但如果浏览器供应商不在浏览器中实现它，它就没有未来。这意味着 React 也是一个潜在的 "jQuery"。或者也许 Flash（ActionScript 具有 ES4 结构）是一个更好的比较。
创造一个有趣的未来：
Facebook 会解决 71% 的分数吗？
所有浏览器供应商（Mozilla、Google/Microsoft、Apple）都会实施 React(Native) 吗？
如果您不必支持 IE11，则有一个现代的、级别的自定义元素 API 竞争环境。
如果您正在学习，请先学习 API，然后看看工具是否可以让您的开发生活更轻松（并接受当您选择的工具与 MooTools、YUI 和许多其他工具相同时需要重构的风险）。 ..
话又说回来……银行仍在运行 Cobol……也许 React 是新的 Cobol？
使用 Web 组件构建企业级应用程序的结构架构的最佳做法是什么？ 您在使用 Web 组件时是否会分离核心逻辑（如加密、数据流等），如果是，如何分离？
您使用 Web 组件构建应用程序，就像您使用 类或代理构建应用程序一样。组件封装了逻辑，唯一的区别是自定义元素 API也 可以生成出色（非常出色）的语义 HTML。
唉，我看到公司和开发人员专注于“工具”而不是 API
对我来说，一个有工具的傻瓜仍然是一个傻瓜。
TypeScript 推出时，我身处 Microsoft SharePoint 世界。
将 MVP “很棒”的 TypeScript（因为他们忘记跟上 JavaScript 的步伐而使用 ES3 语法）重构为 ES6 赚了很多钱
当微软全力投入 React 时，我离开了那个世界。
组件开发人员现在学习工具，就像他们学习 jQuery...
自定义元素 API 是一种 JavaScript 语言结构。
它在某些方面做得非常好，而在其他方面做得不太好。
API 会产生影响吗？是的，就像 Classes 和 Array 方法一样。而这些也需要改变思维方式。
我的建议：
.map 和 .reduce
自定义元素 API 是 W3C 标准，所有浏览器都支持，
只要 JavaScript 在浏览器中运行，这项技术就可以工作。
【讨论】：
Object.assign 功能的 jQuery 源代码并了解到我正在加载 85% 的臃肿代码时，我的惊喜时刻到来了，其中 85% 是我的应用程序从未使用过的。但我确实从罐头里吃汤……有时……即使从头开始自己做汤更令人满意……我仍然需要/使用 Lodash 来做咖喱食谱 :-)
我经历了相同的周期并有相同的问题，实际上我需要创建一个企业应用程序并作为解决方案架构师为我的同事提供建议。凭借 20 年的 Web 技术背景，我认为这并不难回答。 随着支持“现代浏览器”的决定，Web 组件 API 的选择变得很容易。我对 Angular 和 React 也有很深的了解。我们决定使用项目结构和类似的工具链（WebPack、Jest 等）。这显然是非常明智的。 一开始，它只是我们写给 DRY 的一些库代码。它在一年后以一个完整的瘦库结束（让我put it here as a reference）。一段时间后，我们明白我们确实需要数据绑定、状态模型和集成验证。如果没有，你根本就没有足够的生产力。它仍然比胖框架要紧凑得多，但它不仅仅是一种新的 jQuery。 Web 组件本身只是 API 调用。但其他一切都是在 Proxy 和他的同事之上的艰苦工作。这就是所有较小的库或多或少尝试实现的目标（Lit、Hybrids、HyperHTML、Lego、Stencil 等）。我们最终得到了一些非常完整且非常接近胖兄弟的东西，但仍然非常小（Angular 等装饰器与 React 等 JSX 混合）。但是，尽管您渴望编写一个库，我还是建议您查看其中一个提到的库。请注意，未来的 API 可能会进一步减少需求，我很确定 ES2025 将包含大量此类内容。
免责声明：我是这种精简库的创建者和维护者，称为@nyaf。
【讨论】：