5
片面感觉前端（有一部分）是在提高入行门槛
source link: https://www.v2ex.com/t/848148
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
感觉前端（有一部分的行为）是在提高入行门槛，比如复杂的设计，明明简单的方案能解决的问题，一定要设计一个复杂的系统，遇到了问题后再用一个新的复杂的设计来解决新的问题。 终极目的不是为了降低开发成本，而是“提高（自己的）开发体验”，（而有些前端开发者担心技术本体不够简单，任何人都能参与）最终达到了提高技术门槛，实现技术垄断。
观点有些片面，不知大家怎么看
第 1 条附言 · 1 小时 22 分钟前
感谢大家的回复，提到了很多有用的观点与例子。
反思一下，个人提出这种观点的本身还是在吐槽系统的过度设计吧，例如刚学习 react 的时候，了解到了 redux 状态管理，本身概念引入就不少，结果需要引入另外的库来解决 redux 副作用。在当时学习的时候就埋下了吐槽的种子。
再比如：后端开发要晋升，除了设计系统外，有时候解决一个复杂的问题就能够拿出来说一下，而前端几乎不可能用”我圆满的实现了这个业务界面“来分享，造轮子几乎成了唯一出路。
业务需求在变复杂，前端工程化本身是好的，可能只是觉得现有的设计离“刚刚好能满足需求的”设计程度有些过了？
反思一下，个人提出这种观点的本身还是在吐槽系统的过度设计吧，例如刚学习 react 的时候，了解到了 redux 状态管理，本身概念引入就不少，结果需要引入另外的库来解决 redux 副作用。在当时学习的时候就埋下了吐槽的种子。
再比如：后端开发要晋升，除了设计系统外，有时候解决一个复杂的问题就能够拿出来说一下，而前端几乎不可能用”我圆满的实现了这个业务界面“来分享，造轮子几乎成了唯一出路。
业务需求在变复杂，前端工程化本身是好的，可能只是觉得现有的设计离“刚刚好能满足需求的”设计程度有些过了？
57 条回复 • 2022-04-20 18:29:28 +08:00
kop1989smurf 3 小时 35 分钟前
其中有部分原因是“康威定律”，既“设计系统的架构受制于产生这些设计的组织的沟通结构”。
开发公司急需让前端的工作和业务剥离开来，缩减前端一线开发的权限和自由度，从而降低前端开发的不可替代性和通用性。增加前端代码的可维护性和标准化。
“前端工程化”正好命中了这点。
至于说前端工程化，和软件公司架构需求谁是鸡谁是蛋，那就不好说了。
开发公司急需让前端的工作和业务剥离开来，缩减前端一线开发的权限和自由度，从而降低前端开发的不可替代性和通用性。增加前端代码的可维护性和标准化。
“前端工程化”正好命中了这点。
至于说前端工程化，和软件公司架构需求谁是鸡谁是蛋，那就不好说了。
ericgui 3 小时 22 分钟前 
2
以前你要适配 IE6 ，现在前端不需要你手动适配各个浏览器了吧？
所以，你感觉是错的，当然是降低了门槛。
但前端本身也在进化，深度和广度都有发展，你想着就靠着学会 jquery 几个 API 就吃饭的年代肯定过去了。
但实际上前端框架也变得非常非常抽象了，把底层都抽象为几个简单的 api ，你来用用了就好了，但对你的期待更高了，现在对前端的要求已经不仅仅是交互了，而是更复杂的工程了，把大量的功能挪到前端了。所以前端当然更复杂了。但这个复杂， 是需求本身变复杂了，前端本身肯定是降低了门槛，提供了更多的工作机会。
总之，你感觉错了。
所以，你感觉是错的，当然是降低了门槛。
但前端本身也在进化，深度和广度都有发展，你想着就靠着学会 jquery 几个 API 就吃饭的年代肯定过去了。
但实际上前端框架也变得非常非常抽象了，把底层都抽象为几个简单的 api ，你来用用了就好了，但对你的期待更高了，现在对前端的要求已经不仅仅是交互了，而是更复杂的工程了，把大量的功能挪到前端了。所以前端当然更复杂了。但这个复杂， 是需求本身变复杂了，前端本身肯定是降低了门槛，提供了更多的工作机会。
总之，你感觉错了。
anguiao 3 小时 19 分钟前
由于各种五花八门的工具链，入门确实变得复杂了。但是实际开发起来，体验比以前应该是好太多了。
CodingNaux 3 小时 13 分钟前 8
前端容易把事情搞复杂
今天 npm, 明天 yarn, 后天 pnpm （ 我选 npm)
今天 rollup, 明天 webpack,后天 vite. (我选 webpack 或者小几率 rollup)
今天 angular, 明天 vue ，后天 react (我选 react ）
今天 moment,明天 dayjs ，后天 data-fns. (我选 dayjs)
今天 redux, 明天 mobx,后天 hook+context. (一般情况我选 hook+context ）
今天 express ，明天 koa,后滩 nestjs (纯前端搞毛 node 后端？我选 nextjs)
今天 npm, 明天 yarn, 后天 pnpm （ 我选 npm)
今天 rollup, 明天 webpack,后天 vite. (我选 webpack 或者小几率 rollup)
今天 angular, 明天 vue ，后天 react (我选 react ）
今天 moment,明天 dayjs ，后天 data-fns. (我选 dayjs)
今天 redux, 明天 mobx,后天 hook+context. (一般情况我选 hook+context ）
今天 express ，明天 koa,后滩 nestjs (纯前端搞毛 node 后端？我选 nextjs)
jjwjiang 3 小时 2 分钟前
我感觉说这话的是根本没从上古时代开始干过复杂前端项目的
在 js 和 jq 时代我不止一次造过乱七八糟但是功能和现代前端框架类似的轮子
你觉得现在的前端太复杂了，是因为复杂度本来就摆在那里
在 js 和 jq 时代我不止一次造过乱七八糟但是功能和现代前端框架类似的轮子
你觉得现在的前端太复杂了，是因为复杂度本来就摆在那里
shintendo 2 小时 58 分钟前 13
古代造房子都是手撸，现代造房子却要起重机，是不是建筑工人提高行业门槛的阴谋
你只看到手撸和起重机的差别，没看到房子和房子的差别，当代刻舟求剑了
码农这种费拉不堪的群体，会为了提高行业整体门槛而牺牲自己，故意用难用的工具干活，说出来你信吗？有这一半的凝聚力也不至于 996 了
你只看到手撸和起重机的差别，没看到房子和房子的差别，当代刻舟求剑了
码农这种费拉不堪的群体，会为了提高行业整体门槛而牺牲自己，故意用难用的工具干活，说出来你信吗？有这一半的凝聚力也不至于 996 了
catinsides 2 小时 48 分钟前
私以为，是因为有了某个复杂的问题，才产生了对应的解决方案（简单的方案解决不了，或者解决起来麻烦）。
或者是以前的解决方案存在一些问题，然后产生了新的解决方案（以上面说到的 moment 和 dayjs 为例）。
新人不了解这些历史和原因，所以从外面看是越来越复杂。
或者是以前的解决方案存在一些问题，然后产生了新的解决方案（以上面说到的 moment 和 dayjs 为例）。
新人不了解这些历史和原因，所以从外面看是越来越复杂。
zooeymango 2 小时 45 分钟前
还行吧, 应该说以前简单是因为只能干那么多内容, 再往上加复杂功能就无法维护了, 现在有模块化有各种框架以前做不了的东西现在能做了, 需求其实是无止境的, 难度的提升就是就是前端的能力在提升
shintendo 2 小时 41 分钟前 2
奇怪老有人意淫前端曾经有一个“简单，纯净，jq 一把梭，不用关心各种乱七八糟”的田园牧歌时代，也不知道哪里来的印象，看看有这个印象的人多大比例是真写前端的
charlie21 2 小时 24 分钟前
客户端。是客户端，angular 没有对标 vue react ，angular 在对标 wpf javafx 。你再说 angular 是前端框架 angular 要生气啦
ikas 2 小时 23 分钟前
万变不离其宗
一路走来从 flash,flex,js,jquery,extjs,mvc js,wpf,xaml,angularjs,vue..
ui 端真的有什么变化么?难度在哪里?
一路走来从 flash,flex,js,jquery,extjs,mvc js,wpf,xaml,angularjs,vue..
ui 端真的有什么变化么?难度在哪里?
shyrock 2 小时 22 分钟前
作为一个前端外行，
我感觉前端框架的问题是缺乏有统治力的框架，导致前端的框架总是后浪推前浪，前浪死在沙滩上。
新框架有全新的模型完全不兼容旧框架（毕竟是竞争对手，肯定不兼容是最优选择）。
新框架可能在功能和性能上有 50%的提升，然而学习新框架放弃旧框架的学习成本和项目迁移成本是 100%。
我感觉前端框架的问题是缺乏有统治力的框架，导致前端的框架总是后浪推前浪，前浪死在沙滩上。
新框架有全新的模型完全不兼容旧框架（毕竟是竞争对手，肯定不兼容是最优选择）。
新框架可能在功能和性能上有 50%的提升，然而学习新框架放弃旧框架的学习成本和项目迁移成本是 100%。
dcsuibian 2 小时 20 分钟前 1
总体来说，我感觉比起 jQuery 时代，现在的前端开发方式真的舒服不少。如果要做页面，那肯定舒服很多。
但相对而言工具链的配置就整的很复杂。TypeScript 、Webpack 、Babel.js 、Vite 等等。这种东西很复杂，而且弄好了也没有什么成就感。我个人觉得原因主要有：
1 、web 技术是逐渐发展到现在这个样子的，而 js 、css 在最初设计时没有考虑太多（尤其是 js ，语言错误多，而且缺少基本的模块化语法和作用域等功能）。js 光模块化语法就好几种，搞得异常复杂。
2 、兼容性。在前端领域，不考虑兼容性基本就是一个死。但是考虑兼容性，又会变得异常复杂。以前是对浏览器的兼容性，而现在是工具链的兼容。你发布一个包，可能要考虑用户是在什么环境下用的，nodejs 还是浏览器，webpack 、rollup 甚至还要考虑具体的版本。整得异常复杂。
3 、前端生态圈缺少一个像 Spring 这样的整合者。导致大家疯狂地自己造轮子。这点 Vue 还好，有自己的全家桶。React 那边就乱多了，各种搭配层出不穷。
但相对而言工具链的配置就整的很复杂。TypeScript 、Webpack 、Babel.js 、Vite 等等。这种东西很复杂，而且弄好了也没有什么成就感。我个人觉得原因主要有：
1 、web 技术是逐渐发展到现在这个样子的，而 js 、css 在最初设计时没有考虑太多（尤其是 js ，语言错误多，而且缺少基本的模块化语法和作用域等功能）。js 光模块化语法就好几种，搞得异常复杂。
2 、兼容性。在前端领域，不考虑兼容性基本就是一个死。但是考虑兼容性，又会变得异常复杂。以前是对浏览器的兼容性，而现在是工具链的兼容。你发布一个包，可能要考虑用户是在什么环境下用的，nodejs 还是浏览器，webpack 、rollup 甚至还要考虑具体的版本。整得异常复杂。
3 、前端生态圈缺少一个像 Spring 这样的整合者。导致大家疯狂地自己造轮子。这点 Vue 还好，有自己的全家桶。React 那边就乱多了，各种搭配层出不穷。
yzbythesea 2 小时 10 分钟前
我可以就属于这样的老人吧。刚工作只有 jquery ，写的很得心应手。现在偶尔接触下前端，react redux 已经看得我感觉被时代淘汰了 😓 更别提什么 yarn ，webpack 这些了。
主要前端知识貌似没有连续性，比如后端，10 年前做 rpc ，和现在火起来的 grpc ，都差不多。前端不知道，可能语法糖太多，基本不怎么通用。
主要前端知识貌似没有连续性，比如后端，10 年前做 rpc ，和现在火起来的 grpc ，都差不多。前端不知道，可能语法糖太多，基本不怎么通用。
fstar 2 小时 8 分钟前 1
工程化嘛。
前端在过去很简单，JS 被发明的作用就是给网站加点小交互。
发展到现在，甚至直接就把桌面端的那一套搬到网页上了，比如谷歌地图、谷歌文档，这是非常复杂的大型项目。
如果你还像以前一样，直接写 html 、css 、js ，一堆人一起开发，还要考虑兼容问题，命名冲突问题，开发体验很差的，bug 也会多。
怎么办？用工具（比如打包工具、CSS 预编一起）、用框架（ JQ 到 React 和 Vue ）、用第三方库（ npm ）。
当然前端目前因为快速发展的原因，各种方案和轮子层出不穷，一些轮子可能解决了一些问题，但又带出了其他问题。于是修修补补，出现了新的方案。或者有人觉得不好，又重新定义了一个方案，又一个轮子出现了。
确实轮子太多了，但也要确实地明白，解决问题的方案并没有一个固定的答案，每个方案都各有利弊，要选择合适自己的才行。
我们再回到 “提高开发体验” 这件事情，提高开发体验有什么用？可以让产品有更好地交付、更少的 bug 。
我希望自己脑子里想一个东西，然后计算机自动帮我写好了，而且没有 bug 。但不太可能。
复杂是为了抽象，为了将日渐繁杂的业务抽丝剥茧，提高代码的可读性和可维护性。
前端在过去很简单，JS 被发明的作用就是给网站加点小交互。
发展到现在，甚至直接就把桌面端的那一套搬到网页上了，比如谷歌地图、谷歌文档，这是非常复杂的大型项目。
如果你还像以前一样，直接写 html 、css 、js ，一堆人一起开发，还要考虑兼容问题，命名冲突问题，开发体验很差的，bug 也会多。
怎么办？用工具（比如打包工具、CSS 预编一起）、用框架（ JQ 到 React 和 Vue ）、用第三方库（ npm ）。
当然前端目前因为快速发展的原因，各种方案和轮子层出不穷，一些轮子可能解决了一些问题，但又带出了其他问题。于是修修补补，出现了新的方案。或者有人觉得不好，又重新定义了一个方案，又一个轮子出现了。
确实轮子太多了，但也要确实地明白，解决问题的方案并没有一个固定的答案，每个方案都各有利弊，要选择合适自己的才行。
我们再回到 “提高开发体验” 这件事情，提高开发体验有什么用？可以让产品有更好地交付、更少的 bug 。
我希望自己脑子里想一个东西，然后计算机自动帮我写好了，而且没有 bug 。但不太可能。
复杂是为了抽象，为了将日渐繁杂的业务抽丝剥茧，提高代码的可读性和可维护性。
wu67 2 小时 5 分钟前
前端目前最大的毛病就是就是过度设计、过度造轮子. 总是看到其他语言生态的东西就想抄过来, 你一面向过程的语言, 抄个设计思路就算了, 什么玩意都往里抄, 整得各种四不像...
chinajik 1 小时 51 分钟前
我觉得是的， 尤其是 react vuejs angularjs 这三大框架谁能说得出应用场景有何不同，但又不尽相同。
轮子过量设计了，以前我敢说理解 html （结构） css （表现） js （行为） 就能上手的简单工作技能，现在都不知道怎么教新手理解额外的特性
轮子过量设计了，以前我敢说理解 html （结构） css （表现） js （行为） 就能上手的简单工作技能，现在都不知道怎么教新手理解额外的特性
kett 1 小时 36 分钟前
我觉得实际干活的时候大部分人都是专心码自己的功能，不会去整体的考虑系统的复杂性的，提高系统的复杂性只会提高一部分负责统筹全局的人的门槛，而对于其它大部分人来说门槛依然是码功能需要掌握的基础知识和框架知识。
xylophone21 1 小时 4 分钟前
》后端开发要晋升，除了设计系统外，有时候解决一个复杂的问题就能够拿出来说一下
其实差不多，后端可以用”我圆满的实现了这个业务==界面==“来晋升吗？那不是叫 CRUD Boy
其实差不多，后端可以用”我圆满的实现了这个业务==界面==“来晋升吗？那不是叫 CRUD Boy
ChefIsAwesome 38 分钟前 via Android 1
技术圈有这种给项目加标签的行为。xx 项目用上了 xx 框架，xx 架构，xx 语言。最终产品可能是个没啥功能的博客之类的。
新手喜欢这样，显得自己潮。老手也喜欢这样，增加绩效。
举例讲，闲鱼那软件做的啥玩意，可技术面上可是各种创新，各种标签都能打上。
想学一个新技术，首先是明白作者的初衷是什么，要解决什么问题。为什么旧的东西不可以，要造个轮子。
以楼主你的例子来讲，mvc 框架之前就有，为什么要造 react ？ redux 不是 react 捆绑的东西，而是 react 出来有一阵子之后才出现的，它出现的背景是什么，为什么要做 redux 这个东西？
知道初衷就能知道使用场景，用起来自然就能游刃有余。
新手喜欢这样，显得自己潮。老手也喜欢这样，增加绩效。
举例讲，闲鱼那软件做的啥玩意，可技术面上可是各种创新，各种标签都能打上。
想学一个新技术，首先是明白作者的初衷是什么，要解决什么问题。为什么旧的东西不可以，要造个轮子。
以楼主你的例子来讲，mvc 框架之前就有，为什么要造 react ？ redux 不是 react 捆绑的东西，而是 react 出来有一阵子之后才出现的，它出现的背景是什么，为什么要做 redux 这个东西？
知道初衷就能知道使用场景，用起来自然就能游刃有余。
Sivan 12 分钟前
LZ 观察很到位，但现实需要卷起来。否则可能用不了几年这个行业就消失了。
如果工种 A 一直保持小学一年级的难度，那不继续学习自愿一直留级挣这份钱的人会越来越多。两年后，工种 B 和 C 都上到三年级了，课余时间都把你工种 A 辅修完了，以后研究课题时人家还带你玩吗？而如果需要选一个大队委，你觉得陪着一堆一年级上课的 A 班精英能竞争过 B 和 C 班的人么？
如果工种 A 一直保持小学一年级的难度，那不继续学习自愿一直留级挣这份钱的人会越来越多。两年后，工种 B 和 C 都上到三年级了，课余时间都把你工种 A 辅修完了，以后研究课题时人家还带你玩吗？而如果需要选一个大队委，你觉得陪着一堆一年级上课的 A 班精英能竞争过 B 和 C 班的人么？
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK