怎么面对这个心态，低级阶段的 Java 开发工程师看不上前端开发相关的知识

[dode]

个人发展和行为上的困惑

[yinzhili]

@lisongeee 太灵活，有时候不见得是优点。例如：Java6 时代的老项目代码，拿到 Java11 环境下通常可以正常编译打包，这已经是跨越 4 个大版本了。但是有些前端项目的话，Node 14 能跑，换到 Node 16 就编译报错。

[feiqiu]

我们一个团队只有一个前端 负责 3 个小项目 剩下的是前端外包 有时候我就想转前端 这样绩效好看点

[lisongeee]

@yinzhili 《太灵活，有时候不见得是优点》

那是他们不上 ts/eslint/git hooks ，用动态语言又不严格规范怪谁

还有你这个例子举的不正确，我也可以举反例

例如：vite 在 node14 能跑，在 node20 仍然能跑，这已经是跨越 6 个大版本了，还可以工作

但是有些 java 项目的话 Java6 时代的老项目代码，拿到 Java11 环境下就编译报错。

jdk 要真这么稳定，java21 都快出来了，咋一堆人还在用 java8

我能在 node14 上用上 node20 的语法，你能在 java8 上用上 java21 的语法吗

[gunnarli]

都是为资本家打工的工具人，还搞这些人民内部矛盾就很没意思了

[liberty1900]

前端 build pipeline 的好多工具都是用 Rust 写的，从一开始就没考虑过用 Java ，至少 Go 还能参与这个游戏

[AyaseEri]

看不上不要紧，只要别觉得自己会前端就行。
就怕那种写过 jQuery 的 Java 后端，觉得自己懂前端，能领导前端，指导 MVVM 时代的前端开发。上来就是反驳别人 React 函数式组件实例化（对，用了实例化一词）后返回的是实例而不是视图。指导别人抽组件就是继承继承继承，前端为了满足这点性癖换成类组件去写，又问人家为什么要用类组件。

[gtx990]

@lisongeee

node 的兼容性和依赖管理放在整个编程届都是倒数的，我司的项目，前端，ci/cd ，infra 都是 TypeScript 写的，node 的 lts 只有两年，意味着我每年 4 月要升级十几个 pipeline ，node10 ，node12 ，node14 ，node16 几乎都有几个库不兼容，每年这个时候都得找各种 workaround 。顺路也要喷一下 npm 连 dependency 的 dependency 的版本号都指定不了。

另一方面，大家停在 Java8 和 Java11 的原因是，新 feature ，新语法只是 nice to have ，Java8 足够完成你所有的编程任务，Java 从来不会在兼容性，依赖管理这块给你带来任何麻烦。喜欢语法糖就上 kotlin ，几乎约等于在 jdk8 上运行 java20 的语法。

[qping]

@mmdsun #31 var 真的好么，我在写 C#，写起来是简单了，看别人的代码一眼过去都不知道函数返回的是什么

[vevlins]

看不上就看不上，也没人要求你看得上。学个自以为高级的知识就有莫名其妙的优越感，学个知识整的跟奢侈品牌的柜姐一样，真掉价。正大集团养猪的，资产几千亿，作为程序员肯定也看不起养猪的吧？

[lisongeee]

@gtx990

你说的前半句有一定道理，但是 《 npm 连 dependency 的 dependency 的版本号都指定不了。》你是不是没看文档 https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides

Java 从来不会在兼容性，依赖管理这块给你带来任何麻烦，这点不敢苟同，我写 Android 的时候老是遇到一堆依赖问题

另外 npm/pnpm 默认多版本共存，而 java 的 maven/gradle 不支持多版本共存，起码我自己遇到的 java/gradle 依赖问题比 nodejs/pnpm 多

[yinzhili]

@lisongeee 你说的那种 Java11 编译报错，大部分是依赖包问题而不是项目代码本身导致的，比如用了 com.sun 的依赖包或者 JavaEE 的相关包，更改一下替代包就可以解决。但是前端项目从 14 到 16 ，就不是这么简单了，哪次不是要大改一堆东西才能搞定？

[lisongeee]

@yinzhili

别，起码我做过的项目升级起来很简单，大多数都是 volta pin node@latest 一下就完了

