Hacker News 中文摘要

RSS订阅

我重复开发同一应用10次：评估移动性能框架 -- I built the same app 10 times: Evaluating frameworks for mobile performance

原文链接 | HN讨论 | 2025-10-28 16:30:32

文章摘要

作者为团队选择适合移动端的开发框架，测试了10种主流框架的性能表现。最初比较Next.js、SolidStart和SvelteKit时发现React架构存在根本性问题，于是扩大测试范围，全面评估各框架在移动网络环境下的实际表现，为房地产经纪人等需要稳定移动应用的场景提供决策依据。

文章总结

移动端框架性能对决：10次构建同一应用的深度评测

项目背景

我们团队需要为房地产经纪人开发一款移动优先的网页应用。核心需求是：应用必须在移动端表现出色——不仅能用，还要快。当经纪人在开放日或停车场等网络不稳定的场景下使用时，缓慢加载的界面会直接影响专业形象。

评测范围扩展

最初计划对比Next.js、SolidStart和SvelteKit三个框架，但测试发现React架构存在根本性性能瓶颈。最终将评测扩展到10个主流框架，包括： - 传统三巨头：Next.js（React）、Nuxt（Vue）、Analog（Angular） - 新锐框架：Marko、SolidStart、SvelteKit、Qwik City - 混合方案：Astro+HTMX、TanStack Start（React/Solid双版本）

关键发现

  1. 性能断层
    新锐框架（Marko/SolidStart/SvelteKit/Nuxt）的首屏渲染时间（FCP）稳定在35-39ms，比Next.js快12-13倍。4ms的差异对用户无感知，但与传统框架存在数量级差距。

  2. 包体积冠军
    Marko以28.8KB压缩体积（88.8KB原始）成为最小方案，比Next.js小6.36倍。即使是表现最好的传统框架Nuxt（72.3KB压缩），体积也是Marko的2.5倍。

  3. 架构差异

  • MPA框架（如Marko/HTMX）每路由增量极小，适合功能扩展
  • SPA框架需预加载路由和运行时，基础体积更大
  • 可恢复性方案（Qwik）通过延迟加载实现即时交互
  1. Vue的例外表现
    Nuxt以224.9KB原始体积实现38ms FCP，证明传统框架通过优化也能达到新锐框架性能，而React/Angular暂无类似路径。

移动性能的商业价值

  • 用户流失：研究显示性能延迟导致28%用户永久流失，是宕机的3倍
  • 实际成本：在3G网络下，113KB的体积差异意味着1.5-2秒的加载延迟
  • 缓存误区：版本更新会触发重新下载，第一印象至关重要

测试方法论

  • 统一基准：所有应用使用相同数据库（SQLite+Drizzle ORM）、UI组件（17个）和功能（看板CRUD、拖拽、评论等）
  • 严格测量：10次冷加载测试取中位数，清除缓存模拟首次访问
  • 依赖控制：仅包含必要依赖（如拖拽库），避免状态管理等非必要包

框架架构对比

| 类型 | 代表框架 | 核心特点 | |--------------|----------------|--------------------------------------------------------------------------| | 虚拟DOM | Next.js | 组件重渲染+DOM差异比对，RSC序列化增加开销 | | 细粒度响应式 | SolidStart | 信号追踪依赖，组件只运行一次 | | 编译优化 | SvelteKit | 构建时转换为DOM操作，运行时代码极少 | | 可恢复性 | Qwik | 序列化应用状态，按需懒加载交互逻辑 | | HTML驱动 | Astro+HTMX | 服务器返回HTML片段，客户端零状态管理 |

性能数据（看板页）

| 框架 | 原始体积 | 压缩体积 | FCP | 相比Next.js缩减 | |-----------------|----------|----------|-------|-----------------| | Marko | 88.8KB | 28.8KB | 39ms | 6.36x | | SolidStart | 128.6KB | 41.5KB | 35ms | 4.39x | | SvelteKit | 125.2KB | 54.1KB | 38ms | 4.51x | | Nuxt | 224.9KB | 72.3KB | 38ms | 2.51x | | Next.js | 564.9KB | 176.3KB | 467ms | - |

