Technology Radar
随着Next.js和htmx等框架逐步被采纳，我们看到服务端渲染（SSR）的使用越来越多。作为一种浏览器技术，在服务器上使用web 组件并非易事。为了简化这一过程，许多框架应运而生，有时甚至使用浏览器引擎来执行操作，但复杂性依然存在。我们的开发人员发现他们需要绕过一些障碍并付出额外努力来整合前端组件和服务端组件。比开发者体验更糟糕的是用户体验：当自定义 web 组件需要在浏览器中加载和填充时，页面加载性能会受到影响，即使使用预渲染和谨慎调整组件，未样式化内容的闪现或一些布局移动几乎不可避免。正如我们在上一期技术雷达中提到的，我们的一个团队因为这些问题不得不将他们的设计系统从基于 web 组件的Stencil迁移出去。最近，我们从另一个团队收到报告，他们最终用浏览器端组件替换了服务器端生成的组件，其原因是开发的复杂性。我们建议谨慎使用 用于 SSR web 应用的 web 组件 ，即使框架支持。
自从我们在2014年首次提到它们以来，Web 组件已经变得流行起来，总体而言，我们对其的看法是积极的。同样地，我们通过对采用默认选择 SPA 发出警告以及将如 Next.js 和 htmx 等框架与传统的服务器端框架一起列入，来表达对在服务器上来渲染 HTML 的支持。然而，尽管可以将两者结合使用，也还是可能造成深层次的问题；这就是为什么我们建议避免在 服务器端渲染（SSR）的 Web 应用 中使用 Web 组件。作为一种浏览器技术，要在服务器上使用 Web 组件并不容易。已经出现了一些框架来简化这一过程，甚至一些框架中还使用了浏览器引擎，但复杂性仍然存在。比开发人员体验更糟糕的是用户体验：当必须在浏览器中加载和构建自定义 Web 组件时，页面加载性能会受到影响，即使在预渲染和精心调整组件的情况下，也几乎无法避免“无样式内容闪烁”或某些布局变化。放弃使用 Web 组件的决定可能会产生深远的影响，正如我们的一个团队曾经不得不将其基于 Web 组件的设计系统 Stencil 进行迁移。
