设计系统架构师 Ariel Salminen 今天开源了一个叫 Elena 的 Web Components 库，同时发布了 v1.0.0-rc.7 候选版。这不是一个新标准，而是一套写组件的方法论：先用 HTML 和 CSS 把页面渲染出来，JavaScript 晚一步再加交互。核心运行时压缩后只有 2.6kB，零运行时依赖，整个项目拆成了 13 个 npm 包。
Salminen 做企业级设计系统将近十年，他给出的判断很直接：Web Components 这个模型本身没问题，问题出在大家一直用“JavaScript 优先”的方式在写它们——先加载脚本，脚本跑完组件才有样子，首屏因此闪烁、错位，服务端渲染也跟着遭殃。
两层结构，先看得见再能动
Elena 把组件拆成两层。HTML 和 CSS 是底层，浏览器不用等 JavaScript 就能把内容和样式呈现出来；JavaScript 是增强层，负责响应式状态、事件绑定和复杂模板，晚一步加载也不影响用户先看到东西。
Salminen 把这类组件分成三种：Composite 组件把 HTML 包在 Light DOM 里做增强；Primitive 组件自己渲染 HTML，同样把样式和初始状态放在 Light DOM；Declarative 组件是前两者的混合，用上了声明式 Shadow DOM。他自己也强调，这套分类不是 Elena 强制的规则，只是一种设计习惯，方便团队判断该用哪种写法。
SSR 不是无条件免费的
这是最容易被误读的地方。Elena 官网列了一堆好听的自我评价：accessible by default、zero lock-in、works with every major framework——这些都是项目自述，还没有独立第三方验证，读者最好当成设计目标而不是既成结论。
SSR 的实际情况有清晰的边界。没有 render() 方法的组件，因为本质就是 HTML 和 CSS，默认完全兼容服务端渲染，不需要服务器做任何特殊处理。用了 render() 的组件，服务端只能输出初始状态，交互部分仍然依赖客户端 hydration，除非额外接入 @elenajs/ssr 工具包。换句话说，“SSR 友好”不等于所有组件都能脱离 JavaScript 完整跑起来。
拿它跟其他方案比一下会更清楚。传统的 JavaScript 优先 Web Components，组件的样子完全等脚本执行；React Server Components 是把渲染决策权交给服务器和框架层，跨框架复用基本无从谈起。Elena 的位置介于两者之间：它靠 HTML/CSS 先行换来了无 JS 也能看的首屏，也靠 Custom Element 的原生特性换来了跨框架的可能性，但集成摩擦——事件代理、属性同步、不同框架的生命周期差异——并没有被彻底抹平。
- 风险.Elena 的组件默认走 Light DOM，样式隔离弱，命名冲突和 CSS 覆盖问题需要团队自己用命名规范兜底，这是它换取“无 Shadow DOM 屏障”所付出的代价。
谁该现在动手，谁该再等等
Elena 解决的是老问题的新写法，不是新问题的新答案。
对企业设计系统团队来说，Elena 目前最适合的场景是原型验证和局部试点：挑一两个跨框架复用需求强、SSR 首屏体验敏感的组件先跑起来看效果。它还处在 rc 阶段，第七个候选版说明 API 还在收敛过程中，直接把生产环境的组件库整体迁移过去,风险偏高。前端工程团队如果正被 React Server Components 和自研 Web Components 的集成问题卡住，可以把 Elena 列入观察名单，但落地前最好先拿自己的组件在真实框架组合里跑一遍 hydration 和样式隔离，而不是照单全收官网的功能清单。