Web Components：原生组件化开发新趋势？一个深圳考公程序员的真实探索
上周五晚上十点半，我瘫在南山区科技园那套35平的出租屋里，老婆在厨房热剩饭，我盯着 MacBook 上刷到的一道面试题发呆：
“请谈谈你对 Web Components 的理解，它和 React 有什么区别？”
我苦笑了一下。这已经是我这个月第三次在模拟面试中被问到这个问题了。自从去年十月下定决心“裸辞备考公务员”失败后，我又回到了这家做区块链钱包的小公司继续搬砖，月薪从15k涨到了22k，但心里却越来越空。
一、一切始于一场“失败”的裸辞
去年九月，我还在一家做 DeFi 协议的创业公司当全栈工程师。项目上线后团队解散，老板拍着我肩膀说：“小陈啊，你这算法能力不错，去大厂吧。”可我已经厌倦了每天写智能合约、调 Solidity 漏洞、被用户骂“钱不见了”。更关键的是——老婆怀孕了。
那天晚上我们在南山人才公园散步，她摸着肚子说：“要不……你试试考公？”
我愣住了。程序员考公？听起来像“用 C++ 写 Hello World 去参加小学生作文比赛”。
但我还是点了头。十月初，我真裸辞了。
结果呢？行测刷到70分，申论写得像技术文档，结构清晰但毫无感情。最惨的是面试——考官问：“你为什么想离开高薪的互联网行业？”
我说：“我想追求稳定，为人民服务。”
他笑了笑：“那你之前写过什么能体现‘服务人民’的代码吗？”
那一刻，我突然意识到：我的技术栈，和体制内的需求，根本不在一个频道上。
二、重回职场：被迫面对“技术债”与“新趋势”
今年二月，我重新找工作。面了七八家，最后选了这家做企业级区块链浏览器的公司。理由很现实：离家近（步行15分钟），双休，不加班到凌晨。
但入职第一天就傻眼了。
我们的前端是纯 HTML + jQuery 写的，页面加载慢得像2G网络，组件复用？不存在的。产品经理甩过来一个需求：“我们要做一个类似 Etherscan 的交易详情页，支持插件式扩展。”
我脱口而出：“用 React 啊！搞个 Context + 自定义 Hook，三小时搞定。”
结果架构师老李摇摇头：“老板不让用框架，怕 bundle 太大影响加载速度，而且我们有些页面要嵌入到政府系统里，不能有第三方依赖。”
我当时差点背过气去。不用 React？那用 Vue？Angular？
“都不行。”老李喝了口枸杞茶，“老板说，要么原生，要么滚蛋。”
于是，我被迫开始研究 Web Components。
三、Web Components 到底是个啥？
简单说，Web Components 是浏览器原生支持的组件化方案，不需要任何框架。它由三部分组成：
- Custom Elements：自定义 HTML 标签，比如
<my-button> - Shadow DOM：隔离样式和 DOM，避免全局污染
- HTML Templates：声明式模板，懒加载用
举个例子，我想做一个可复用的“区块链交易状态指示器”：
<template id="tx-status-template">
<style>
.status { color: green; }
.pending { color: orange; }
.failed { color: red; }
</style>
<div class="status" id="statusText">Loading...</div>
</template>
<script>
class TxStatusComponent extends HTMLElement {
constructor() {
super();
const template = document.getElementById('tx-status-template');
const shadowRoot = this.attachShadow({ mode: 'open' });
shadowRoot.appendChild(template.content.cloneNode(true));
}
connectedCallback() {
const txHash = this.getAttribute('tx-hash');
this.fetchTxStatus(txHash);
}
async fetchTxStatus(hash) {
// 调用区块链节点 API
const res = await fetch(`/api/tx/${hash}`);
const data = await res.json();
this.shadowRoot.getElementById('statusText').textContent = data.status;
this.shadowRoot.getElementById('statusText').className = data.status;
}
}
customElements.define('tx-status', TxStatusComponent);
</script>
然后在页面里直接写：
<tx-status tx-hash="0xabc123..."></tx-status>
是不是有点像 Vue 的单文件组件？但它完全原生，连 Babel 都不需要！
四、和 React 比，谁更香？
我知道很多兄弟会说：“这不就是 React 的阉割版吗？”
别急，咱们拉出来遛遛。
| 维度 | React | Web Components |
|---|---|---|
| 学习成本 | 高（JSX、Hooks、状态管理） | 低（纯 JS + HTML） |
| Bundle 体积 | 至少 40KB+（React + ReactDOM） | 0KB（浏览器内置） |
| 跨框架兼容 | 只能在 React 项目用 | 任何地方都能用（Vue/Angular/jQuery/原生） |
| 生态 | 海量 UI 库（AntD、MUI） | 生态较弱，但 Lit、Shoelace 等正在崛起 |
| 开发体验 | 热更新、DevTools 调试爽飞 | 调试靠 console.log，痛苦指数 ★★★★☆ |
我在公司试了两周，发现 Web Components 特别适合嵌入式场景——比如我们要把交易查询组件嵌入到某市政务平台里，对方只允许加载一个 JS 文件，且不能有外部依赖。这时候，React 直接出局，而 Web Components 只需一个 <script> 引入，完美运行。
但如果是大型应用？比如带复杂状态管理、路由、表单校验的后台系统？我还是会选择 React。毕竟，程序员的时间比 bundle size 更值钱。
五、考公路上的技术反思
上个月，我又参加了一次公务员面试（这次是某省大数据局的技术岗）。面试官果然又问：“你了解 Web Components 吗？”
这次我没慌。我说：“我用它在区块链项目中实现了跨系统组件嵌入，解决了第三方依赖冲突问题。虽然它不如 React 生态丰富，但在特定场景下，原生方案反而更可靠。”
面试官点点头：“很好，我们正好需要能对接老旧系统的开发者。”
那一刻，我突然明白：技术没有高低贵贱，只有是否合适。
考公不是逃避，而是换个战场发挥价值。体制内也需要懂 Web Components 的人——尤其是现在各地都在搞“数字政府”，很多老系统要改造，不能全盘重写，只能渐进式升级。这时候，原生、轻量、无依赖的 Web Components，反而是破局的关键。
六、写给同样迷茫的你
如果你也像我一样：
- 在大厂卷不动了
- 想转行但怕技术过时
- 或者一边刷 LeetCode 一边焦虑未来
我想说：别把技术当成非黑即白的选择题。
React 很强，但 Web Components 也有它的战场；
算法要刷，但解决实际问题的能力更重要；
考公不是“躺平”，而是把技术用在更需要的地方。
上周我和老婆商量，决定继续备考，但不再裸辞。白天写代码，晚上刷行测。房租3500，生活紧巴巴，但心里踏实多了。
昨天深夜，我给那个 tx-status 组件加了个 loading 动画，老婆凑过来看：“这绿点一闪一闪的，像不像宝宝的心跳？”
我愣了一下，笑了。
也许，技术的意义，从来不只是拿高薪、进大厂，而是让冰冷的代码，也能传递一点温度。
结语：趋势之外，是人的选择
Web Components 确实是“原生组件化的新趋势”，但它不会取代 React，就像 React 也没能消灭 jQuery。
真正的趋势，是我们如何在变化中保持清醒：
知道什么时候该用重型武器，什么时候该用瑞士军刀；
知道什么时候该冲刺，什么时候该稳住；
知道什么时候该为自己活，什么时候该为家人拼。
我是深圳南山的一个普通程序员，月薪22k，房租3500，老婆怀孕五个月，正在准备明年省考。
我不确定能不能上岸，但我知道——
无论在哪条路上，只要代码写得干净，人心守得正直，就永远不会“掉线”。
共勉。
评论 0