感觉不少前端框架 版本升级似乎很不喜欢搞兼容?

[bbbblue]

现在技术栈主要是 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 思维和苹果思维？

[wj2061]

维护成本太高了，来源项目一般人力资金有限，当然怎么自己爽怎么来。

[Belmode]

因为前端升级的“代价”和后端不可比，后端大多数情况是要求更稳定的，而前端迭代更快速。要求就不一样。

[huangzhiyia]

react 向后兼容算是拔尖的了，其余的就像你说的那样。甚至一个 1.1.x 的小版本更新都会引起问题。挺无语的

[Perry]

不要因为 remix 一个个例就下结论

[twig]

@Perry 这结论其实也没错

[StevenRCE0]

开发团队越稳定，用户（开发者/公司）基数越大，对兼容就会越上心。这就是 nextjs 很多人觉得是石也会赤的原因😂

[facebook47]

毕竟前端娱乐圈

[zhengfan2016]

大版本升级本来就不兼容啊，vue2 升级 vue3 不也不兼容？相比之下 nextjs 就改了个 approuter 算好的了，你总不能要求开发者做 approuter 相关的新功能的时候也给 pagerouter 做一份吧，2 倍的工作量，你给它们打钱吗？

[yb2313]

如果是这样的话，新项目新版本，老项目老版本。或者一开始选的时候就选升级注重向后兼容的包，react 的兼容就做得挺好

[kkwa56188]

追求短平快, 先上了再说,
兼容要做得好开发者难受, 兼容做不好用户难受. 两者相权取其轻, 死道友不死贫道

[darkengine]

前端确实需要花 30%的精力解决兼容或者说升级的问题，这还只是 web 的，app 端的苹果或者谷歌弃用个 API ，修改个权限，又是一堆工作量。

[gnosis23]

大版本有 breaking change 也算合理吧

[DefoliationM]

语义化版本就是这样，大版本更新本来就允许不兼容，比如 Python2 -> Python3 ，这不是 Windows 思维和苹果思维，你这种大概是半瓶水响叮当思维。

[crackidz]

没有什么长期思考，全是短视行为。觉得还行就上了，实际上越用越坑发现积重难返于是重新挖一个新坑

[Bijiabo]

有没有可能不是因为不喜欢。。。就好像我赚钱没马云多，可能不是因为我不喜欢

[cz5424]

Vue 的兼容性问题，导致了我们旧项目还一直在用 vue2

[pi1ot]

按我观察，几乎每个前端程序员都有一个自己的前端框架

[z00i]

React 本身在兼容性上，整个开源社区，不管前后，都算很优秀的了。

React Router 和 remix ，我感觉团队的问题。。React Router 从 1.0 开始，每次大版本升级，都改的面目全非，路由说白了，就是一个 路径到组建的映射吧，在项目的代码里真占不到多少比例，每次都那么有存在感。。remix 本来在社区的名声非常好，真不理解要强行并入 React Router 。

公司的项目没办法，我自己能掌握的，绝笔绕着这个团队走。。

[Ketteiron]

不止前端，整个 js/ts 生态都不喜欢向前/向后兼容。
整个 js 生态可以说是一塌糊涂，在破茅草屋上缝缝补补，缝不上了就推倒重来，光是 esm 就能让整个生态鸡飞狗跳，react 那边卡 8 年了。
https://github.com/facebook/react/issues/10021
还在活跃的 js 项目大多选择不断破坏性重构，这是没办法的事，要么停在尴尬的分岔路口，要么丢掉历史包袱重新选择正确的路，维持向后兼容很花时间精力，这点上我支持作者直接砍掉。

[lscho]

和前端圈、js 生态什么关系啊，和短视也不沾边啊。。。。思考的深一点这就是必然的。

前端本质是客户端，客户端就要跟随用户设备的发展、用户的审美、用途来变化的，

比如以前都是电脑，现在移动端居多，js 和 css 是不是要添加移动端的支持？以前都是小屏甚至非触摸屏，现在都是大屏触摸屏，是不是要添加对触摸事件的支持？以前分辨率低，现在分辨率高，浏览器的渲染机制就要发生变化。GPU 在升级，GPU 加速也要跟上吧？有新特性了不得加上？这样一来二去，还怎么向下兼容啊。

