周三下午，我为了改一个按钮的颜色，再次等了三分钟的Vite热更新。这个项目的node_modules有3479个包，总大小1.2GB。而它实际功能只是三个按钮、一个列表、一个表单。我当时就想骂娘，但骂完还是打开React官方文档找use()的用法。因为我老板说要用最前沿的技术。
后来我做了个不算严谨的实验。拿同一个页面跑了四个方案：React 19 + Vite、Vue 3.5 + Vite、Svelte 5 + Vite、原生Web Components + Vite。页面包含表单输入、列表渲染2000条、筛选、主题切换。我记录每个方案的production build gzip体积，还有Lighthouse的性能分数。跑了三遍取最好成绩。React的产物是187KB，gzip后62KB；Vue是96KB，gzip后31KB；Svelte是89KB，gzip后29KB；原生写了点helpers，12KB，gzip后4.1KB。性能分数，React是62分，Vue是76分，Svelte是82分，原生是94分。测的时候用的是Moto G4模拟。最搞笑的是，React这边我根本没用上use()，因为服务端数据是室友帮我写的Express接口，我只需要fetch。
但数字不是全部。写代码的过程才让我冒冷汗。React有useEffect、useMemo、useCallback，稍不留神就循环依赖，我调了一天。Vue这边模板语法倒是亲切，但有个input事件在某次更新后丢失了焦点，查了半天是官方警告的一个实现细节。Svelte 5的runes写起来像Solid，很爽，但是我想找个现成的Tree Shakeable的日期选择器，GitHub上没几个能无缝用的，逼得我去看源码。原生Web Components纯粹得不像是2025年的技术，但一旦要接第三方地图SDK，那丑态百出，所有方法都要自己bind this。
所以我的观点可能有点反主流：框架的本质是帮你管理状态和DOM的同步，可如果你根本没有需要高频同步的状态，框架就只是沉重的拐杖。我现在做一个新项目会先数一数：页面里需要跨组件的状态有没有超过10个，数据变化频率有没有超过每秒1次。如果没超过，我直接拿原生JS加HTMX，甚至只用HTML和SSR。如果超过，我就用Svelte，因为它编译后生成的代码最少。只有一种情况我会选React——团队里那帮人只熟悉React，交期又紧，那就继续用，但别骗自己说这是技术选型，这是人力惯性。
