本文探讨了前后端技术栈升级过程中遇到的不同体验。后端方面，将Java项目从11升级到21，Spring Boot从2升级到3，以及将线程池改为虚拟线程，过程相对顺利，兼容性问题不大。然而，前端库和框架的升级则显得尤为棘手。作者以Remix和Next.js为例，详细阐述了框架版本迭代带来的不兼容性，例如Remix从v2到v3的巨大变革，以及Next.js App Router对Page Router的“软弃用”策略。这种“不兼容”的升级模式，虽然推动了技术创新，但也给开发者带来了重构的压力，引发了对不同技术生态升级策略的思考。

⚙️ 后端升级相对平稳：Java 11升级至21，Spring Boot 2升级至3，以及线程池改为虚拟线程，整体兼容性良好，未遇到重大阻碍，升级过程被形容为“丝滑”。

🤯 前端升级的复杂性：前端库和框架的升级过程更为“蛋疼”，主要原因是新版本常引入新功能和特性，可能与现有依赖产生冲突，而过快的升级又可能导致与其他库的不兼容，需要开发者投入大量精力解决。

🎢 Remix的动荡与不确定性：Remix从v2到v3的演进经历了从基于React到完全不同的技术栈的转变，React Router的合并和模式的调整，以及v3的再次宣布开发，给开发者带来了巨大的困惑和不确定性，甚至被形容为“Remix无了”。

🚶 Next.js的“软弃用”策略：Next.js 13的App Router的出现，虽然提供了迁移方案，但其新特性全部基于App Router，实质上是对Page Router的“软弃用”，通过未来的发展前景迫使开发者进行重构，以享受框架的最新优势。

🤔 对“不兼容”升级模式的思考：作者对Remix和Next.js等主流框架为何倾向于“不搞兼容”，将创新置于首位，导致频繁的大改动表示不解，并将其与苹果的系统升级策略进行类比，探讨这种模式背后的逻辑。

现在技术栈主要是 js/ts + react/nextjs，java + sb。

前段时间把自己之前的项目，跑在 java11 和 sb2，升级到了 java21 和 sb3，除了 lombok 要跟着升级，再加上 javaEE 包改成 JakartaEE，其他都兼容了，没遇到太大问题。然后把几个 IO 任务的线程池改成 virtual thread, 测试没问题就发上去了，感觉比较丝滑。

---

但是前端这边的库/框架要升级感觉就特别蛋疼。。。。

首先为什么要升级呢，因为想用新功能和特性，而且还在不断写的项目偶尔要用一些新依赖，框架版本太老可能会和新依赖本身产生冲突，emmmm ，但是反过来，升太快可能其他库还没准备好...也会各种不兼容。

---

去年学了 remix，项目里要用。v2 版本，future flags 开了大部分。
然后看到官方说不会有 v3 版本了，v3 和 react router v7 合并...
我：？？？

后来真合并了，升级需要打开所有 v2 的 future flag ，然后用 codemod 可以完成部分工作，剩下一堆有问题的地方自己找 issue 解决了，大量的包名从 remix 改成了 rr。

rr 的 v7 开始说自己有多种模式，你可以用框架模式（其实就是remix), 库模式(之前 rr 的方式), 现在库模式好像又分成了两个。rr 算是不兼容老熟人了，只能说 remix 无了。

然后 remix 又突然宣布 remix v3 正在开发。
我：？？？
一看，这个 v3 是完全新的东西，甚至不基于 react 了，官方说是完全不一样的东西。
彻底无语了，完全不一样的东西你叫啥 v3 。

Next.js 的情况稍微好一点点，至少这个框架是持续性的，不像 Remix，有点绝后的感觉。
Next.js 13 的时候出了 App Router, 然后建议从 Page Router 迁移到 App Router，官方提供了并存和逐步迁移的方案。

但也基本是“软弃用”了，新特性全是 App Router 的。官方也通过文档不断告诉你，你正在使用的技术已经过时了，再不迁移，就享受不到框架发展的红利，逐渐会被边缘化。这东西本质上也是一种“不搞兼容”的策略，用未来的发展前景逼着你进行重构。

这两个库算是用的人不少了吧，就感觉很神奇，为什么就不喜欢搞兼容呢，感觉好像创新大于一切似的，动不动就搞个大改动😂，有点像苹果，我升级系统你不跟是吧，那你 app 别跑了呗😂。

emmm...可能这就是 windows 思维和苹果思维？