我到现在都记得那次 sprint planning。
我盯着一张工单，内容是：把我们的 UI 库从 2.7.1 升到 2.7.3。 对，你没看错——两个 patch 版本。
没有新功能。 只是安全修复、依赖更新。
评估工期？ 三天。整整三天。
为什么？因为你动一个依赖，会炸三个；炸了三个就得改组件 import；改完 import 还得重构测试；重构测试再顺手把你的理智也一起重构掉。
最后呢？换来什么？ 一个更“高级”的 hook 名字？一个更“时髦”的 API 语气？
那一刻我真的“啪”地一下醒了。
而如果你这十年一直在做 Web，你一定懂我在说什么—— 我们一直在一台叫“框架迭代”的仓鼠轮上冲刺。冲得飞快，原地不动。
Angular、React、Vue、Svelte、Solid、Astro、Qwik、Remix、Next、Nuxt、SvelteKit…… 你还没念完，世界上已经有人准备发布一个叫 “Next++ Ultra Remix Fusion 2” 的东西了。
框架要死了吗？
先把话说死：框架不会死。
React 不会凭空蒸发。Vue 不会突然崩盘。Svelte 不会牵着 jQuery 的手走进夕阳。
但“框架是所有项目的默认答案”这件事——正在结束。
我们正在进入一个更现实、更清醒的时代：
- 浏览器 API 终于像样了
- 工具链开始模块化了
- 性能重新变重要了
- 框架变成“可选项”而不是“信仰”
开发者正在意识到一件看起来很大逆不道的事：我们不需要 2MB 的包和一个虚拟 DOM，才能把按钮文字改一下。
震撼吗？ 但这就是事实。
痛苦的现实：框架不是因为优雅才火的
框架当年变成主流，并不是因为它们“美”。 它们是因为：当年的 JavaScript 真的很难用。
DOM 操作又脏又乱。 兼容性像地狱。 状态管理靠胶带。 工程化几乎不存在。
框架给了我们：
- 抽象
- 模式
- 工具
- 以及某种“我终于能交付了”的精神安慰
但今天？平台自己追上来了。甚至很多地方已经超过了。
Exhibit A：原生 JS 已经不再让人想哭
以前你要更新 DOM，像在徒手拆炸弹。 现在你看看这段：
const btn = document.getElementById('save');
btn.addEventListener('click', async () => {
const res = await fetch('/api/save');
btn.textContent = res.ok ? 'Saved!' : 'Error';
});
可读。直接。没有 jQuery。没有 useState。没有 400KB runtime。 你甚至不需要写一段“为了更新 UI 而更新 UI 的 UI”。
Exhibit B：Web Components 也不再是笑话
你想复用组件？想封装行为？不想交框架税？你现在有选择：
class Counter extends HTMLElement {
count = 0;
connectedCallback() {
this.innerHTML = `<button>Clicked ${this.count}</button>`;
this.addEventListener('click', () => {
this.count++;
this.innerHTML = `<button>Clicked ${this.count}</button>`;
});
}
}
customElements.define('my-counter', Counter);
可复用。原生。跨框架甚至无框架。 你想在哪用就在哪用。没有“迁移成本税”。没有“版本神罚”。
我们不愿承认的框架陷阱
很残酷的一句话：很多时候我们用框架，不是因为需要，而是因为习惯。
框架已经从工具变成：
于是 主流前端框架 如 React 不再仅仅是一个库。 它变成一种信仰体系。一种宗教。一种人格标签。
招聘里最常见的一句是什么？
“我们在招 React 工程师。”
而不是：
“我们在招 Web 工程师。”
我们是不是忘了 2013 年之前 Web 也能跑、也能活、甚至也能优雅？
框架仍然很强：只是它不该管所有事
我不是来烧框架的。我是来烧“默认框架”的。
框架在哪些场景仍然统治力爆表？比如：
- 大规模设计系统
- 超复杂仪表盘
- 组件复用到离谱的产品
- 超大团队需要统一范式与 onboarding
你在做 Figma、Notion、复杂企业系统？React 合理得很。
你在做个人博客？也许你只是想用大炮打蚊子。
真正的未来：更小、更轻、更“不押宝”
我们正在看到一种新趋势： 不是“一个框架统治一切”，而是“按需组合”。
比如：
- 微型库：htmx、Alpine.js
- 元框架与工具：Astro、Vite
- native-first 的写法
- SSR 回潮
- partial hydration / islands 架构
这不是框架之死。 这是框架迷信之死。
我们正在从：
“我该用哪个框架？” 转向：
“我真的需要框架吗？”
这才是 Web 的平衡感回归。
说句不那么体面但很真实的话
大多数 App 并不需要：
- 客户端路由
- 虚拟 DOM diff
- 十层状态抽象
- CSS-in-JS
- hydration
你的 Todo App 不需要 hydration。 你的落地页不需要 Redux。 你的作品集不需要 SSR。
我们这几年一直在“剃牦牛”，不是因为用户需要，而是因为框架告诉我们“这才专业”。
可落地的建议
1）选框架前先问三句：
- 我到底要解决什么问题？
- 这项目复杂到值得那套工具链吗？
- 原生 JS / Web Components 能不能覆盖 80%？
2）试着不用框架写一个小组件 就一个：弹窗、计数器、表单都行。 你会学到的东西，比刷一百个教程都多。
3）别把框架当职业 你的职位不是 React。你的技能不是 JSX。你的价值也不是 useEffect。
4）用工具，不要被生态绑架 能用 Vite 就别先上 Next 全家桶。 能用 Astro 就别 React 满天飞。 能用 Alpine.js 就别为了一个交互把 Vue 整套搬进来。
5）接受“简单不是退步” 极简不是业余。原生 API 与 Web Components 不是过时。 相反，它们可能是未来最稳的底座。
所以：这是“框架的终结”吗？
不是。 但这是以下东西的终结：
这也是以下东西的开始：
而且说真的：早就该这样了。
最后
这里不是反框架。 是反“框架默认”。
如果我们更少地选择框架，我们反而会更好地使用框架。
也许下次你再看到一个“patch 升级”，它就不会再花掉三天，顺便带走你对生活的热爱。
如果这篇让你思考、发笑、或者愤怒——很好。欢迎在 云栈社区 与其他开发者继续探讨这个话题。
不同意？更好。
如果你正好认识一个正在从 React 17 迁移到 18 的朋友—— 把这篇转给他，当作精神止痛药。
或者留着，等下一次依赖审计让你 PTSD 发作时再翻出来。
发表于 2025-12-31 06:08:07
|
查看: 24|
回复: 0
