为何前端构建工具这么麻烦

[weimo383]

被 webpack 整晕的一天。想问问后端构建工具是不是很方便🌚🌚

[nanzm]

是

[ngn999]

后端无论 make,还是 CMake 都比 webpack 要简单太多

[Smash]

不仅麻烦,而且技术更新太快,可能才学没多久的构建工具,立马就不管用了...

[rpman]

屎堆多了自然麻烦

[okampfer]

因为我们写的前端代码需要做转码(transpile)后才能在浏览器中运行。我们本地开发习惯的那些方式，模块加载、路径解析等等，放到浏览器执行环境中会发生变化。我觉得正式因为这种差异导致前端工程化的复杂化。

不过情况正在不断改善，特别是 ES6 问世后，统一的模块加载标准有了，现在现代的浏览器(Chrome, Firefox, Edge, Safari)都 100%支持 ES6 了（当然我们写代码用的是 ES6+）。

另外推荐使用比较现代化的脚手架代替手动配置 webpack，比如 vite 。

[sheepzh]

最难得地方：配置文件不向下兼容

[yitingbai]

我也被前端打包惊了, 一个普通 web 项目, node_modules 竟然有几万个小文件

[weimo383]

@okampfer 碰上 electron 啥的还是 GG

[KouShuiYu]

应为它解决的问题本身就是复杂的🤷‍♂️

[walpurgis]

webpack 配置工程师没听过吗，新项目没有浏览器兼容问题的话直接上 vite，又快又简单

[darksword21]

后端完全不懂前端想问一下前端的构建指的是什么？

[Rache1]

前端现状就是一堆吃上饭的人，一个劲的在研究怎么样新来的吃不上饭

[weimo383]

@Rache1 后端也是啊🌝🌝

[Mithril]

@okampfer 后端管这个叫做编译

@darksword21 就是你在后端编译打包项目做的那些活。编译器把一种语言翻译成另一种，分析项目依赖把它们都打包到一起。

其实主要就是因为从一开始设计就只是个简单的脚本语言，根本就没想做完备的工程化解决方案。后面再加起来就很头疼。
不仅仅是前端有这问题，Python 也是一样。

[dinjufen]

@darksword21 就是想开发爽一点，各种新语法、框架、文件依赖、代码压缩等，但你开发爽了浏览器又不全认，所以得有个工具来干这个脏活

[2kCS5c0b0ITXE5k2]