至于服务器端，因为硬件和操作系统本身就足够稳定，新特性加的很保守，本身就没有什么大的变化，兼容是好做的。

[Al0rid4l]

你说他不遵循 semver 语义那我陪着你一起骂, 结果看来看去一堆人属于是吐槽都吐不到点上

semver 兼容是情分, 不兼容是本分, 我以为这不难理解

@Ketteiron esm 鸡飞狗跳恰恰是因为兼容, 谁让 esm 来得晚呢, 要是社区都愿意直接抛弃 cjs 那反而没那么多事了

[stickchen]

前端重构相对简单的多，一个页面可能直接重构，后端根本不可能

[Gilfoyle26]

兼容？ IE 的亏吃的还不够吗

[abc8678]

前几天在 IT 之家看到这篇«开源媒体播放器 VLC 更新 3.0.22 RC1：正式支持 Win11 Arm ，修复 WinXP SP3 兼容性»哈哈

[bbbblue]

@z00i +1,已经不敢用了...

[bbbblue]

@lscho remix 和 nextjs 这类不只是单纯前端了 毕竟可以做全栈 不知道 nestjs 在更新这点是不是好很多

[bbbblue]

@Al0rid4l
不知道算不算个例 我之前用的 UI 库也是版本大更新 然后我发现主要的布局组件都嗝屁了... 然后一看官方把这些组件重写了，直接用了旧组件的名字，但是旧组件在新版里也全在，但是名字被改了都加了个 Legacy 。

因为是一个很大的项目了没精力全部重构我就加了 as 给他转了下... ...发现没啥问题 全都能用

所以感觉是可以兼容的，但是官方会为了鼓励大家用新版本，故意搞出不兼容。😂

[bbbblue]

@stickchen nextjs 和 remix 这类是全栈框架了，后端逻辑也有，但是如果有专门的后端开发会在他们的后端做层校验和转发。没有专门的后端开发，后端逻辑也全在里面了。

[bbbblue]

@StevenRCE0 感觉是 nextjs 毕竟有公司背书，有大量客户，所以还是比较节制了一点😂。但是如果之前项目是 14 ，升级到 15 ，15 改了 cache 的默认行为其实都够吃一壶了。

[bbbblue]

@zhengfan2016 是啊 所以我不是说 nextjs 稍微好一点点嘛

[bbbblue]

@DefoliationM
苹果 MacOs/iOS 会倾向于通过生态控制推动技术演进，牺牲部分兼容性以换取安全与体验；微软 windows 则优先保障向后兼容，允许旧应用长期运行，即使技术已过时。

MacOS/iOS 的倾向是向前推进，淘汰旧技术，新系统可能会直接删 api ，你要适配必须升级。
Windows 是尽最大努力保持向后兼容

windows 更包容，MacOS/iOS 更强势。

这么说思维没啥问题吧😂😂😂😂

[bbbblue]

@Al0rid4l 补充一下这个个例里更无语的，官方后面出的新组件文档里还在用这些 Legacy 组件做示例。。。。这些 Legacy 组件在官方文档里用的比新的组件还多。。😂😂😂

[LandCruiser]

前端技术不成熟啊，没办法，后端 java 这一套已经相对成熟了。还有一点原因就是前端是直接面对领导和客户的，需求不一致就导致技术也很难稳定一致。

[lightjiao]

互联网不管是前端还是后台，开源框架日新月异
而游戏开发领域，除了 GAS ，至今没有一个公认好用的开源玩法框架，资源管理框架倒是有好几个，但也不算百花齐放

[bojue]

需求提供就业机会，ToB 行业的兼容性处理可能占 30% - 50%，我们重构技术栈的已经好几次了，包括升级，换框架，换方案（类似采购其他公司的脚手架）。

几年没啥项目团队保住了几个人手，有项目了起码还能接。

[charlie21]

因为没人用，你却用了

[uni]

js 生态很多创业公司或者小团队在用，就是这样快速迭代的风气