前端工程转型实践：从 Ember 迁移到 React，提升构建速度与研发效能

一家海外 SaaS 公司最近完成了一项重要的前端工程转型：将核心前端从 Ember 逐步迁移到 React。

这次迁移并不是为了追赶技术潮流，而是为了获得更快的构建速度、更高的开发效率，并让工程团队更好地使用 AI 驱动的开发者工具。对于正在思考前端技术栈升级、研发效能提升和 AI 编程落地的团队来说，这次从 Ember 迁移到 React 的实践，具有很强的参考价值。

在过去两年里，这家公司对前端工程实践做出了近年来最重大的调整之一：把核心前端技术栈从 Ember 迁移到 React。

这个决定并非草率做出。早在 2014 年，该公司重构主应用时，Ember 是一个非常合适的选择。它理念鲜明，强调“开箱即用”的开发方式，也符合当时团队一贯的工程风格：快速行动、减少反复决策，把主要精力放在解决客户问题上，而不是陷入无休止的架构争论。

随着业务发展，这个主应用最终成长为业内规模非常大的 Ember 应用之一，拥有超过 200 万行代码，以及 10 万多个合并请求。

但到了 2023 年，问题逐渐变得无法忽视：本地构建时间已经超过 90 秒，框架版本也相对陈旧，导致团队难以采用新的构建工具。虽然团队依然认可 Ember 社区的价值，也持续关注相关构建工具的改进，但从工程效率和未来发展来看，他们必须做出改变。

前端技术栈升级：选择一条新的道路

团队用对待产品决策的方式来处理这次技术栈转型：组织研讨会，进行健康检查，并设定明确的触发条件。

到 2023 年中期，过多触发条件已经被触发，团队不得不认真思考：什么样的前端技术栈，才真正有利于公司未来发展？

于是，他们决定寻找一条新的道路。

第一步，是明确理想中的前端框架应该是什么样的。团队根据自身工程原则制定评估标准，因为这次技术栈调整并不是为了“换技术而换技术”，而是为了加速整个研发组织的发展。团队将这个项目称为“前端的未来”。

经过评估和实验，React 很快成为最合适的选择。

这不是因为 React 更热门，而是因为它已经在公司部分产品和站点中被广泛使用，拥有成熟的生态系统、完善的文档，也被公司内部和整个行业的工程师广泛熟悉。更重要的是，React 能够更好地对接未来越来越重要的 AI 驱动开发工具。

从 Ember 迁移到 React 后，效果如何？

如今，“前端的未来”项目已经进入稳定推进阶段。React 已经成为该公司新 UI 开发的默认选择，带来的效果也非常明显。

首先是极快的反馈循环。

在 React 技术栈下，本地构建时间不到 10 秒，重建时间不到 1 秒。相比原有 Ember 应用超过 90 秒的构建时间，这对工程师的日常开发体验是巨大提升。

其次是更高的开发速度。

工程师普遍反馈，使用 React 后工作速度更快，也更容易保持专注。尤其是当 React 与现代 AI 编码工具结合使用时，开发者可以更顺畅地生成代码、修改组件、验证想法和完成重构。

再次是更广泛的团队采用。

自 2025 年 3 月以来，已经有 10 多个产品团队发布了基于 React 的功能，贡献了超过 840 个合并请求。这说明迁移并不只是少数团队的试点，而是在逐步成为公司前端开发的新默认方式。

最后是 AI 协同效应。

React 与现代 AI 工具的结合非常自然。设计师和工程师正在使用 AI 代理编写代码、从设计稿生成组件，甚至构建自己的设计开发环境。前端开发不再只是手写组件和调整样式，也开始进入 AI 辅助生成、验证和迭代的新阶段。

生产力提升是实实在在的。一位工程师的反馈很典型：“我原本预计需要一周才能完成的工作，两天就完成了。”

为什么 React 迁移对研发效能很重要？

这次迁移并不只是一次前端框架替换。它真正的意义在于，为未来十年的产品创新和研发效率奠定基础。

该公司的技术负责人曾提出一个目标：在未来一年内，将研发团队生产力提升一倍。要实现这个目标，团队需要减少工程摩擦，大规模应用 AI，并为工程师提供更现代、更高效的工具链。

React 正是实现这一目标的重要推动因素。

对于一个追求高标准和高目标的工程组织来说，把核心前端从 Ember 迁移到 React 是一项大胆变革。但这项决策背后的逻辑非常清晰：减少等待时间，提升交付速度，提高质量标准，让工程师把更多精力投入到真正重要的事情上，也就是为客户解决实际问题。

如果团队希望把这类技术栈升级真正转化为持续的研发效能提升，还需要让目标、客户反馈、需求、开发、测试、发布和知识沉淀形成闭环。比如 PingCode 这类智能化研发管理工具，可以覆盖研发全生命周期管理，并打通研发工具链，让迁移过程中的任务进展、质量数据和经验知识顺畅流转。

前端技术栈转型带来的启示

这次迁移给前端团队和技术管理者带来了几个值得借鉴的启示。

第一，技术选型需要服务于组织效率。

选择框架不应只看流行度，也不应只看团队历史偏好，而要看它是否能提升工程效率、降低协作成本，并帮助团队更快解决业务问题。

第二，构建速度会直接影响开发体验。

本地构建从 90 多秒缩短到 10 秒以内，重建时间缩短到 1 秒以内，看似只是工具链层面的优化，但它会极大影响工程师的反馈循环。等待越少，验证越快，团队就越容易保持开发节奏。

第三，AI 正在改变前端工程的技术栈选择。

未来的开发工具会越来越多地参与代码生成、组件搭建、重构和测试。一个框架是否拥有成熟生态、清晰模式和广泛训练数据，会直接影响 AI 工具的可用性和产出质量。

第四，大型迁移需要组织级推动。

从 Ember 到 React 的迁移不是单个工程师的重构任务，而是一次跨团队、跨产品线的工程转型。它需要明确目标、持续评估、分阶段推进，也需要让团队看到实际收益。

在这类跨团队迁移中，任务拆解、文档沉淀、目标对齐和节奏管理同样关键。Worktile 这类通用项目协作系统，可以承接任务、项目、文档、目标、日历和审批等协作场景，帮助不同角色围绕同一迁移目标保持同步，减少沟通断层和信息遗漏。

结语：前端工程的未来不只是框架之争

前端技术栈的演进，从来不只是框架之争。

真正重要的问题是：这套技术能否帮助团队更快获得反馈？能否减少复杂性？能否让工程师更高效地交付高质量产品？能否适应 AI 驱动的软件开发新趋势？

从 Ember 迁移到 React，并不是对过去技术选择的否定，而是一次面向未来的工程升级。

当产品规模、团队结构和开发工具都发生变化时，工程组织也必须重新审视自己的技术基础。真正成熟的技术团队，不会为了稳定而拒绝改变，也不会为了潮流而盲目迁移，而是会在合适的时机，选择最能支撑未来发展的道路。