Web Components：原生组件化开发新趋势 —— 一个成都前端“幸存者”的实战复盘
去年十月的一个深夜，我坐在成都高新区某共享办公空间的角落里，窗外是早已熄灯的写字楼群，桌上摆着半杯凉透的瑞幸。手机震动了一下，钉钉弹出一条消息：“公司决定暂停运营，全员协商离职。”
那一刻，我盯着屏幕愣了足足三分钟，脑子里只有一个念头：下个月房租3500怎么交？老婆刚查出怀孕，产检费用还没着落。
那家公司是我创业三年来的第三家前端岗，从React项目搭到微前端架构，自以为技术栈扎实、经验丰富。结果呢？公司现金流断裂，投资人撤资，我们这些“核心技术人员”连N+1都没拿全。回家路上，秋雨淅沥，我一边骑共享单车一边刷BOSS直聘，看到有岗位写着“熟悉Web Components优先”，心里一咯噔：这玩意儿我只在MDN上扫过一眼，实际项目里压根没用过。
被现实打脸后，我才认真看Web Components
失业后的两周，我每天泡在图书馆（比在家省电），开始疯狂补课。不是那种“收藏即学会”的伪学习，而是真的敲代码、跑demo、读规范。原因很简单：成都本地前端岗位本就不多，大厂又偏爱“全栈”或“懂算法”的人，而我这种只会写业务组件、调样式、搞状态管理的“纯前端”，在简历筛选阶段就被HR默默划掉了。
有一次面试，面试官是个戴黑框眼镜的Java后端转架构师，他翻完我的GitHub后问：“你做过微前端吗？有没有考虑过用原生能力做组件隔离？比如Web Components？”
我支支吾吾：“我们之前用React封装组件……”
他点点头，语气平淡：“React很好，但过度依赖框架在中小公司风险很高——你们公司倒闭了，技术债谁接？”
这句话像一记闷棍砸在我头上。是啊，我们团队花了半年时间用React + TypeScript + Redux Toolkit搭了一套内部管理系统，结果公司一倒，整套代码成了“数字骨灰盒”。没人维护，没人接手，连交接文档都散落在几个飞书文档里。
那一刻我突然意识到：框架会变，公司会倒，但浏览器原生的能力，永远在那里。
从“玩具”到“武器”：我在副业项目里试水Web Components
失业期间，我接了个外包单子：给一家本地茶叶电商做商品展示组件。客户要求不高，但特别强调“要能嵌入任何页面，不依赖jQuery也不依赖Vue/React”。我一开始想用iframe硬套，但性能太差，加载慢还跨域问题一堆。
灵机一动，我决定试试Web Components。
说实话，第一次写customElements.define('tea-product-card', TeaProductCard)时，手都在抖。毕竟习惯了React的JSX和Hooks，突然回到“原生DOM操作+模板字符串”的世界，感觉像从iPhone退回诺基亚3310。
但神奇的是，三天后，这个组件居然跑起来了：
class TeaProductCard extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: 'open' });
}
connectedCallback() {
const { name, price, image } = this.dataset;
this.shadowRoot.innerHTML = `
<style>
.card { border: 1px solid #eee; padding: 16px; }
img { width: 100%; height: auto; }
</style>
<div class="card">
<img src="${image}" alt="${name}">
<h3>${name}</h3>
<p>¥${price}</p>
</div>
`;
}
}
custom-elements.define('tea-product-card', TeaProductCard);
客户把这段代码复制粘贴到他们的PHP后台生成的HTML里，刷新一下，商品卡片直接显示出来。没有打包、没有构建、没有node_modules——它就像一段普通的HTML标签，安静地工作着。
那天晚上，我给老婆发消息：“今天赚了2000块，够交一个月房租了。”她回了个笑脸：“你终于不用天天愁眉苦脸了。”
Web Components vs React：不是取代，而是互补
很多人一听“原生组件化”，就以为是要干掉React。其实完全不是这回事。
React的优势在于开发体验、状态管理和生态工具链。你写个表单，用Formik + Yup验证，配合React Query拉数据，效率高得飞起。但在某些场景下，它的“重量级”反而成了负担：
- 客户只是想要一个可复用的UI片段，嵌入老系统（比如Java写的JSP页面）
- 团队没有前端工程化能力，连Webpack都不会配
- 公司随时可能倒闭，代码需要“零依赖”存活
Web Components的核心价值，恰恰是低耦合、高移植性、框架无关。它不解决状态管理，不提供虚拟DOM，但它能让你写的组件“活”在任何地方——哪怕五年后React已经没人用了，只要浏览器还在，你的<my-calendar>依然能跑。
举个例子：我们之前公司有个日历组件，用React写的，依赖moment.js和一堆CSS-in-JS。后来市场部想把它放到WordPress博客里，折腾半天，最后不得不重写成jQuery插件。如果当初用Web Components，一行<company-calendar events="..."></company-calendar>就搞定。
别被“原生”吓住：现代Web Components已经很香了
早期Web Components确实难用：模板得手写字符串，样式作用域靠shadow DOM但调试困难，属性传递只能靠dataset。但现在不一样了。
得益于Lit（Google出品的轻量库），写Web Components几乎有了“类React”的体验：
import { LitElement, html, css } from 'lit';
import { customElement, property } from 'lit/decorators.js';
@customElement('user-profile')
export class UserProfile extends LitElement {
@property({ type: String }) name = '';
@property({ type: Number }) age = 0;
static styles = css`
.profile { padding: 12px; background: #f9f9f9; }
`;
render() {
return html`
<div class="profile">
<h3>${this.name}</h3>
<p>Age: ${this.age}</p>
</div>
`;
}
}
你看，装饰器定义属性，模板用tagged template literals，样式内联但自动scoped。体积只有几KB，比React runtime小一个数量级。
而且，Web Components可以和React共存！通过react-web-component这类适配器，你甚至能把Web Component当成React组件用：
// 在React项目中
import './user-profile.js'; // 注册自定义元素
function App() {
return <user-profile name="张三" age="28" />;
}
反过来也行——把React组件打包成Web Component（虽然有点重，但可行）。这种灵活性，在中小公司或混合技术栈团队里简直是救命稻草。
成都前端的困境：算法、Java、综合能力
说到这儿，不得不提成都前端圈的现状。
我和几个前同事常约在九眼桥的烧烤摊喝酒。上周五晚上，阿强（前阿里P6，现在回成都养老）喝多了吐槽：“成都这边招前端，JD清一色写‘熟悉算法’、‘了解Java后端’、‘具备综合技术视野’……你一个写页面的，难道还要去LeetCode刷Hard题？”
他说得对，也说得不对。
对的是：本地创业公司资源有限，一个人恨不得当三个用。老板希望前端不仅能写界面，还能对接API、调数据库、甚至部署上线。这时候，如果你只会React Hooks，确实容易被淘汰。
不对的是：算法和Java不是目的，解决问题才是。
我在学Web Components的过程中，顺带研究了Custom Elements的生命周期、Shadow DOM的事件穿透、Template的性能优化——这些本质上都是“浏览器底层机制”的理解。而理解底层，恰恰是“综合能力”的体现。
比如，你知道为什么Web Components的属性要用attributeChangedCallback监听？因为DOM attribute和JS property是两套系统。这种知识，和你刷“反转链表”一样，都是在训练抽象思维和系统认知。
至于Java？我不懂Spring Boot，但我能看懂RESTful接口文档，能用Postman调试，能在前端Mock数据。这就够了。真要写后端，不如老老实实用Node.js搭个BFF层，何必硬啃Java？
写给和我一样的“幸存者”：技术人的抗脆弱性
现在我在一家做智能硬件的小公司上班，月薪18k（比上份少，但稳定）。团队5个人，前后端全包。上周我用Web Components封装了一个设备状态面板，嵌入到客户的旧版管理后台（基于Struts2 + JSP），客户老板当场拍板续约。
回望那段失业的日子，我最大的收获不是学会了Web Components，而是明白了：技术人不能把自己的价值绑定在某个框架或公司上。
React会更新，Vue会迭代，甚至TypeScript明天可能被Deno Runtime取代。但只要你理解组件的本质是封装与复用，理解浏览器如何渲染页面，理解用户真正需要什么，你就不会被淘汰。
Web Components不是银弹，但它代表了一种思路：回归原生，拥抱标准，降低依赖。在成都这种“高性价比但机会有限”的城市，这种思路尤其重要——因为你不知道下一家公司会不会明天就发不出工资。
最后一点真心话
写这篇文章的时候，老婆在旁边睡着了，肚子微微隆起。我关掉VS Code，看了眼余额：还有2.3万存款，够撑三个月。
我知道，前端这条路不好走。尤其是在成都，薪资天花板低，技术氛围不如北上广深。但正因为如此，我们才更需要打造可移植、可复用、不依赖特定环境的技术资产。
Web Components或许不会让你涨薪到30k，但它能让你在下一次裁员潮来临时，多一份底气。
就像那个茶叶电商的客户说的：“你这个组件，我们用了半年，一次bug都没出。”
我说：“因为它没用任何框架。”
他笑了：“那最好，我们技术部就两个人，一个会PHP，一个会Excel。”
你看，有时候，简单就是最强的护城河。
给读者的建议：
- 别鄙视“原生”：花一周时间，用Lit写一个真实可用的Web Component（比如天气插件、评论框）。你会发现它比想象中强大。
- 在现有项目中渐进式引入：比如把公共Header/Footer抽成Web Component，减少框架耦合。
- 理解标准，而非追逐潮流：Web Components是W3C标准，浏览器厂商都在支持。这种技术，十年后依然有用。
- 提升“综合能力”不等于成为全栈：你可以不懂Java，但要能和技术栈不同的人协作；你可以不刷算法，但要理解数据结构如何影响性能。
技术人的安全感，从来不是来自大厂title，而是来自——无论世界怎么变，你写的代码，依然有人用。
（完）
作者：一个在成都挣扎求生的前端开发者，经历过三次创业公司倒闭，目前专注于“能活下去的技术”。
如果你也在成都，欢迎加微信聊聊（备注“Web Components”），一起搞点不依赖公司的副业。
评论 0