Web Components 会超越 JavaScript 框架成为主流吗？
为什么想讨论这个话题，归因于最近看到了一篇博文中描述的现有 JavaScript 框架的痛点以及 Web Components 的一些优势以及 Google 团队推出的 Lit 框架。
现在 React/Vue 框架趋于稳定，作为开发者的我们在开始一个项目时，在技术栈选择上常常会犹豫不决。你会选择当前主流可靠的 React/Vue？还是选择更轻量时髦的 Svelte 或 Solid？还是选择老派的服务器框架和 HTMX？
下面以构建博客示例来阐述为什么？
在选择构建博客时，当时有考虑选择使用 React，但是大多数情况下项目的约束决定了技术选型的决策，在反复的考虑之后，下面谈谈为什么？
写博客时间长的同学，可能都经历过各种技术栈的切换，现在使用的可能是 Astro 构建的，在这之前可能是静态网页生成器构建的，再之前可能是 Hugo，再之前可能是 WordPress。
在博客技术切换的过程中，让迁移变得容易的可能是将所有内容都保存为 Markdown 文件，在不同系统之间切换是只需要从一个系统导出，再导入另一个系统即可，最多的修复下兼容性或者移除一些无法移植的内容。博客系统可以很容易的跑起来。
令人不愉快的是大多数网站生成器都有一种自有的语法糖，Astro 也不例外。MDX 允许你在 Markdown 文件中集成 Astro 组件。这些组件可以使用 Astro 构建系统的所有功能，您可以在一个文件中编写 HTML、CSS 和 JS，Astro 会自动为您提取和优化所有内容。它还会范围化 CSS 选择器，编译 TypeScript，让你有条件地渲染标记，做其他各种花哨的事情。
当然，缺点是这一切只能在 Astro 内部运行。为了切换到不同的网站生成器，我必须重写这些组件。我可能需要拆分 HTML、CSS 和 JS，或者配置新的构建系统，或者找到新的样式范围。因此，Astro 特有的功能是不受限制的--无论多么方便。
不过 Markdown 优势是你可以在其中编写 HTML！这意味着我想添加的任何花哨的交互式图表，只要能用纯 HTML 标签来表达，就能和我的其他 Markdown 一样具有可移植性。
Web Components 恰好满足了这一需求。它们是用于构建可重用 HTML 元素的 W3C 标准集。您通过编写自定义元素的类、注册标签名称并在标记中使用它们来使用它们。下面是编辑器的代码：
<pixelart-demo></pixelart-demo>
Web Components 将所有 HTML、CSS 和 JS 封装在一个文件中，无需构建系统。开发者可以将组件的所有代码集中在一个地方，大大减少了脑力开销，因为它们给开发者带来了良好的体验。虽然 Web Components 不像 Astro 或 Svelte 那样好写，但它们仍然超级方便。
如果您对 Web Components 不熟悉，下面是上述 <pixelart-demo> 组件的代码
import PixelEditor from "./PixelEditor.js";
class PixelArtDemo extends HTMLElement {
constructor() {
super();
this.shadow = this.attachShadow({ mode: "closed" });
this.render();
const resolution = Number(this.getAttribute("resolution")) || 100;
const size = { w: resolution, h: resolution };
const alice = new PixelEditor(this.shadow.querySelector("#alice"), size);
const bob = new PixelEditor(this.shadow.querySelector("#bob"), size);
alice.debug = bob.debug = this.hasAttribute("debug");
}
render() {
this.shadow.innerHTML = `
<div class="wrapper">
<canvas class="canvas" id="alice"></canvas>
<canvas class="canvas" id="bob"></canvas>
<input class="color" type="color" value="#000000" />
</div>
<style>
.wrapper {
display: grid;
grid-template-columns: 1fr 1fr;
grid-template-rows: 1fr auto;
gap: 1rem;
margin: 2rem 0 3rem;
}
.canvas {
grid-row: 1;
width: 100%;
aspect-ratio: 1 / 1;
border: 0.25rem solid #eeeeee;
border-radius: 0.25rem;
cursor: crosshair;
}
.color {
grid-column: 1 / span 2;
}
</style>
`;
}
}
customElements.define("pixelart-demo", PixelArtDemo);
Web Components 的另一个优点是 Shadow DOM，它将组件与周围的页面隔离开来。当你想在组件和应用程序的其他部分之间共享样式时，shadow DOM 往往会显得很笨拙，但当你真的想把所有东西都隔离开来时，它就非常完美了。就像图片和视频一样，无论在哪里使用，这些组件的外观和行为都是一样的。
同时 Web Components 可以暴露属性，以便从外部对其进行配置。
另一个是使用 vanillaJS。有一些框架可以编译成 Web Components ，其中最著名的是 Lit（虽然我更愿意称它为一个库），但也有 Stencil、Svelte 等。它们都是很棒的工具，但框架是一种依赖关系，而依赖关系又需要权衡利弊。在这种情况下，最担心的就是维护问题。
小懒也写过两篇关于 Lit 的文章，快速阅读：Lit 与 React 框架对比指南 和 前端快讯｜Lit 3.0 已发布，再见 IE，你好 TC39 装饰器！
这一点也适用于 TypeScript。TypeScript 的最近 15 个版本都有破坏性的变化，尽管我们很喜欢 TypeScript，它并不是 Web 的原生底座，它仍然是一个依赖项。
使用依赖项是有代价的。新版本会发布、API的变化，都需要花时间和努力确保码与它们兼容。而且这个成本会随着时间的推移而积累。
回顾 Web 发展的 20 年，见证过 jQuery 的诞生、崛起和衰落。Node.js被创造出来，分叉成io.js，然后再次合并到 Node.js 中。Backbone 爆发增长，很快被 AngularJS 取代，然后又被 React 和 Vue 取代，再就是新兴框架的出现 Lit、Astro、Svelte、Solid 等。
但是，在其周围的生态系统不断变化的同时，Web 平台本身却保持了非常稳定 - 这在很大程度上是因为标准的管理者辛苦工作，确保没有新的变化会破坏现有的网站。比如，1996年的原始《Space Jam》网站仍然有名且在现代浏览器中完美呈现。
最后，不管是使用 Web Components 还是 主流框架 React/Vue，在我们做项目技术选型时，更多建议是从项目情况、团队人员能力水平、技术栈的发展等不同维度来评估。
大家都在看