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

那以后工资也看起你呗

有一说一，合作过的很多 Java 都不会写前端代码，，，但对我们 PHP 来说，这就是顺手的事情。

我不知道你做不做 cli ，其实和 ui 没什么区别，form 。

包括 UI 框架的设计思想，我觉得也有很多后端可以学习的地方。

如果你指的是切图，css 之类设计，我觉得后端大可不必深入研究。


另外，我觉得做 cli 和 ui 挺香的，默默无闻的码农出彩的好机会。 默默无闻的 crud 是真的苦。

我以前是有一点这样的感觉，现在认为基本的前端知识对个人能力来说是必要的。

@nowheremanx

Javaboy 看不起前端总觉得蛮微妙的。前端的 async/await 和 MVVM 还有视图和状态之间的绑定不比那个破锁和 MVC 更先进吗。

这还只是前端的一个例子。

然后感觉一般来说前端也比 Javaboy 更容易接受例如函数式编程之类的新思想。一个例子就是 Java 社区极度排斥函数作为函数参数或返回值的技巧，美其名曰设计模式，但这在前端尤其是 React 社区简直就是基本功了。除此之外，TypeScript 玩起来也比 Java 更灵活更有表达力。没记错的话后端一堆拿着个 optional 甚至 var 吹上天的，现在又在吹 loom 了。

实在不知道哪来的自信心看不起别的领域。

@netabare 我也是 Javaboy ，Vue/React 都写过，没有看不起前端，反而觉得前端是最难的。无论是渲染器、编译器的设计我都觉得很精妙。

但是在日常使用中，就单说搭一个脚手架，前端那可太简单了。用用组件库就行了。但是对于我这种不是专业的前端，复杂的样式实现起来还是比较难的（也就是难就难在 css ）至于你说的函数式编程，Java 现在大把这种设计，你只要看几眼 spring security 的源码就能发现。

至于后端搭一个脚手架，要考虑技术栈比前端多太多了，微服务/单体? 安全认证怎么实现? 日志收集？链路追踪？拿开源的脚手架直接用真容易，但是自己想搭一个自己顺手的还是得花点时间的

只有会的人才有资格看不起。

你这鄙视链底层的 jvav 人谁关心你瞧得起瞧不起谁了.....怎么对自己的定位一点 B 数都没有
费城大街上的瘾君子说自己瞧不起办公室社畜你看有人搭理他不

会前端最大的好处就是你想整点什么出来给别人看的时候，别人不会只能看到硬邦邦的文档和接口，总的来说技多不压身。

想起某天晚上加班的一件小事。后端有个新来的初级 java 突然走到我身后，以一种奇怪的眼神看着我的代码，不过从话语和神态中似乎能看出来他有点轻视前端。过了一阵子遇到一个分页 bug ，公司项目之前约定的分页 index 是 1 开始的，不知道为什么那个后端设置成 0 开始了，我就这个问题和与我对接的后端交流，结果那个初级 java 突然幽幽的蹦出一句：“我们 java 就是从 0 开始的，还是得多学几门语言才好。”给哥们噎得一句话说不出来。

分人、看公司，小公司全干。
Java 确实不需要写前端。Java 要写业务，有的还搞中间件，kafka 队列，es 之类的就够搞的了。也没时间搞前端。我也会 vue react,移动 app 也会，并没有看不起的意思。

语言就是个工具，平常工作 C/C++，偶尔涉及 Java 和 C#，但体验上，我个人感觉 C#比 java 好一些 :)

@twofox
同 java 崽，我也是觉得前端真的是难学。不知道是不是先入为主学 c/java 的原因

@netabare
“一个例子就是 Java 社区极度排斥函数作为函数参数或返回值的技巧，美其名曰设计模式”

——怀疑你这说的把函数副作用和高阶函数弄混了吧！？ Java 社区反对的是函数入参引用类型直接修改和返回吧，这在前端也是反对的，不是纯函数，有副作用。但 Java 社区从来不反对高阶函数吧。

前端的 async/await 和 Java 、go 哪种完全不一样，Java 和 go 都是有栈协程。
async/await 实质上是状态机，现有语言就能实现。比如 kotlin 在 Java 语言基础上就加入了类似 async/await 协程功能。

这两种协程各有优劣，也没有什么不好 看不起的说法。

学技术是为了什么。

