这是一个创建于 605 天前的主题，其中的信息可能已经有所发展或是发生改变。
过去十年移动互联网大发展，产生了巨量前、后端需求，推动前、后端技术走工程化的路线。
工程化是对的，但是前端目前的工程化方向可能有点偏了，以致于频繁调整路线——最终表现就是前端工程师们觉得自己需要不停的学习新知识。
实际上，前端“以频繁学习新知识为荣”是一种“大聪明”的表现，就好比一个学渣总是写错作业，却以重写作业为荣。
市场繁荣期已经过去，近期频繁出现前端求职困难——当然后端也好不到哪里去。
未来，剩下的前端们会因为人力有限，开始将前端工程化过程中“繁杂无效”的部分剔除，回归到“技术服务项目”路线上来，而不是继续以前那种“技术服务工程化”的路线。
嗯，我是前端，也是后端，纯纯外包仔。
顺便推荐一下我的项目： https://github.com/dongnanyanhai/vue-web-loader-2
这个项目本质上算是对前端工程化的一种吸收和反对，前端生态非常丰富，是可以好好利用的，但前端开发的流程还在改进中，需要暂时避开。
最后强调一点，前端帅哥很多，非常多！
 |
1
ma836323493 2023-03-30 11:31:00 +08:00  3
大道至简
|
 |
2
HiCode OP 另外，工程化在提高开发效率的同时，也弱化了人在项目中的作用。
一个项目如果高度工程化，那么程序员就没办法像医生、律师那样越老越值钱，而是会像汽车厂的技术工，被年轻人和机器人随意代替。 |
 |
3
kop1989smurf 2023-03-30 11:32:58 +08:00 2
软件架构 overkill 应该是近 10 年来一直存在的问题。
一是很多软件公司承受不了业务扩展后的重构，不如就那业界最优解一把梭。又稳定，成功率又高，参考资料还多。 二是随着硬件性能的提高，复杂架构的弊端逐渐变得不明显。同时快速迭代的互联网公司兴起，导致对于员工的可替代性、标准化要求非常高。所以复杂架构就越来越变成必然。 btw：楼主这个项目的思路挺有意思。有点行为艺术的意味在里面。 |
 |
4
iyiluo 2023-03-30 11:36:10 +08:00
不知道现在前端还用不用 npm ，几年前去维护一个前端，那个 npm 下载的依赖真的多
|
 |
5
lanlanye 2023-03-30 11:38:14 +08:00 via iPhone
工程化的目的是降低参与者自己的认知负载，我觉得这是必然要做的，至于用什么方式做，做到什么程度……那还是要人根据实际情况来决定的，也许没有标准答案。
|
 |
6
lvsijun 2023-03-30 11:39:12 +08:00
最后一句表示苟同
|
 |
7
jay435990054 2023-03-30 11:40:45 +08:00
@HiCode 雀食 主要还是人在内卷
|
 |
8
weixind 2023-03-30 11:43:59 +08:00 1
可以了解下前端工程化的各部分是为了解决哪些问题。只能说现在前端工程化还有很长的路要走。哪有过度工程化。拿最基础的包管理举个例子，npm 、yarn 、pnpm 几年时间各自更新的多个大版本，是因为一直迭代出新的更好的解决方案。而不是“大聪明”的表现。
新手学习过程中可以 script 标签引用 min.js 。可是生产环境的性能优化和兼容性怎么处理呢。 |
|
9
weixind 2023-03-30 11:46:26 +08:00
@iyiluo 包管理器 npm 自身迭代了几个大版本，后续也有 yarn 、pnpm 新的解决方案。就是因为之前的 npm 太垃圾了。前端生态看上去更热闹一方面是人多，一方面是很多解决方案并没有迭代到最优解。
|
 |
10
uni 2023-03-30 12:47:54 +08:00
我现在在用 python 写后端，感觉真的原始，难用，无时无刻不在怀念着前端的良好体验
|
 |
11
debuggerx 2023-03-30 12:54:16 +08:00 1
需求是多样且多变的，对某些简单项目来说“过度工程化”，对某些复杂项目却是“工程化不足”，没法简单下定论的。
总的来说，前端项目需求是越来越复杂的，工程化的探索和进步就是为了适应这样的变化。 |
 |
