现在技术栈主要是 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 思维和苹果思维?
1
wj2061 20 小时 29 分钟前 via iPhone
维护成本太高了,来源项目一般人力资金有限,当然怎么自己爽怎么来。
|
![]() |
2
Belmode 20 小时 27 分钟前
因为前端升级的“代价”和后端不可比,后端大多数情况是要求更稳定的,而前端迭代更快速。要求就不一样。
|
![]() |
3
huangzhiyia 20 小时 8 分钟前 via iPhone
react 向后兼容算是拔尖的了,其余的就像你说的那样。甚至一个 1.1.x 的小版本更新都会引起问题。挺无语的
|
![]() |
4
Perry 19 小时 31 分钟前 via iPhone
不要因为 remix 一个个例就下结论
|
![]() |
6
StevenRCE0 18 小时 49 分钟前
开发团队越稳定,用户(开发者/公司)基数越大,对兼容就会越上心。这就是 nextjs 很多人觉得是石也会赤的原因😂
|
7
facebook47 17 小时 40 分钟前 via Android
毕竟前端娱乐圈
|
8
zhengfan2016 14 小时 16 分钟前 via Android
大版本升级本来就不兼容啊,vue2 升级 vue3 不也不兼容?相比之下 nextjs 就改了个 approuter 算好的了,你总不能要求开发者做 approuter 相关的新功能的时候也给 pagerouter 做一份吧,2 倍的工作量,你给它们打钱吗?
|
![]() |
9
yb2313 14 小时 15 分钟前
如果是这样的话,新项目新版本,老项目老版本。或者一开始选的时候就选升级注重向后兼容的包,react 的兼容就做得挺好
|
10
kkwa56188 13 小时 43 分钟前
追求短平快, 先上了再说,
兼容要做得好开发者难受, 兼容做不好用户难受. 两者相权取其轻, 死道友不死贫道 |
![]() |
11
darkengine 13 小时 41 分钟前
前端确实需要花 30%的精力解决兼容或者说升级的问题,这还只是 web 的,app 端的苹果或者谷歌弃用个 API ,修改个权限,又是一堆工作量。
|
![]() |
12
gnosis23 13 小时 38 分钟前
大版本有 breaking change 也算合理吧
|
13
DefoliationM 12 小时 49 分钟前 via Android ![]() 语义化版本就是这样,大版本更新本来就允许不兼容,比如 Python2 -> Python3 ,这不是 Windows 思维和苹果思维,你这种大概是半瓶水响叮当思维。
|
14
crackidz 12 小时 47 分钟前 ![]() 没有什么长期思考,全是短视行为。觉得还行就上了,实际上越用越坑发现积重难返于是重新挖一个新坑
|
![]() |
15
Bijiabo 12 小时 40 分钟前
有没有可能不是因为不喜欢。。。就好像我赚钱没马云多,可能不是因为我不喜欢
|
![]() |
16
cz5424 12 小时 1 分钟前 via iPhone
Vue 的兼容性问题,导致了我们旧项目还一直在用 vue2
|
![]() |
17
pi1ot 11 小时 54 分钟前
按我观察,几乎每个前端程序员都有一个自己的前端框架
|
18
z00i 7 小时 9 分钟前 ![]() React 本身在兼容性上,整个开源社区,不管前后,都算很优秀的了。
React Router 和 remix ,我感觉团队的问题。。React Router 从 1.0 开始,每次大版本升级,都改的面目全非,路由说白了,就是一个 路径到组建的映射吧,在项目的代码里真占不到多少比例,每次都那么有存在感。。remix 本来在社区的名声非常好,真不理解要强行并入 React Router 。 公司的项目没办法,我自己能掌握的,绝笔绕着这个团队走。。 |
![]() |
19
Ketteiron 6 小时 41 分钟前 ![]() 不止前端,整个 js/ts 生态都不喜欢向前/向后兼容。
整个 js 生态可以说是一塌糊涂,在破茅草屋上缝缝补补,缝不上了就推倒重来,光是 esm 就能让整个生态鸡飞狗跳,react 那边卡 8 年了。 https://github.com/facebook/react/issues/10021 还在活跃的 js 项目大多选择不断破坏性重构,这是没办法的事,要么停在尴尬的分岔路口,要么丢掉历史包袱重新选择正确的路,维持向后兼容很花时间精力,这点上我支持作者直接砍掉。 |
20
lscho 5 小时 2 分钟前
和前端圈、js 生态什么关系啊,和短视也不沾边啊。。。。思考的深一点这就是必然的。
前端本质是客户端,客户端就要跟随用户设备的发展、用户的审美、用途来变化的, 比如以前都是电脑,现在移动端居多,js 和 css 是不是要添加移动端的支持?以前都是小屏甚至非触摸屏,现在都是大屏触摸屏,是不是要添加对触摸事件的支持?以前分辨率低,现在分辨率高,浏览器的渲染机制就要发生变化。GPU 在升级,GPU 加速也要跟上吧?有新特性了不得加上?这样一来二去,还怎么向下兼容啊。 至于服务器端,因为硬件和操作系统本身就足够稳定,新特性加的很保守,本身就没有什么大的变化,兼容是好做的。 |
![]() |
21
Al0rid4l 4 小时 44 分钟前
你说他不遵循 semver 语义那我陪着你一起骂, 结果看来看去一堆人属于是吐槽都吐不到点上
semver 兼容是情分, 不兼容是本分, 我以为这不难理解 @Ketteiron esm 鸡飞狗跳恰恰是因为兼容, 谁让 esm 来得晚呢, 要是社区都愿意直接抛弃 cjs 那反而没那么多事了 |
22
stickchen 4 小时 3 分钟前 via Android
前端重构相对简单的多,一个页面可能直接重构,后端根本不可能
|
![]() |
23
Gilfoyle26 3 小时 34 分钟前
|
24
abc8678 3 小时 3 分钟前 via Android
前几天在 IT 之家看到这篇«开源媒体播放器 VLC 更新 3.0.22 RC1:正式支持 Win11 Arm ,修复 WinXP SP3 兼容性»哈哈
|
![]() |
27
bbbblue OP @Al0rid4l
不知道算不算个例 我之前用的 UI 库也是版本大更新 然后我发现主要的布局组件都嗝屁了... 然后一看官方把这些组件重写了,直接用了旧组件的名字,但是旧组件在新版里也全在,但是名字被改了都加了个 Legacy 。 因为是一个很大的项目了没精力全部重构我就加了 as 给他转了下... ...发现没啥问题 全都能用 所以感觉是可以兼容的,但是官方会为了鼓励大家用新版本,故意搞出不兼容。😂 |
![]() |
28
bbbblue OP @stickchen nextjs 和 remix 这类是全栈框架了,后端逻辑也有,但是如果有专门的后端开发会在他们的后端做层校验和转发。没有专门的后端开发,后端逻辑也全在里面了。
|
![]() |
29
bbbblue OP @StevenRCE0 感觉是 nextjs 毕竟有公司背书,有大量客户,所以还是比较节制了一点😂。但是如果之前项目是 14 ,升级到 15 ,15 改了 cache 的默认行为其实都够吃一壶了。
|
![]() |
30
bbbblue OP @zhengfan2016 是啊 所以我不是说 nextjs 稍微好一点点嘛
|
![]() |
31
bbbblue OP @DefoliationM
苹果 MacOs/iOS 会倾向于通过生态控制推动技术演进,牺牲部分兼容性以换取安全与体验;微软 windows 则优先保障向后兼容,允许旧应用长期运行,即使技术已过时。 MacOS/iOS 的倾向是向前推进,淘汰旧技术,新系统可能会直接删 api ,你要适配必须升级。 Windows 是尽最大努力保持向后兼容 windows 更包容,MacOS/iOS 更强势。 这么说思维没啥问题吧😂😂😂😂 |
![]() |
32
bbbblue OP @Al0rid4l 补充一下这个个例里更无语的,官方后面出的新组件文档里还在用这些 Legacy 组件做示例。。。。这些 Legacy 组件在官方文档里用的比新的组件还多。。😂😂😂
|
33
LandCruiser 1 小时 52 分钟前
前端技术不成熟啊,没办法,后端 java 这一套已经相对成熟了。还有一点原因就是前端是直接面对领导和客户的,需求不一致就导致技术也很难稳定一致。
|
34
lightjiao 10 分钟前
互联网不管是前端还是后台,开源框架日新月异
而游戏开发领域,除了 GAS ,至今没有一个公认好用的开源玩法框架,资源管理框架倒是有好几个,但也不算百花齐放 |