因为我本身对使用的 npm package 有严格的要求，这东西看人，你觉得就是你对

[gtx990]

@lisongeee 你说的这个东西 release 于 2021 年 12 月，在这个之前，需要用很 hack 的方式。在此之上更糟糕的是，我司会强制把 dependency 变成 nested 的状态，理由和你说的类似。但实际上有很多包必须全工程版本一致，我举一个例子，比如存 mapping 关系，否则会引入业务逻辑上的冲突。Java 对于某个库只允许一个版本在我看来是优点。

[lisongeee]

@gtx990

《 Java 对于某个库只允许一个版本在我看来是优点。》

npm/pnpm 也可以通过提升铺平全部依赖来 放弃多版本共存，另外 nodejs 的包的依赖是使用范围匹配，只要两个依赖的子依赖范围存在相同，这个子依赖就只存在一份，最理想情况下，每个包都只存在一份，存在多份只是因为它们声明的依赖范围不同而已，难道这时候要违背这个范围规范强迫它们去使用同一个版本吗？

也就是 pnpm 支持多版本/单版本，而 java 只能单版本

ClassNotFoundException 又不是第一次见了

[NickHopps]

建议听听陈皓大佬的《左耳听风》，还在纠结这个问题只能说确实是低级阶段。

[yinzhili]

@lisongeee 你觉得简单，应该是因为从一开始你就严格把控了这个项目，当然会简单，这很合理。有些前端项目是半路接手的，就不是那么规范了。

[yinzhili]

@lisongeee 我举个例子：有些前端项目特别喜欢用 node-sass ，而且用得很广泛，但只要 node 版本从 14 升到 16 ，对不起，这东西就表示不兼容了。相应的，Java 环境也升级 2 个版本的话，Java6 的项目拿到 Java8 去跑，绝大多数情况下是正常的。

[lisongeee]

@yinzhili

这是库的问题，node-sass 是一个 c++ 项目，它编译的库本来就是和 nodejs 版本的 modules 数量相关的

也就是每个 node-sass 版本都需要面向 node14/16/xx 单独编译才能直接使用

一开始使用它就得了解它的规范，无脑升级借此吐槽兼容性不可取

另外 https://github.com/sass/node-sass/releases node-sass 不是还在支持 node16/18/19/20 吗

另外社区已经转向 dart-sass ，它由 dart 编译到 纯 js ，没有你说的这个问题

[gtx990]

@lisongeee 首先 dedupe 是有限制的，如果两个库非得一个写 1.2.*,一个写 1.3.*，你最后还是会有两个版本。

然后保底方案，使用 package-lock.json 里的版本的话，所有 dependency 都会是 nested 。有些库就是不能版本冲突，再举一个浅显的例子，不同的库不应该引用不同版本的 react 对吧，应该把这种东西放到 peerDependencies 这种基础知识大家都知道，但是我遇到过很多别的库，就要把公司的 common 包放在 dependencie 里，你能咋办。

再加上之前说的 npm ，2021 年 12 月才搞出来 override 这么基础的功能。让本来已经很糟糕的 node 体验变得更糟糕了。如果你说 yarn ，我的火气还没这么大。

范式匹配也是最大的败笔之一，很多项目，总有人喜欢用 latest ，当你引用别的组写的这样的包的时候，latest 的 dependency 很多时候都不太 work ，比如你的 dependency 的 dependency 突然飙了一句 node18 的语法，打包的时候没有打好，导致你 node14 的项目 fail 了，老板让你这周内 fix ，当你咬咬牙升级 18 的时候，更多的库 fail 了，true story 。

我在写 Java 的时候从来没遇到过这些 bullshit ，你说的 class not found 只会出现在刚引进新包的时候。你永远不会像 node 一样，昨天用着好好的，今天就不能 build 了。

[lisongeee]

@gtx990

你说的很有道理，而且你举的例子全是人为操作不规范导致的错误，怎么说呢，我不好评价

就比如《 dependency 突然飙了一句 node18 的语法，但是没有语法降级》，这明显属于不规范的破坏性更改

你吐槽的点更多来源于 人为操作的不规范，js 比 java 支持了更多功能的同时也拉低了代码质量的下限

如果想提高整体代码质量，确实要用 java 这类静态语言