有些把领域的技能当成了自己的技能，其实只有学会了才是自己的。而且前端开发相关的知识 != 只是前端开发用的知识。
我为了实现各大视频网站的 url 代理而实现 http server ，用到的知识不只是前端开发的吧；
我为了一些功能写的 babel 插件需要学习一下 AST ，AST 不只是前端开发的吧；
我为了实现一些动画、特效、功能用到了数学知识，数学不只是前端开发的吧；
我为了防止反编译函数，用 go 实现并编译成 wasm ，go 不只是前端开发的吧；
我们的 E2E test 的代码是 c#写的，c#不只是前端开发的吧。

@netabare "前端的 async/await 和 MVVM 还有视图和状态之间的绑定不比那个破锁和 MVC 更先进" 这位更是重量级。你一定要说自己是前端 千万别说自己是程序员。

我就不一样，我是看不上只会一端的[狗头]

js/ts 得益于 babel/esbuild/swc/tsc 每年出的新语法/api 特性只要不涉及底层就能立刻当前项目用起来，比如最近刚出的 using 声明语法

但是 java 只能升级 jdk 才能用，比如 java10 出的 var 自动类型推导，java8 能用吗

但是这东西就是个喜好问题，没必要争个高低，喜欢用啥就用啥，我用 kotlin

@c3de3f21
胜任本职工作，适应时代变化，提高自身
@mmdsun
对，分工合作，投入产出效率才会更好

@hongfs 我是 PHP 但是我只会写一点点 css

@dode 还不够底层，需要在底层一点的意义

@netabare 见过好多 Javaboy 沉迷于设计模式, 有点魔怔的感觉, 别的语言的反而不怎么有.

当然, PHPboy 沉迷于 优雅, 怎么优雅的干啥事.

GOboy 没事就大道至简, (我主要写 go 说不好听点就是简陋, 要啥啥没有).

反而写 C++ 的比较安静, 可能是写的人少吧

@twofox 不是专业前端写一些复杂的样式对于我来说还是挺难的，完全没有思路

@hongfs #2 我一直很好奇, 为什么很多 phper 都会写前端.....

打工人视角：在争论哪个语言更好，哪个工具更好，哪个端更好
老板视角：一群臭 shabi

@netabare
async/await 是从 c#抄的，c#基本上就是 Java with 语法糖，Java 捣腾 future 就能达到同样的效果（就像 JavaScript 的 promise 一样

打到一半不小心点了发送
还有现在的 Java boy 基本上不用 stream ，lambda 就不会编程了，如果你说的 fp 只是这些，那基本上现在的 Java boy 都是疯狂的 fp 爱好者

如果你说的不只是这些，你大可在 jvm 的生态里施展你的拳脚，在 kotlin 和 scala 里实现你真正的 fp ，我有一个同事，不是我自己，非得把项目的逻辑用 scala fp 写，差点被其他同事打死

@bruce0
Cpper 成迷于各种语法；）

作为一个开发，应该对有代码的东西都感兴趣才对。技术没有高低贵贱之分。

@zoharSoul 可能是因为以前写的时候前后端不分离所以都会写吧, 比如 thinkphp 或者 jsp 这样子的, 写过这些框架的以前都是前后端一起撸的

@lisongeee 其实 JDK 8 可以用 var ，kotlin 那种扩展函数都支持，安装 lombok 插件有这个选项。

当年开发安卓 JDK 不支持 lambda ，Android studio 上还可以安装插件支持 lambda 。

@hongfs 可是 php 不就是天生和 html 一起的吗？这没有可比性吧？

@dode 我以为一切知识/技能都是为了让自己活的更好直接体现就是"会的多的选择就多机会更多",无所谓前后端或者项目管理，哪怕是业务需要了解其他行业的知识，也是多多益善。

建议多了解前端…… 比如尝试写一个 polyfill ？