@Mithril php 也是(

[KouShuiYu]

@Mithril 我觉得前端面对文件类型的要比后端复杂 js，css，scss, json,各种图片, 再加上各种版本问题，兼容性问题

[netwjx]

如果你要编译的程序需要运行在

不同的操作系统 x 不同的 app 内嵌环境 x 不同的操作系统版本 x 不同的 app 版本

针对新版本还得能用上新版本的优化

后续程序的分发, 竟然还和编译有关(CDN , 静态资源更新)

[ztxcccc]

@emeab composer 比 npm 好多了

[lscexpress]

@ztxcccc 是的，而且 composer 几乎没有自身报错的时候，我想尝试一下前端安装框架文档来 npm 也报错，而且看到过好几次前端的同事 npm 也报错。

[QHKZ]

npm install 给我的感觉就是这样的
https://imgur.com/r/wtf/nqfWVeV

[RRRoger]


[KatowiZz]

如果 c++有 cargo 的话...

[chengxiao]

每次运行 npm 那一堆 warn 看的我都怀疑人生.....

[beginor]

rollup 可以试一下， 感觉这几年逐渐崛起了！

[lululau]

前端构建工具其实是后端技术😂

[gBurnX]

题主对后端是不是有什么误会...您这只是晕一天，后端构建环境，一个特殊的 rpm 依赖都有可能要搞一天。

[crclz]

angular 从来都没这种鸟问题

[Dragonphy]

@yitingbai #7
刚做前端的时候都惊了，还能这么搞，windows 下删文件巨慢，WSL 还好😡👊

[namelosw]

前端有简单的，比如 rollup，写库可以，真正前端项目的话需求的功能更多。

问题是前端的东西本来就很复杂，一会要打包图片，一会要字体，一会又要样式插入 TypeScript，JavaScript 还得有无数种语法扩展，还得能按浏览器比例 target 成不同版本的 JavaScript，而且经常还得用户看哪页只下载哪页相关的代码，看另外一页还不能公用的代码还不能重复下载。各种问题能无限举下去。

这样一比后端构建那点问题就是弟弟。

[WildCat]

[Actrace]

tmpUI 完美解决痛点。。

[molvqingtai]

@lscexpress #20 npm 报错大概率是国情问题

[veike]

@molvqingtai too young too simple

[xsen]

@Rache1 @12 哈哈哈，这总结经典

[xsen]

@gBurnX @28 看来你不是个合格的后端。做后端连 docker 都不知道，确实少见

[jiyinyiyong]

如果项目小, 试一下 Vite.

浏览器只能用文本形态来分发, 而不是 WASM, 更难禁止使用奇奇怪怪的功能, 而且 ES Module 出来太晚了, 社区野蛮生长时期的代码你总不能直接说不让人运行啊.

Webpack 发展到现在也就十年不到, ES Module 时间更短, 不成熟.

[huangsw]

有个东西叫脚手架，无论开发组件库、工具库，第三方脚手架基本都可以帮你解决

[Rebely]

node modules 无底洞 加上 webpack 孱弱的性能简直了。 期待一下 vite 和 esbuild

[michaelcheng]

前端其实可以说是面向资源开发，而不只是面向代码，所以构建这一步要处理的东西就多。

同理，就跟我们讨论后台的时候，往往会带上运维相关的内容，一样的复杂。

[abcbuzhiming]

工程化的思维是近 10 年才引入前端的，后端则早的多了，至少人月神话那个时候就开始了。前端的构建工具不够好用的根源还是时间太短，坑没踩完。不说别的就光一个 npm 设计问题，连作者都觉得设计失败的玩意还是很多人说 npm 设计的好。。。再过个 10 年，等社区对什么是真正的好，达成共识了，估计前端工程化就成熟了，现在内部意见都不统一，你觉得好的东西我觉得是屎，这种环境下工具链不可能让人满意

[shintendo]

因为前端页面的复杂化（主要是富交互化），导致越来越需要开发的工程化，工程化的方式部分模仿了后端和客户端开发，也有一些前端独有的问题需要边摸索边前进，摸索的过程中就出现了各种框架各种工具的井喷，这也是“前端三个月换一个框架”的印象的来源（实际上现在的三大框架最年轻的也已经 7 年了）。

与开发方式的工程化对应的，是作为运行环境的浏览器变化迟缓（ which 是可以理解的），于是这中间的落差就靠构建工具来弥平，构建工具把你工程化的项目吃进去，吐出最原始的、浏览器能认识的 html 、css 、js 文件。webpack 干的就是这活，又因为前述的原因，当时前端的工程化起步不久，很多东西都在摸索期，还没有沉淀出比较公认的方案，所以 webpack 的输入就各种五花八门，配置自然也就复杂了。更现代的打包工具如 vite 就简单很多。

一些人其实骨子里是看不起前端的，他们的印象还停留在十几年前切图轮播验表单的 the good old days，拒绝接受前端居然胆敢变成一门需要他们正儿八经坐下来学习的技术。所以他们面对前端开发的复杂化时，能想到的解释就是“故弄玄虚，简单问题复杂化，提高后来者的入门门槛”。说真的，大家都是写业务的打工仔，你会有闲心为了提高行业入门门槛而故意选择复杂难用的技术吗？前端要有这凝聚力，还至于跟你们一起 996 ？

[tabris17]

不难怎么堆 KPI

[ZxBing0066]

前端构建

需要打包的资源包括但不限于：js 、css 、html 、json 、图片、文本、字体

每种资源对应的类型包括但不限于：
js：es3 、es5 、es6 、es6+、ts 、coffee
css：css 、sass 、scss 、less
html：html 、template
json：json 、jsonc
图片：jpg 、png 、gif
字体：各种字体类型

各种模块引用方式兼容：amd 、cjs 、global 、esm 、dynamic import

各种语法支持

前端打包需要解决的问题包括但不限于：
整合资源、压缩体积、预处理代码、兼容处理、分包优化、首屏优化、动态加载优化

总结：环境使然，真没那么多人有空给别人找事

[whyso]

构建？是编译吗？ go build 拖拽文件就完了啊

[erlking]

有多少公司的项目真的复杂到需要用 Webpack ？一般情况下有什么是 CRA, ng-cli, vue-cli 搞不定的？

[runze]

主要是 webpack 麻烦，不用 webpack 会简单得多

[mtmzorro]

@QHKZ haha 感谢承包了我今日的笑点，形象。

[gBurnX]

@xsen

合格的后端是吧？来，解释一下，我之前的问题，与 docker 有什么关系？

[fenglangjuxu]

我也觉得 所以我现在对 前端的技术 很抵制 不愿意去学 和接触
比较喜欢偏原生的一些 html 项目

[lancelock]

不都有脚手架？大部分都不用自己配吧

[anguiao]

没那么复杂的需求就不要直接用 webpack 了，一般都有现成的脚手架，直接用就行。
或者直接抛弃 webpack，用更现代的构建工具，比如 vite 。

[pacexy1]

为什么 Chromium 这么复杂？不就是显示个网页吗？
为什么 VSCode 这么复杂？不就是在网页里写个 textarea 吗？

[libook]

工具是用来解决问题的，不是用来制造麻烦的，所以如果真的有需求要用某个工具来满足，就用，没有的话也不必硬上，很多简单交互页面用原生 JS 和 WebAPI 写起来也很方便，最新的原生 Web API 功能多得令人惊讶，更别提 WebComponent 这种可以一定程度上替代框架的东西，就算用框架也可以用 CDN 模式（ Vue 就有这种用法，不需要任何打包工具），以及 Bulma 之类的纯 CSS 样式框架。不光前端，各个技术栈都是这样的。

另外，一个东西如果没学明白的话，一定会有一种它复杂和难用的错觉（比如 C++语言、后端经典的 JavaEE ），Webpack 的 loader 和 plugin 搞明白了其实也就那么回事。

没有人喜欢大而笨重的东西，但凡是具有一定规模的前端项目都是囊括了各种角度刁钻的产品需求（特别是各种奇葩的浏览器兼容），不站在巨人的肩膀上纯靠手撸早就饿死了。

[magicdawn]

裸 webpack 很麻烦，用个 wrapper 就好了
我推荐 https://poi.js.org/

[fkdog]

个人觉得从 jquery 时代过来的前端开发普遍缺乏工程化思想, 外加浏览器兼容原因, 导致前端工程化工具发展的初期, 各门派林立质量参差不齐.

过了初期以后, 前端的各种构建工具普遍成型, 各个工具希望通过兼容对手工具的方式来抢夺用户, 于是工具配置开始复杂化.

最后就是各种遗留问题了.

现在基本很少会有前端去纠结这类配置问题, 因为现在前端应用基本都是 vue 、reactjs, 他们都已经做好了相关的脚手架让你直接上手, 你只需要打命令 build 就行.

[nicevar]

主要是前期不够专业，想法又多，屎山堆得差不多了，谁来都解决不了，github 有意思的现象就是一个前端的项目一大堆的 issue 都是无法构建

[rekulas]

@yitingbai

[shakukansp]

本质是前端没有办法知道你写的代码最终运行的环境是什么，只能兼容

你写后端的时候最后部署在哪会没有 B 数吗

[charlie21]

前端构建工具分为两种，一种是 angular 、另一种是 非 angular

[pabupa]

我不做前端的原因就是，他们在把问题复杂化，，，，根本不解决任何问题，反而引入了很烦人的新问题……

[pabupa]

@pabupa 用 jqery 也完全可以写出来模块化的、漂亮的代码。

[pabupa]

@ZxBing0066 你并不需要兼容所有的选项，只选择适合自己业务的不久行了吗？

[xsen]

@gBurnX #50 因为 docker 要解决的其中一个问题，就是你说的
所以用 docker，就不会出现你提出的问题

[killerv]

你们不要再吐槽 node_moudles 了，前几天救了我的命，我手滑 rm -rf 没提交的项目，发现之后赶紧 Ctrl + C，还好 node_moudles 还没删完，不然 src 肯定没了。

[kevin262516]

@pabupa 业内这批顶尖的的人认可啊，普通人有什么办法呢；呵。。

[pecopeco]

同意前端起步晚的说法，现在处在前端快速发展期间，而后端工具链基本已经很成熟了，公司里的老人根本看不懂前端在写啥，他们只能理解 js html css 一把梭

[timpaik]

打个比方，就好比你写 C++/Qt,但是你需要调用一堆 Python 脚本，还得交叉编译到 ARM，可气的是那堆 Python 脚本还 ffi 调用了一堆 rust x86_64 的库，当然还有更可气的，目标运行环境的 glibc 比 centos 6 还差

[Felldeadbird]

前端历史遗留问题太多，以前很多优秀的库，作者没维护了。后面接棒的人要搞构建环境真的吃力和浪费时间。

我在维护一个旧的前端库，用的 gulp2 。要用特定的 node 版本。我也没深入学习 gulp 新版的语法。不想浪费时间在构建上……

-------------
对比起后端来说，一般只要运行语言版本对的上。构建就是把代码丢过去，或者 IDE 编译就完事。而且大多数错误网上都有各种案例，很少有冷门的问题出现。这应该算是和前端构建起来少出问题的原因把。

[randomboi]

后端构建工具是不是很方便: NO

[TomatoYuyuko]

@pabupa 早年间我也用过 requireJS+jquery 写项目，处理数据密集型的功能太麻烦了，后来加了个 ko 才勉强好点。再后来数据可视化项目多了直接换 vue 了，外加移动端项目，要用到的技术变得越来越繁杂。我觉得前端复杂化是跟随互联网需求发展的，毕竟需要直接面对用户，网速越快，平台越丰富，前端屁事越多，没办法的事。

[zooeymango]

你也可以自己写一个构建工具，大家看看怎么样

[code4you]

webpack 长时间不用就忘记了~~

我这已经 2 个月没用 又忘记了

看以前的配置回忆下 不知道是记忆不好的 还是因为工具复杂的~ 😶

[baipiaoguai]

razzle 了解一下，基本的配置都直接搞定了，不用自己操心

[xujiahui]

webpack3 的时候确实懵逼，4 简化后感觉挺好的，不需要怎么配置，可能是我没碰到特别复杂的场景吧，你们一般碰到什么场景需要配置复杂的 webpack ？

[byte10]

@rpman 你这评论太精辟了，前端花里胡哨的东西多，自然不断的反复修改论证，估计真的是狮多了。
@michaelcheng 好像也是有点道理
@killerv 高级黑，笑死🤣。


后端也是复杂的配置，比如 gradle，应该不比前端的坑少。脚本语言的通病，花里胡哨的东西贼多，带来的代价就是贼复杂的，对于初学者很不友好，容易出错。至于 c++ cmake 那些感觉还好一些。

[abear]

@Dragonphy rimraf

[dzzhyk]

vite 现在发展怎么样

[exonuclease]

是吗 我记得我当初为了把一些代码抽出来做成 nuget package 一个 PR 改了 2000 个文件

[darknoll]

1. 没法强制用户用最新的浏览器，所以需要把新语法转成旧语法
2. js 模块化机制糟糕，在 es module 之前没有好用的

[pabupa]

@TomatoYuyuko 复杂的业务就是需要复杂的实现，这是没办法的事情。原来用 jQuery 要做的事情，用了 React 之后，你还是要做，而且使用更复杂的方式去做……

[leetom]

@QHKZ 鸭子跑到一半，突然门口一滩血，里面的鸭子出不来了。

[vance123]

要不是浏览器钦定, lz 才不会用这垃圾脚本语言写程序

[catbestme]

@rekulas
哈哈哈，形象！

[goodboy95]

当时学 webpack 纯粹是因为想用 async……

[WildCat]

1. Webpack 配置不会请用 TypeScript 写 config： https://webpack.js.org/configuration/configuration-languages/

2. 不想配置，请直接用 vite

另外，webpack 慢可以用 esbuild-loader https://github.com/privatenumber/esbuild-loader

[littlebaozi]

普通做个项目，用 cli 工具生成就行了 不用去学 webpack 自己配置啊 想要改配置再去搜就很快上手了
是为了深入学习那就另说

[catbestme]

前端所谓的模块化，确实是搞的花里胡哨的，webpack 里面是配置套配置，模块套模块，关系搞得一塌糊涂，比后端的关系搞的还混乱，工具写的这么烂，真不知道有什么好自傲的

[Greatshu]

npm install

[Trim21]

后端发明一门新语言可以直接用对应语言的运行时或者编译器，要用新特性只需要更新工具链。

前端的新语言都得转成 js 和 CSS，想上新特性要么等用户升级，要么转义成旧代码。

而且模块化还是后来才出来的，为了用户体验也不可能全用浏览器原生支持的模块化方案。（看到个用 vite 的例子，因为依赖太多，浏览器开始渲染前要请求几百个 js ）

[ada87]

后端构建有没经历过这个时代（ Java ）？：

下载 jar 包,粘贴到 lib, 打开 eclipse，右键项目，导出为 war? 全程人工，本地环境？

停留在 jQuery 的当然可以说，同样是轮子，你的轮子能干的事我的轮子也能干，为啥偏要换？

[Obrigado0815]

不是有脚手架吗？？

[Imindzzz]

你用哪个 UI 框架不都有脚手架嘛，你刚开始搞，先跑起来再说，后面熟了再定制配置

@ngn999
还有就是我挺看不惯应该这种心态的，觉得前端就应该简单。
新手你直接来配个 cmake 你说要多久。就算新手配置安卓环境那也不是分分钟就能配置好啊，为啥前端构建配置就不能花多一点时间来配置呢。

[DOLLOR]

说说你放着各种脚手架不用，铁着头去折腾 webpack 的理由。

[weimo383]

@DOLLOR
来年春招做准备

[Seanfuck]

jquery 时代一把梭挺好的呀，又快又简单，前端就没多少页面需要搞什么工程化。

[qrobot]

我敢说，你们大部分说 webpack 不好用的人多半是把 webpack 当作 html-webpack-plugin 在用。

真的不清楚，webpack 什么时候变成的复杂的构建工具了？ webpack 本身很简单啊

主要就是一个 Entry(入口), Output(出口), Loaders(装载器) 就这三个配置，Entry 和 Output 是主要配置，和传统的 html js css 开发本身就是一样的。


你们为什么会感觉到复杂？

1. 就说 es6 -> es5 里面的转换，就有很多工具， 比如 babel 进行转换，babel 的配置本身不简单， 或者 esbuild 在或者 ts 也就是可以做到的
2. 例如 css 有很多技术栈， 例如 less，sass 还有 styled-components
3. 越灵活的工具，配置就越复杂， 越固定的东西使用越简单，webpack 让你感觉到复杂因为它太灵活了，基本上可以覆盖整个前端的技术栈

[leohxj]

用脚手架干活, 用 webpack 整活.

[shayuvpn0001]

@QHKZ 21# 笑死