12
CEBBCAT 2023-03-30 13:08:02 +08:00 6
「入乡随俗」「清官难断家务事」「家家有本难念的经」
那个帖子的楼主之所以被喷是因为以一个门外汉的水准去吐槽前端领域，显然没说这话的资格。 如果站在前端工程师的角度去剖析前端何以至今，那么不管是唱衰还是叫好，总不会被骂成这个样子。 回到这个帖子，我似乎没看剖析在哪里，更多的好像是认准了“前端过度工程化”的基调，然后扯到“大聪明”，“求职困难”上。 也许可以举个例子，如果能从开发效率、架构设计需要，软件工程实现上来分析，那么想必会很有干货。 |
 |
13
EscYezi 2023-03-30 13:30:06 +08:00 via Android
看了下楼主的项目，不用 nodejs 的话如何管理依赖呢？现在有太多资源托管在 npm 上了
|
|
14
HiCode OP 1
@EscYezi 手动复制引用代码。没有包管理，例如想用 vant ，直接在 html 文件里面加上：
<!-- 引入样式文件 --> <link rel="stylesheet" href="https://unpkg.com/[email protected]/lib/index.css" /> <script src="https://unpkg.com/[email protected]/lib/vant.min.js"></script> |
|
16
HiCode OP @weixind 我不是反对前端迭代优化。我说的大聪明，是指那些没搞清楚前端频繁迭代原因，反而“以频繁学习新知识为荣”的前端从业者。
|
 |
18
bhbhxy 2023-03-30 14:25:49 +08:00 1
@ma836323493 所谓大道至简就是纸上谈兵。把大象关进冰箱要几步：打开冰箱门，把大象关进去，关冰箱门。但在实际操作中你要考虑大象从哪里来，要用什么设备运输，一路上大象吃什么，冰箱要多大尺寸，需要多少材料来造，如何选择更省钱等等一系列问题。而工程化及各种工具就是为了各个场景应运而生。
|
 |
19
poorAshenOne 2023-03-30 14:27:34 +08:00
看到最后一句...
靓仔. 爆照我就给你点 star |
 |
20
Mutoo 2023-03-30 14:43:18 +08:00 1
前端之所以变化快是为了应付变化的需求，以及变化的环境。由浏览器或操作系统的迭代升级都会影响前端。简单讲，前端是在多变的客户端环境下进行开发，后端是在稳定的服务端环境下进行开发。前者非常不可控，后者相对可控。更别提多跨平台跨浏览器的需求了，这些都是后端不需要考虑的。不学新东西几乎不可能，除非操作系统和浏览器不再升级了，屏幕分辨率不再变大了，设计趋势也不再更新了。
再者，所有的新框架都是为了更好的应付更加复杂的变化而存在的，哪怕是最早的 jQuery ，他的口号与是 write less do more ，解决了很多跨浏览器的兼容问题。后来 backbone 引入了 mvc 以及双向数据绑定。React-Flux 提出了单向数据流，减轻了开发者的心智负担，再后来 Vue 引入了 reactivty 让数据响应更加直觉化。 就不提其它的工具链（ bundler ，linter ，testing ）哪一次新的东西被提出来不都是进步么！这有什么好喷的。 |
|
21
HiCode OP |
|
22
Mutoo 2023-03-30 16:00:31 +08:00 via iPhone
@HiCode 你没看到我说的重点，前端写的程序不只是运行在自己的浏览器上。就当当这点，就不知道多出多少工作量了。以至于 webpack 配置工程师都可以变成一个岗位，这是后话。
|
 |
23
yunyuyuan 2023-03-30 16:13:22 +08:00
我猜 OP 不写 angular
|
 |
24
sky857412 2023-03-30 16:14:22 +08:00 1
很多人忽略了为啥前端工程化了，就是移动端的崛起，国内当时还没前后端分离，大家都在一个工程下面玩，后端直接返回的 html ，多了一个移动端就不能够这么玩了，然后再前端工程化。然后搞 javascript 的又热衷造轮子，导致前端越来越复杂
|
 |
28
twelvechen 2023-03-30 18:04:48 +08:00
@HiCode 请问这样如何处理懒加载呢，没有用到的组件也被放到页面里了。
还有如果目标用户都是现代浏览器，很多不必要的 polyfill 代码是不是也被加载了。 如果项目里用到了其他库，这些库与 vant 的依赖有相同的，那么相同的依赖库是否被多次加载到页面中了呢。 这些问题只是工程化所要解决的一小部分，前端起步晚，面临的环境比较复杂，国内国外的应用场景可能也不一样，toB 代码和 toC 都可能有很大的差异。工具大部分都是为了解决不同的问题的，所以一直在变，只是因为问题一直都有而已 |
|
30
yunyuyuan 2023-03-30 18:15:34 +08:00 2
我就服气了，很多人一边用着 vue ，一边吐槽前端恶心，前端热衷于造轮子，好像他们口中的“前端”，是一名浪荡的花花公子，angular 摆在这里他们又不用
|
|
33
HiCode OP 1
@twelvechen
支持动态加载组件，其实还是 vue 官方文档里的那一套，模版里用： <component v-bind:is="indexView"></component> 然后 JS 代码里通过下面代码去按需加载组件： // 动态加载其他组件 VueWebLoader.import('view/index.vue', function(component) { that.indexView = component; }) |
|
36
HiCode OP |
 |
