2025 年，前端攻城狮要怎么整活？

前言

2024 年就这么过去了。

虽然前端整个求职市场还是如同一潭死水，整体大格局上仍旧以汰换为主。但是好消息是，裁员的情况似乎也少了（应该是这样吧？）。

新的一年来了，24 年不管怎么来，都是过去了，未来才是重要的不是吗。那么新的一年要做些什么呢，本文仅从大方向上给出一些初步的建议，不涉及具体的事项，希望可以引发大家的一些讨论和共识。

具体每个方向具体展开的话一篇文章可能承载不下，有机会我们再做些讨论。大家有什么想法也可以在评论区发表一些意见和想法，在新年开始之际，一起定下一个，新的目标。

共同成长，前端 fighting。

2024 发生了些什么

回顾下 2024 年，比较大的几件事情有：

1. react 发布了第 19 个版本，在该版本中，react 引入了一个新的 hook：use，用来解决异步数据流转的问题。但是具体在业务开发中会带来哪些实际影响的还有待实践。

2. 另外一件 react 相关的事情是，react 发布了新的 Compiler，尝试在编译环境解决 react 开发中遇到的性能问题。让开发者可以更好的把精力集中在业务开发中。这也将进一步降低 react 复杂应用的开发门槛。

3. 相比 react，vue 的噱头则大了很多。今年 vue 引入了 alien-signals，号称可以提升 400%的性能，在这业务日益复杂、性能需求日益增加的今天，还是有着不小的吸引力的。

4. 构建工具上，整体还是 rust 和 vite 两大正营在挑大梁。基于 rust 语言的 rspack，在今年已经有了相对完善的生态，大部分业务场景下都可以相对平滑的从 webpack 迁移到 rspack，构建速度基本可以提升 50%以上吧。vite 今年势头非常强劲，vite6.0 引入了新的 Environment API，帮助开发者解决多环境编译问题；vitest 发布了 2.0 版本，可以更好的基于 vite 生态去做单元测试。

5. 其余方面，nodejs 今年发布了两个正式 版本，大版本号来到了 23，比较大特性就是支持了 require(esm)，意味着你可以在 CommonJS 文件中加载 ESModules 文件（esm 和 commonjs 的兼容问题算是有了一个解决方案）。然后是几乎处于半凉状态的 react-native，今年在 0.76 版本开始，默认启用的新的架构，并带来了新的 devtools，希望可以在性能和调试层面都给开发者带来全新的体验。

2024 年，大家都在做什么

当然 2024 年，还发生很多其他事情，以上主要是挑了几件我个人认为比较重要的事情来说。

对上述发生的事情，做一个简单的总结，其实可以发现，整体来讲，业界去年发生的事情是围绕三个方向的展开的：开发体验、性能以及稳定性。

为了更清晰的看清楚这些事情，我做一个简单的归类：

• 开发体验

• react19 引入的新特性 use 显然是为了降低 react 异步数据流转这一开发场景的业务复杂度

  require(esm)，解决了 Commonjs 和 ESModules 文件混用的问题，在当前 node 新老两种模块方案混用的今天，实在是不小的惊喜

  react native devtools，调试工具，号称体验对齐 web 工具

  vite6.0 新的 Environment API

• 性能

• react Compiler 主要目的应该是为了解决 react 渲染带来的性能问题，当然因为是在编译期自动去做了这件事情，对整体的开发体验和开发门槛也会有影响，但是从实际结果出发，还是归类到了性能下。

  vue 的 alien-signals，最大的噱头就是性能提升，无需多说。

  react-native 新架构，这部分升级比较大，但是从《react 全新架构来了》一文中看，最大的提升也是性能

  rspack（或者是 rust 生态），构建性能提升。

• 稳定性

• vitest，单测工具

分类之后，我们看到，三个方向，开发体验和性能相关分别各占 4 项，稳定性占一项。

同样的我们也看到一个事实，前端似乎已经很久没有全新的、有影响力的轮子出现了。或者说，优秀的开发者们越来越少的将精力投入到了新轮子上。

2025 年对于一线开发方向应该是什么

从社区的经验上看，还是开发体验、性能和稳定性三个方面为主。

先各自说下三个方向的特点以及可以发力的点。

开发体验方向上，虽然前端现在大的问题基本都已经被解决，但是在一些小范围的细分场景，还是有很多事情可以做。业界大的框架上只能去做一些相对通用的解决方案，但是具体某些业务领域有自己的业务痛点，这部分痛点还是可以被识别并形成解决方案的。

性能方面，我记得曾经有句话叫，性能的问题都可以交给硬件迭代去解决。之前我对这句话深信不疑。但是随着深入一线业务越久，我越发现这句话是不对的。硬件虽然在提升，但是我们的业务复杂度也同样在提升，并且有时候我们的业务复杂度提升甚至是大于硬件提升的。此外用户对于性能的要求预期也是在不断变高的。我用 iPhone 15 打开页面 2s，iPhone16 还是 2s，这不合理吧？所以实际上，性能问题长期应该都会是前端重点需要被解决的问题（所以 24 年有四项是和性能有关）。

不过我们也要相对清醒的认识到，性能问题实际上是很难被较好的解决的。首先是，通用性的解决方案基本都已经被挖掘了，其次，虽然业务体量的增加，性能天然就会被劣化。所以这块在技术深度上，会比开发体验的要求更高。君不见，react 已经开始卷 Compiler 来解决性能问题了。而 vue 的 alien-signals 也绝对不是简单的技术迭代就可以完成的。

最后是稳定性。虽然 24 年，稳定性方向上，相对没有什么大事发生，但是这并不代表稳定性不重要，只是它很难有比较好的结果产出。一方面是和稳定性方面技术产出的收益不好衡量，另外一方面也是由稳定性问题特点导致。所谓的稳定性，并不是我简单的全局 onerror，然后 catch 上报这么简单。

不应该被忘记的 AI

从 chatgpt 发布之后，ai 就注定是一个不能被忽视的方向。今年，ai 整体在各个方向上都有不少的进展。前端方向，ai coding、ai testing、ai devops 等等，都有不少团队在尝试。尤其是 ai coding，cursor 今年已经在这个方向上给出了一一个全新的解法。

但是这仅仅只是开始。2025 年，我相信会是各类 ai 工具飞速发展的一年，这点不仅仅会体现在 coding 方向上。就算单纯的 coding 方向，目前编辑器形式的结合，也仅仅只是开始，一整套工具链的逐步完善，依旧有很多东西可以做。

DeepSeek 的爆火，反映出大众对新技术的强烈渴望和积极拥抱。它以开源、免费的姿态，让更多人能够接触和使用 AI 技术，推动了人工智能的普及。在软件开发领域，低代码开发也在经历着类似的变革，它降低了开发门槛，让更多人能够参与到应用程序的开发中来。

在众多低代码开发平台中，JNPF 快速开发平台凭借其卓越的性能脱颖而出。JNPF 将企业管理系统中 80% 的功能通过组件化、可视化、拖拽化的方式来完成，这大大降低了企业应用开发成本，能够快速完成项目交付。

从技术架构来看，JNPF 采用.NET/JAVA 技术双引擎，并且提供全源码交付，方便企业进行二次开发。这意味着企业在使用 JNPF 平台时，既可以利用其可视化开发的便捷性，又能在需要深度定制时，通过源码进行灵活调整。而且，90% 的基础代码无需编写，进一步提高了开发效率。

感兴趣的可以做个尝试。官网：https://www.jnpfsoft.com

其他方向，就看各位大佬的发挥。

总结一下

开发体验，对于一线业务来讲应该是最容易切入的，但是结果不好衡量，最好能和你的领导目标达成一致，他也能理解你的业务痛点，否则你做的事情很难得到肯定。这点在一些好大喜功的厂子里面，表现尤其明显。不过对于一些三年左右的工作经验的研发来讲，还是推荐可以去做。一是本身工作年限低，领导对你的期望值也会低；其次，就算什么都没得到，对你个人技能的提升也是非常大的。

性能方向上，之前说了，对技术要求比较高，需要找准切入点。但是性能方向也有一个优势就是结果比较容易衡量。你需要的各类指标基本照着 web vitals 建议的来就行了，各种指标采集也给你写的明明白白。找准方向，就很容易把你的受益说清楚。最大的问题是，在各种技术已经被挖掘的很干净的今天，你要怎么继续深入。

稳定性方向，其实是一个比较背锅的方向，吃力不讨好。为什么呢，大家都知道稳定性很重要，但是有时候你业务出不出问题，真的不是你个人能决定的。并且很多稳定性的建设其实是等除了问题之后才会发现。没出问题之前，没人意识到稳定性的重要，出了问题，就是稳定性没做好。妥妥背锅侠。

所以三个方向推荐的顺序是，性能、开发体验和稳定性。具体选择，就看你个人了。

但是不管哪个方向，都有一个关键字，最好能围绕业务场景来。

最后是 ai，ai 这个赛道，目前是全新的，有很多东西可以做，但是大部分前端可能对 ai 都缺少深入的了解。

ai 方向整体是一个投入和产出都会比较大的赛道。