选择建议

  • 绝对最小体积：Marko（Beta阶段但稳定）
  • React迁移路径：SolidStart（相似JSX语法）
  • 最佳开发体验：SvelteKit（渐进增强默认支持）
  • 成熟生态：Nuxt（Vue插件体系+优秀性能）

深层启示

  1. React的性能天花板：TanStack Start移除Next.js开销后，React运行时仍占100-118KB压缩体积，这是架构决定的不可优化成本。

  2. 技术封建主义警示：React Native的移动策略实质是将开发者推向应用商店的抽成体系，而高性能Web应用是保持开放网络的关键。

  3. 编译器的局限性：Next.js 16的自动Memo优化无法解决基础体积问题，而新框架通过重新设计响应式模型实现根本性突破。

行动建议

  • 新项目应优先考虑新锐框架
  • 现有React项目可评估TanStack Start缩减体积
  • 所有团队都应建立移动性能预算意识

完整测试代码和方法论详见项目仓库。在移动优先的时代，框架选择直接决定用户体验和商业竞争力。

评论总结

评论总结

1. 对Svelte的积极评价

  • 观点：Svelte因其开发体验简单高效而受到高度评价，适合生产环境应用。
  • 引用：
    • "Svelte/SvelteKit is working in the 'easy' difficulty level. You can achieve the same end result and keep your sanity."
    • "As somebody using Svelte for a real production application, I can only 100% agree with their recommendations."

2. 对移动优先设计的争议

  • 观点：部分评论认为过度关注移动端可能导致桌面体验下降，且并非所有应用都适合移动端。
  • 引用：
    • "Ugh. That thinking is what gets you things like mandatory login via apps for your desktop."
    • "And not every application makes sense on a phone."

3. 对框架性能的关注

  • 观点：Marko和Solid因性能优异受到关注，但部分用户认为开发体验和舒适度更重要。
  • 引用：
    • "Interesting to see Marko and Solid topping the performance metrics."
    • "I prefer to use whatever I'm more comfortable with than something that is measurably the fastest."

4. 对React Native和原生开发的讨论

  • 观点：部分用户希望看到React Native或原生开发的比较，认为它们在移动端更具优势。
  • 引用：
    • "I'd be interested in seeing React Native in this comparison."
    • "Most sane people would write a native app for this sort of thing if money was on the line."

5. 对文章质量的评价

  • 观点：文章因技术深度和可读性受到广泛好评，但部分用户指出其移动端展示存在技术问题。
  • 引用：
    • "The quality of the writing here is remarkable."
    • "You might want to fix your horizontal scroll on mobile."

6. 对开发选择的个人偏好

  • 观点：部分开发者倾向于选择熟悉或舒适的框架（如Vue、Quasar），而非单纯追求性能。
  • 引用：
    • "We ended up with Vue/Nuxt since we agreed they have the most intuitive syntax for us."
    • "I have landed on Django/React(vite). I have mastered this and can go from idea to app running in production in a matter of hours."

7. 对移动端性能的重视

  • 观点：移动端性能（如加载速度、延迟）被强调为关键指标，但部分用户认为带宽和缓存策略同样重要。
  • 引用：
    • "Mobile is the web. That's why."
    • "As ever on mobile it's latency, not bandwidth, that's the issue."

8. 对ChatGPT生成内容的质疑

  • 观点：部分用户怀疑文章由ChatGPT生成，认为其内容重复或缺乏深度。
  • 引用：
    • "this article was written by ChatGPT. I'm tired."
    • "Thanks ChatGPT for your valuable slop."

9. 对技术趋势的反思

  • 观点：部分开发者对不断涌现的新框架感到疲惫，更倾向于稳定和熟悉的技术栈。
  • 引用：
    • "I rather learn something else than look through the docs of yet another web framework."
    • "React seems like a recipe for a bloated bureaucratic mess."

10. 对实际应用场景的讨论

  • 观点：性能优化的优先级取决于应用类型（内容网站vs. Web应用），且用户缓存和预加载策略很重要。
  • 引用：
    • "If you are building a content site, bundle size is obviously massively important."
    • "Preload as much data as possible such that navigations are instant."