38
duke807 2023-03-30 18:35:35 +08:00 via Android
当年跟着 angular 1 、2 … 一路走过来，现在只用 vanilla-js.com
|
 |
39
hzxxx 2023-03-30 18:36:51 +08:00
我觉得前端（不涉及图形）难不难，培训班 s 和当前的前端市场已经给出了铁一般的答案
|
 |
40
sofukwird 2023-03-30 20:11:48 +08:00 via Android
那该如何热重载呢？
|
 |
41
wangerka 2023-03-30 21:13:52 +08:00 3
何苦呢这是。。。不知道如何吐槽
@sofukwird 别说热重载，他这个都不支持 scope style ，更不支持 scss ，就是把 style 插到 head 里： https://github.com/dongnanyanhai/vue-web-loader-2/blob/38597e6613dee5b6adc7f6da0abc601906b5ca83/js/vue-web-loader-2.js#L218 而且这里解析 script 的正则也太简陋了，可能匹配错误 https://github.com/dongnanyanhai/vue-web-loader-2/blob/38597e6613dee5b6adc7f6da0abc601906b5ca83/js/vue-web-loader-2.js#L175 整体上就是把.vue 文件请求回来手动 Vue.component()了一下 |
 |
42
Imindzzz 2023-03-30 21:58:50 +08:00
老实说，被标题引战吸引进来的，看到有贴 github ，以为会收获什么新奇的观点
可通篇看到楼主在输出情绪而不是观点。悲哀呀。 希望你能完善一下文档，持续关注。 |
|
44
HiCode OP 1
@wangerka 不好意思，这个项目给不想陷入前端 node.js 工具链的人用的，要完整功能请使用官方的 loader 。
|
 |
45
ixixi 2023-03-30 23:39:34 +08:00
我反对
|
|
46
yunyuyuan 2023-03-30 23:51:56 +08:00 via iPhone 6
@wangerka 我也看了看代码，属实惊掉下巴，用 fetch()加载 SFC ，再前端用正则手动把 script,template 和 style 分离，可能 OP 都没听说过 vue-loader 。
另外，2023 年了，作为一个 lib ，就不说没上 typescript 了，居然还用 var ，你想支持 ie ，vue3 它也不支持啊。 我错了，如果这是 OP 所说的工程化，那确实没有争执的必要😓 |
 |
47
zbowen66 2023-03-31 00:52:29 +08:00
大部分都是 kpi 罢了
|
 |
48
n18255447846 2023-03-31 03:34:08 +08:00
首先，我支持 OP 的项目。
其次，看这么多前端老油条吐槽，何必呢？都是打工人。 最后，说过度工程化不太苟同，我的感觉是才发展了百分之六十多的样子，可能不到十年内又将迎来一次技术变革（发展到百分之八十多），工具链，三大框架，运行环境等 |
 |
49
KSR 2023-03-31 08:18:55 +08:00 5
什么是“过度工程化”呢？
这个“度”在哪里呢？ 这个“度”的标准不会是 “我会不会” 吧? |
 |
50
461229187 2023-03-31 08:55:49 +08:00 2
你的项目解决了你的痛点，那些大佬的项目解决了大部分人的痛点，至少解决了我的痛点
|
 |
51
rsyjjsn 2023-03-31 09:48:26 +08:00
工程化是为了让一部人可以很容易进来，一部分人很难进来
|
 |
53
gogozs 2023-03-31 11:06:41 +08:00
谈具体问题，说大道理没意义
|
 |
54
tairan2006 2023-03-31 11:18:28 +08:00 1
angular 不是做得挺好的
要不楼主讨论一下 Linux 桌面？ |
 |