没关系，俺们写 CPP 的写看不起 jawa (((不是
————————————————————
语言只是工具，技术栈才是知识

@gtx990 我说的 FP 当然不只是 lambda 和 linq ，我自己也没少用 Kotlin 或者 Scala 写过一些东西，但确实经常看到 Java 背景的人对 FP 表现出的敌意。虽然也不是所有人都这样，哪怕 Java 也有一些专门用于 FP 的框架。

@gtx990 Java 自带的 Future 及其难用以至于每个异步框架和反应式框架都有自己的 Future 。而且很多「函数式」课程或者文章提到 Future 还在说怎么 get ，直接失去了 Future 的使用意义。

@mmdsun 你说的这个是另外一件事情，直接修改返回确实是不好的操作。我说的是社区认为函数参数位置或者返回类型为 Optional<T>, Consumer<T>或者 Supplier<T>的写法是反模式这件事情。前段时间才刚遇到这么样的讨论，而且不是一两次了。作为习惯写函数式代码的人无法理解这种思维，说难听点，C 语言里传 void*也是常见的事情吧？

@twofox 会搭微服务，弄日志、认证、链路这些东西的，一般都会十几种不同的框架和语言，不会看不起前端吧。我也没说看不起 Java 或者相关的技术。JVM 平台实在是过于庞大精妙。但总有一些人非要对前端或者函数式有优越感。

emmm
npm cnpm pnpm
说实话前端挺难学的，老造轮子

@netabare 我还以为你要说啥呢。

async/await 和 MVVM 还有视图和状态之间的绑定。这些东西后端语言里早就有，当然不是 java ，java 的历史包袱很重，自然没有，你换个新一点的后端语言看看嘛。

而且，各位前端，你们为啥就喜欢盯着 js 语言来讲优越性呢，语言这个玩意，多玩几个就会发现高级语言是差不多的，谁也不比谁金贵。

要我说，前端的真正奥秘，在 CSS ，这个东西才是绝杀好不好，为啥就没有几个前端意识到 CSS 是多么绝妙的东西，作为一个后端，你要拿 js 怼我，我只会冷笑，你当我真不会写 js 吗？但是你要拿 CSS 怼我，那我肝败吓疯。

看到这么多人喜欢 kotlin 我就放心了

@netabare 楼上说得对，js 有的特性，Java 不一定有，但是一定会有别的高级实现。页面逻辑还是很简单的。但你要跟我说 CSS ，那真的是绝杀。

我也是个用过很多中间件、框架的人。但是对会 CSS 的，真佩服

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

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

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

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

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

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

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

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

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

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

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

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

@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 的语法。

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

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

@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 多

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

@yinzhili

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

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

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

@gtx990

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

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

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

ClassNotFoundException 又不是第一次见了

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

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

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

@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 ，没有你说的这个问题

@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 了。

@gtx990

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

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

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

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

@lisongeee 为什么前端开发者加班多，就是框架也好，生态圈也好，没有很好的做约束或者规范。隔三岔五造新轮子替代旧轮子，向下兼容的事情也没人管，然后再造新新轮子替代新轮子。你始终把锅甩给开发者，这一点我是不理解的。

@yinzhili

《你始终把锅甩给开发者，这一点我是不理解的。》难道不是吗？ js 本来就快速上手，就 node ./index.js 或 人人都有的浏览器控制台 就能跑起来的事情，特别是有 https://stackblitz.com/ 这种 WebContainer 之后能直接在浏览器运行 nodejs ，那些 ui 库都能在文档里附带运行 demo 了，使得 js 上手难度几乎为 0 ，而且发布代码就是 npm publish 一条命令的事情，试问 java 能做到这些吗？，虽然有的人可能连 esm/cjs/umd 的区别都不知道，更别说 ts/eslint/stylelint/rollup/esbuild/webpack ，但是这不妨碍 npm 是所有编程语言最繁荣的包平台。

《隔三岔五造新轮子替代旧轮子，向下兼容的事情也没人管》 那这种轮子你就不要用，你就当没看见，你就当 js 没有这种轮子，当一个生态的数量越来越多的时候，低质量和高质量的代码库也会越来越多，这种轮子就是典型的低质量轮子，难道 java 就没有这种轮子吗？只是 nodejs 由于上述原因轮子基数大这种轮子比较多

@lisongeee 别说了，npm 那种愚蠢的设计，你还在这里吹呢？ left-pad 那场大事故才过去多少年啊？要不要给你回顾下

@yinzhili

《别说了》我能说你这是急了吗？我说的是 js 上手成本几乎为 0 导致 npm 是所有编程语言最繁荣的包平台。

你要反驳我最好就拿出我刚刚说的技术的缺点

---

left-pad 属于用户可以直接删除 npm 上的库而无需邮件审核，这属于 npm 的人员审核缺陷

直到现在 npm 上的包仍然可以直接删除，比如哪天尤雨溪就可能脑子就抽了直接把 vue 删除了

我承认这是 npm 的审核缺陷，这确实很垃圾。我认为应该禁止删除一个包或者手动发送邮件审核说明删除原因。

但是这和我上面说 js 上手成本的没关系，你这属于反驳不了就转移话题，那么我同意你接下来的所有回复，你也别和我讨论了

人不行,看什么都不行

@lisongeee 你这是精通精神胜利法呀，虚假繁荣也是繁荣嘛

@yinzhili 是的，我同意你的说法