Web Components：原生组件化开发新趋势——一个异地考公程序员的深夜思考
上周五晚上十一点，我还在公司改一个老旧管理系统的前端 bug。窗外北京的秋雨淅淅沥沥，办公室只剩我一人，屏幕右下角弹出老婆发来的微信：“今天又不能视频了？明天一早我要出差，下周才能回来。”
我心里一沉，回了个“嗯”，然后默默把手机塞进裤兜。这已经是这个月第四个周末没法见面了——她在上海，我在北京，为了考公，我白天上班写 Java，晚上刷行测申论，周末还得抽空研究新技术，生怕被淘汰。
说来好笑，一个准备上岸的程序员，居然还在纠结 Web Components 这种“非主流”技术。但没办法，干我们这行的，哪怕明天就要交辞职信，今天也得把代码写明白。
从 React 到原生：一场“返祖”式的技术探索
去年十月，我还在一家中型互联网公司做前端，月薪从15k涨到22k，看似风光。但每天面对的，是成吨的 React 组件、Webpack 配置、Node_modules 依赖地狱。有一次，产品临时要求在一个纯静态页面里嵌入一个复杂的筛选器，而那个页面根本没引入 React。我花了整整两天时间打包、压缩、兼容，最后还因为 bundle 太大被老板骂了一顿。
那天晚上回家，老婆视频问我：“你最近怎么总叹气？”我说：“感觉像个搭积木的，React 是乐高，但有时候客户只想给你一块木头，让你现场雕个狮子出来。”
就是那一刻，我开始认真看 Web Components。
Web Components 不是什么新东西，它其实是浏览器原生支持的一套组件化标准，由 Custom Elements、Shadow DOM、HTML Templates 和 HTML Imports（已废弃）四部分组成。简单说，它允许你用纯 Javascript 定义一个可复用的 HTML 标签，比如 <my-button>，自带样式隔离、逻辑封装，不用任何框架。
听起来是不是有点像 React 的自定义组件？但关键区别在于：它不依赖任何构建工具或运行时库。你写完就能直接扔进任何 HTML 页面跑，就像当年写 jQuery 插件那样自由。
为什么一个考公人还在研究这个？
可能有人会问：“你不是要考公务员了吗？还折腾前端新技术干嘛？”
说实话，我也犹豫过。今年三月，我和老婆认真讨论过这个问题。她说：“你要是真考上，以后可能就写不了代码了，不如趁现在多学点‘能带走’的东西。”这句话点醒了我——技术可以不用，但思维不能丢。
而且，考公≠躺平。我现在的工作单位虽然是私企，但做的系统很多是给政府对接用的。那些老掉牙的 Java 后台管理系统，前端基本还是 JSP + jQuery 的混合体。领导们嘴上喊着“数字化转型”，实际上连 ES6 都不敢上。在这种环境下，如果你只会 React/Vue，根本插不上手；但如果你能用 Web Components 写一个轻量、无依赖、即插即用的组件，反而更容易落地。
举个真实例子：上个月，我们接到一个任务，要在某个市级政务门户的旧页面里加一个“政策解读卡片”。那个页面是十年前用 Struts2 + JSP 写的，连 npm 都没装过。我试过用 Vue 打包，结果因为 CSP（内容安全策略）限制，script 标签直接被拦截。
最后怎么办？我用 Web Components 写了一个 <policy-card> 组件：
class PolicyCard extends HTMLElement {
constructor() {
super();
const shadow = this.attachShadow({ mode: 'open' });
const style = document.createElement('style');
style.textContent = `
.card { padding: 16px; border: 1px solid #ddd; border-radius: 8px; }
.title { font-weight: bold; color: #333; }
`;
const title = document.createElement('div');
title.className = 'title';
title.textContent = this.getAttribute('title') || '政策解读';
shadow.appendChild(style);
shadow.appendChild(title);
}
}
customElements.define('policy-card', PolicyCard);
然后在 JSP 页面里直接写：
<policy-card title="关于小微企业税收优惠的通知"></policy-card>
搞定。零依赖，零构建，连 IE11 都能用（配合 polyfill）。项目经理看了直呼“神奇”，其实我只是用了浏览器原生能力而已。
Web Components vs React：不是替代，而是互补
我知道很多人一提 Web Components 就想到“对抗 React”。其实完全没必要。React 的状态管理和生态无可替代，但 Web Components 解决的是另一个问题：跨技术栈的组件复用。
想象一下：你们公司有 React 团队、Vue 团队、甚至还有 Angular 老系统。现在要做一个统一的 UI 库，每个团队都得维护一套自己的 Button、Modal。但如果用 Web Components 写一套原子组件，大家都能直接用，还能保证视觉和交互一致性。
更妙的是，React 本身也能消费 Web Components。虽然官方不推荐（因为生命周期不同步），但通过包装一层，完全可以做到：
// 在 React 中使用 <my-button>
function MyButton({ label, onClick }) {
return (
<my-button
label={label}
onClick={onClick}
/>
);
}
反过来，Web Components 也能嵌入 React 组件（通过 ReactDOM.render），虽然略显 hack，但在混合迁移场景下非常实用。
异地生活中的技术坚持
写到这里，我看了眼时间，凌晨一点。老婆应该已经睡了。房租3500的房子隔音很差，隔壁情侣吵架的声音隐约传来。我揉了揉眼睛，继续敲键盘。
有人说，考公是为了稳定，是为了结束异地。但我觉得，真正的稳定，不是一份铁饭碗，而是无论身处何地，都能解决问题的能力。Web Components 教给我的，就是这种“轻装上阵”的能力——不需要庞大的生态，不需要复杂的工具链，只要浏览器支持，我就能交付价值。
当然，这条路也不容易。Web Components 的文档分散，社区小，调试工具弱，连 VS Code 的智能提示都不完善。有次我卡在一个 Shadow DOM 事件冒泡的问题上，翻遍 Stack Overflow 才找到答案。那一刻真的很焦虑，差点想放弃，回头去卷 LeetCode。
但转念一想：如果连这点技术深度都啃不下来，将来进了体制内，面对那些“既要又要还要”的需求，我拿什么立足？
给同行的几点建议
如果你也在考虑 Web Components，这里是我踩坑后总结的几点：
- 别指望它取代 React/Vue：它适合做底层原子组件，不适合做复杂应用。
- 重视兼容性：现代浏览器基本没问题，但政府/银行项目可能还要 polyfill。
- 善用 Lit：Google 出的轻量库，简化 Web Components 开发，类似“React for WC”。
- 和现有框架结合：不要二选一，而是用 WC 解决框架解决不了的问题。
- 心态放平：这不是银弹，但它是一把瑞士军刀——小，但关键时刻能救命。
结语：在不确定中寻找确定性
写完这篇稿子，天快亮了。再过两周就是国考报名截止日，我的复习进度才60%。老婆说她下个月调岗，可能会来北京，也可能不去。未来充满变数。
但有一点我很确定：无论我最终坐在公务员办公室，还是继续写代码，对技术本质的理解，永远不会过时。Web Components 可能不会让我涨薪，但它让我明白——真正的组件化，不是靠框架赋予的，而是靠对浏览器原生能力的敬畏与掌握。
技术人的浪漫，大概就是在深夜的出租屋里，用几十行 Javascript，造出一个属于自己的 <hope-element>。
愿我们都能在时代的洪流中，守住那份“写清楚一行代码”的初心。
—— 一个正在刷行测、改 bug、等老婆消息的普通程序员
2023年10月 北京
评论 0