从“写页面”到“构建系统”
在过去，前端开发者被称为“切图仔”，我们只需要将设计稿转为HTML/CSS/JavaScript。而今天，前端开发几乎成为一种系统级工程，我们谈论模块化、微前端、WebAssembly、边缘渲染。讽刺的是，当我们用越来越多的工具去解决由工具本身带来的问题时，用户看到的页面表现并没有本质提升——甚至因为加载了上百KB的框架运行时而变得更慢。这不是技术的退步，而是思维的扭曲。我们错把“工程复杂度”当成了“技术深度”，把“依赖数量”误认为“架构的先进性”。
这种扭曲的根源在于我们默认了“大问题需要大方案”的思维模式。在前端场景中，一个简单的博客站点和一个复杂的在线编辑器，本应属于完全不同的设计范式，但如今它们共享着几乎相同的搭建流程——vite、react、redux、router、tailwind……我们像使用统一治具一样对待所有问题，然后回过头来嘲讽那些用纯PHP或jQuery搭建站点的人是“老古董”。真正需要被审视的，恰恰是我们自己。
类似地，组件化本身的初衷是复用与单一职责，但当组件库拥有了自己的版本发布、代码生成器和文档站点，甚至组件之间的依赖关系需要图数据库来维护时，我们已经偏离了“用户”而回到了“开发者自嗨”。每次升级框架带来的破坏性变更，都需要一个专门的迁移团队来负责，这难道不是对“抽象”的最大讽刺吗？我们创造了怪物，然后为喂养这个怪物而加班。
框架之争：谁在解决真实问题？
Vue、React、Angular三大框架的竞争从未停止，但这竞争的焦点早已从性能和体验切换到了周边生态和开发体验。React的Server Components、Vue的Vapor Mode、Svelte的编译时优化……这些都试图在“运行时”和“编译时”之间寻找平衡。但一个有趣的对比是：Svelte重新强调编译时消除框架，而SolidJS则选择了细粒度响应式，而React仍然坚守运行时协调。它们都将自己包装成“正确的道路”，但最终的结果是——没有任何一项技术能在复杂的实际应用中消除其固有缺陷。
当我们对比传统多页面应用与现在的单页应用时，会发现SPA的初衷是实现无刷新交互，但代价是SEO问题、首屏白屏、路由守卫、状态同步、内存管理等一大堆额外负担。现在业界又提出了MPA+智能预渲染的方案，仿佛又回到了起点。这些来回震荡的“趋势”本质上是同一个问题在时间维度上的反复：我们从未真正理解“内容应用”与“任务应用”的边界，也因此无法为每种形态选择最合适的技术栈。
更令人反思的是，框架将开发者训练成了“框架思维”的奴隶。当被问到如何实现一个“点击按钮后获取数据并显示列表”的功能时，现代前端开发者需要思考：用useEffect还是useQuery？用server state还是client state？需要拆分成独立组件吗？要不要做loading skeleton？这些决策在纯JavaScript中不过是fetch().then(render)两行代码而已。从何时起，我们失去了说“这不值得”的勇气？
复杂度守恒定律：前端工程化的终极困境
我想提出一个“前端复杂度守恒定律”：无论你采用什么技术栈，系统的总复杂度都不会消失，只能被转移到某个层次——要么在源码中被显式处理，要么在工具链中被隐式处理，要么在运行时被透明处理。传统前端把复杂度放在程序员头上，每个页面都手工管理DOM和事件；现代框架把复杂度转移到框架的调度器和虚拟DOM中，但程序员依然需要面对状态一致性、副作用管理等新问题。当我们用TypeScript消灭了部分运行时错误，却引入了类型体操与泛型地狱；当我们用状态管理库解决了跨组件通信，却引入了action/reducer/redux-thunk的样板代码。
这个守恒定律的推论是：过度工程化是一种逃逸行为——将显性、可感知的问题，转化为隐性、需要在调试时才能感知的问题。这让我们在写代码时的“爽感”往往以未来数周的“痛苦感”为代价。独立开发者可以使用最笨重的方式快速上线一个产品，而大公司则必须在“可维护性”的名义下忍受十倍人力成本。但用户真的需要我们的代码“可维护”吗？不对，用户只需要响应速度、视觉流畅与功能可靠。可维护性是给工程师自己找的台阶。
更值得深思的是，前端三大细分领域——UI、状态、路由——本应是一门学科的整体，却被强行拆分成独立库。我们为每个领域创建了抽象，然后试图用另一个库来协调这些抽象之间的关系。例如，react-router和react-query是两套心智模型，而redux将这些模型再次映射到自己的数据流中。这难道不比直接用一条同步流程来描述更复杂吗？诚然，当代码库大到一定规模时，组织是必要的，但我们从不定义“一定规模”的阈值，于是每行代码都被当成必须遵守复杂架构的砖块。
告别幻觉：以用户为尺度的前端设计
那么，我们应该彻底抛弃框架，回到jQuery吗？当然不是。我想表达的核心是：前端开发者需要重新建立以“用户可感知的质量”为唯一标准的评价体系。这意味着当我们可以用原生懒加载+骨架屏完成优化时，就不必动用Service Worker和PWA全家桶；当我们的表单只有三个字段时，就不必引入react-hook-form和zod校验；当更新只需要修改一个DOM属性时，就不必使用虚拟DOM的协调算法。这不是反技术，而是反对“为了技术而技术”。
我主张一种“预算思维”——每个页面、每个交互都有它的复杂度预算和性能预算。技术选型必须在这个预算内进行，而不是先选型再寻找理由。一个类似的例子是，很多团队在项目开始时就引入微前端架构，仅仅是认为“未来可能会扩展”，这种面向未来的代价是当下开发效率的显著下降，以及构建链路的指数级变长。而真正的扩展需求往往在半年后才出现，那时原本简单的代码早已迭代成遗留系统，微前端反而成为重构的最大包袱。
最后，我们应意识到前端开发不仅是技术领域，还是认知领域。当我们手中拿着锤子，一切看起来都像钉子；当我们脑中常想着“组件”、“状态”、“抽象”，任何需求都会被拆解成组件树和状态流。但用户看到的并不是组件树，而是产品。产品的好坏取决于第一个像素的呈现与最后一次滚动的流畅。如果我们无法在这两个维度上交出满意答卷，那么无论我们引入了多少编译引擎、同构方案或AI编程助手，都只是在自己的后花园里自high。让我们松开手，让技术回归简单，让思想重新直面用户。或许，这才是前端开发的下一个“版本”。