55
urnoob 2023-03-31 11:18:36 +08:00 1
后端老人，当年 jquery 直接操作 html 习惯了。都没法理解现在的前端了。
光语法就天翻地覆了。一堆 export 啥的。一脸蒙 |
|
56
sofukwird 2023-03-31 11:19:16 +08:00 via Android 1
给你来一点老东西的小小震撼 systemjs vue
|
|
57
HiCode OP @n18255447846 “我的感觉是才发展了百分之六十多的样子”——好像你这个说法才是对的，我看到了他们的乱序发展，没看到他们乱序发展后实际上的进度并不高。
|
|
59
HiCode OP @tairan2006 我对 linux 桌面不熟悉，你有什么观点或想法可以直接说。
|
|
61
HiCode OP @sofukwird 写了一大堆内容，结果提交的时候没了。
再简单说一下吧，我知道有很多同类的项目，我是看过他们代码的，我在其他帖子会着重感谢 Vue-rap 这个项目给我提供的思路。 上面很多人提到这个项目简陋，实际上，我是从第一版的繁复砍掉大量多余功能，精简到现在第二版的简陋。 |
 |
62
qrobot 2023-03-31 14:27:46 +08:00 1
写了一堆 460 行代码, 没一行是算法, 然后他说
前端 “以频繁学习新知识为荣” 是一种 “大聪明” 的表现 对此, 我的建议是 你的这个不如 VanillaJS 至少 VanillaJS 效率比你的高, 依赖少运行速度快. 并且 VanillaJS 满足你所有的一切要求 |
 |
63
AaronWang13 2023-03-31 15:08:50 +08:00
楼上说的对
|
|
64
HiCode OP @qrobot 我不确定我这个项目的代码，跟你说的这些话有什么关系？
还是你大脑先预设我就写了这个一个 js 项目，然后以此项目来评论我对前端的了解？ 你开心就好，正常讨论也是有门槛的，建议增强逻辑锻炼。 |
 |
65
zhanlanhuizhang 2023-03-31 16:16:50 +08:00
@uni 兄弟，你可以学学 sqlite 的开发者，用 c 写后端。就当作练习技术了。
|
 |
66
ruxuan1306 2023-03-31 16:21:11 +08:00
不重要，图形界面增长已经过拐点了，下一代是自然语言界面。
|
 |
67
zoharSoul 2023-03-31 16:21:43 +08:00 2
确实, 同为大前端领域
Android/ios 就没 web 前端这么离谱..... |
 |
68
Envov 2023-03-31 16:26:08 +08:00
我同意题主的论点
我以为题主可以拿出很屌的东西把「杂乱工程化」按在地上摩擦 但是题主这个项目显然不足以支持这个论点 |
 |
69
WasteNya 2023-03-31 17:13:16 +08:00
可是很多团队的需求是需要
校验代码并统一团队的代码规范（类似 eslint ） 实现前后端的快速对接（类似 openapi-typescript-codegen ） 压缩包裹体积（类似 terser-plugin ） 处理本地开发存在的跨域问题（类似 http-proxy-middleware ） 大幅度减少文档依赖和类型问题的 bug （类似 typescript ） ...... 最终不还是回到了工程化上了吗 |
 |
70
himozzie 2023-03-31 17:15:15 +08:00
多数企业的业务场景不需要那么多工程化支撑。但等队伍大了，项目多了，复杂度高了，就明白为啥工程化还远远不够了
|
 |
71
dode 2023-03-31 23:41:00 +08:00 via Android
npm ，nodejs 创建几十万文件我可以理解，java ，go 也都是这么搞的，但是每个项目都复制一份实在是醉了
|
|
72
HiCode OP @Envov 没有没有，主意看这个项目地址下面那句话：
“这个项目本质上算是对前端工程化的一种吸收和反对，前端生态非常丰富，是可以好好利用的，但前端开发的流程还在改进中，需要暂时避开。” 这个项目本身是一种“逃避”，对前端乱七八糟工具链和流程的一种逃避，发在这里主要是表达我的态度，不是论证观点的。 |
 |
74
wazggcd 2023-04-01 04:54:07 +08:00 via Android
@HiCode 如果想使用你的框架有些疑问：
如何用 less ，typescript 之类的？ 如何引入浏览器兼容性的垫片？ 依赖的包是不是没法做到按需加载？ 开发的时候代码提示和代码检查方便吗？ 提交代码前能自动检查代码格式有问题的不让提交吗 如果代码检查有特殊的要求，能支持自定义吗 如果都支持，感觉是不是又回到了工程化的老路了？ 其实还有很多疑问，webpack 配置复杂，但其实 webpack 但每一个选项基本都是为了解决某一类问题存在的。都是工作，没有人会无聊到写无用的配置项。 另外我觉得你吐槽 webpack 没问题，但你不能在推广你的框架的时候吐槽 webpack ，因为你这个框架能做的事，跟 webpack 要做的事不一样：你俩不是竞品，你的框架是一个特定的细分场景下的解决方案。 探讨为主，不是非要抬杠哈 |
Select Language