9
为何前端构建工具这么麻烦
source link: https://www.v2ex.com/t/794664
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.
被 webpack 整晕的一天。想问问后端构建工具是不是很方便🌚🌚
56 条回复 • 2021-08-10 12:38:17 +08:00
nanzm 20 小时 45 分钟前 
2
okampfer 20 小时 35 分钟前 2
因为我们写的前端代码需要做转码(transpile)后才能在浏览器中运行。我们本地开发习惯的那些方式，模块加载、路径解析等等，放到浏览器执行环境中会发生变化。我觉得正式因为这种差异导致前端工程化的复杂化。
不过情况正在不断改善，特别是 ES6 问世后，统一的模块加载标准有了，现在现代的浏览器(Chrome, Firefox, Edge, Safari)都 100%支持 ES6 了（当然我们写代码用的是 ES6+）。
另外推荐使用比较现代化的脚手架代替手动配置 webpack，比如 vite 。
不过情况正在不断改善，特别是 ES6 问世后，统一的模块加载标准有了，现在现代的浏览器(Chrome, Firefox, Edge, Safari)都 100%支持 ES6 了（当然我们写代码用的是 ES6+）。
另外推荐使用比较现代化的脚手架代替手动配置 webpack，比如 vite 。
Mithril 19 小时 46 分钟前
@okampfer 后端管这个叫做编译
@darksword21 就是你在后端编译打包项目做的那些活。编译器把一种语言翻译成另一种，分析项目依赖把它们都打包到一起。
其实主要就是因为从一开始设计就只是个简单的脚本语言，根本就没想做完备的工程化解决方案。后面再加起来就很头疼。
不仅仅是前端有这问题，Python 也是一样。
@darksword21 就是你在后端编译打包项目做的那些活。编译器把一种语言翻译成另一种，分析项目依赖把它们都打包到一起。
其实主要就是因为从一开始设计就只是个简单的脚本语言，根本就没想做完备的工程化解决方案。后面再加起来就很头疼。
不仅仅是前端有这问题，Python 也是一样。
netwjx 19 小时 24 分钟前 1
如果你要编译的程序需要运行在
不同的操作系统 x 不同的 app 内嵌环境 x 不同的操作系统版本 x 不同的 app 版本
针对新版本还得能用上新版本的优化
后续程序的分发, 竟然还和编译有关(CDN , 静态资源更新)
不同的操作系统 x 不同的 app 内嵌环境 x 不同的操作系统版本 x 不同的 app 版本
针对新版本还得能用上新版本的优化
后续程序的分发, 竟然还和编译有关(CDN , 静态资源更新)
lscexpress 19 小时 10 分钟前
@ztxcccc 是的，而且 composer 几乎没有自身报错的时候，我想尝试一下前端安装框架文档来 npm 也报错，而且看到过好几次前端的同事 npm 也报错。
namelosw 13 小时 45 分钟前
前端有简单的，比如 rollup，写库可以，真正前端项目的话需求的功能更多。
问题是前端的东西本来就很复杂，一会要打包图片，一会要字体，一会又要样式插入 TypeScript，JavaScript 还得有无数种语法扩展，还得能按浏览器比例 target 成不同版本的 JavaScript，而且经常还得用户看哪页只下载哪页相关的代码，看另外一页还不能公用的代码还不能重复下载。各种问题能无限举下去。
这样一比后端构建那点问题就是弟弟。
问题是前端的东西本来就很复杂，一会要打包图片，一会要字体，一会又要样式插入 TypeScript，JavaScript 还得有无数种语法扩展，还得能按浏览器比例 target 成不同版本的 JavaScript，而且经常还得用户看哪页只下载哪页相关的代码，看另外一页还不能公用的代码还不能重复下载。各种问题能无限举下去。
这样一比后端构建那点问题就是弟弟。
WildCat 13 小时 14 分钟前 17
jiyinyiyong 3 小时 43 分钟前
如果项目小, 试一下 Vite.
浏览器只能用文本形态来分发, 而不是 WASM, 更难禁止使用奇奇怪怪的功能, 而且 ES Module 出来太晚了, 社区野蛮生长时期的代码你总不能直接说不让人运行啊.
Webpack 发展到现在也就十年不到, ES Module 时间更短, 不成熟.
浏览器只能用文本形态来分发, 而不是 WASM, 更难禁止使用奇奇怪怪的功能, 而且 ES Module 出来太晚了, 社区野蛮生长时期的代码你总不能直接说不让人运行啊.
Webpack 发展到现在也就十年不到, ES Module 时间更短, 不成熟.
abcbuzhiming 2 小时 30 分钟前 2
工程化的思维是近 10 年才引入前端的，后端则早的多了，至少人月神话那个时候就开始了。前端的构建工具不够好用的根源还是时间太短，坑没踩完。不说别的就光一个 npm 设计问题，连作者都觉得设计失败的玩意还是很多人说 npm 设计的好。。。再过个 10 年，等社区对什么是真正的好，达成共识了，估计前端工程化就成熟了，现在内部意见都不统一，你觉得好的东西我觉得是屎，这种环境下工具链不可能让人满意
shintendo 2 小时 27 分钟前 5
因为前端页面的复杂化（主要是富交互化），导致越来越需要开发的工程化，工程化的方式部分模仿了后端和客户端开发，也有一些前端独有的问题需要边摸索边前进，摸索的过程中就出现了各种框架各种工具的井喷，这也是“前端三个月换一个框架”的印象的来源（实际上现在的三大框架最年轻的也已经 7 年了）。
与开发方式的工程化对应的，是作为运行环境的浏览器变化迟缓（ which 是可以理解的），于是这中间的落差就靠构建工具来弥平，构建工具把你工程化的项目吃进去，吐出最原始的、浏览器能认识的 html 、css 、js 文件。webpack 干的就是这活，又因为前述的原因，当时前端的工程化起步不久，很多东西都在摸索期，还没有沉淀出比较公认的方案，所以 webpack 的输入就各种五花八门，配置自然也就复杂了。更现代的打包工具如 vite 就简单很多。
一些人其实骨子里是看不起前端的，他们的印象还停留在十几年前切图轮播验表单的 the good old days，拒绝接受前端居然胆敢变成一门需要他们正儿八经坐下来学习的技术。所以他们面对前端开发的复杂化时，能想到的解释就是“故弄玄虚，简单问题复杂化，提高后来者的入门门槛”。说真的，大家都是写业务的打工仔，你会有闲心为了提高行业入门门槛而故意选择复杂难用的技术吗？前端要有这凝聚力，还至于跟你们一起 996 ？
与开发方式的工程化对应的，是作为运行环境的浏览器变化迟缓（ which 是可以理解的），于是这中间的落差就靠构建工具来弥平，构建工具把你工程化的项目吃进去，吐出最原始的、浏览器能认识的 html 、css 、js 文件。webpack 干的就是这活，又因为前述的原因，当时前端的工程化起步不久，很多东西都在摸索期，还没有沉淀出比较公认的方案，所以 webpack 的输入就各种五花八门，配置自然也就复杂了。更现代的打包工具如 vite 就简单很多。
一些人其实骨子里是看不起前端的，他们的印象还停留在十几年前切图轮播验表单的 the good old days，拒绝接受前端居然胆敢变成一门需要他们正儿八经坐下来学习的技术。所以他们面对前端开发的复杂化时，能想到的解释就是“故弄玄虚，简单问题复杂化，提高后来者的入门门槛”。说真的，大家都是写业务的打工仔，你会有闲心为了提高行业入门门槛而故意选择复杂难用的技术吗？前端要有这凝聚力，还至于跟你们一起 996 ？
ZxBing0066 2 小时 17 分钟前 1
前端构建
需要打包的资源包括但不限于：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
各种语法支持
前端打包需要解决的问题包括但不限于：
整合资源、压缩体积、预处理代码、兼容处理、分包优化、首屏优化、动态加载优化
总结：环境使然，真没那么多人有空给别人找事
需要打包的资源包括但不限于：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
各种语法支持
前端打包需要解决的问题包括但不限于：
整合资源、压缩体积、预处理代码、兼容处理、分包优化、首屏优化、动态加载优化
总结：环境使然，真没那么多人有空给别人找事
libook 37 分钟前
工具是用来解决问题的，不是用来制造麻烦的，所以如果真的有需求要用某个工具来满足，就用，没有的话也不必硬上，很多简单交互页面用原生 JS 和 WebAPI 写起来也很方便，最新的原生 Web API 功能多得令人惊讶，更别提 WebComponent 这种可以一定程度上替代框架的东西，就算用框架也可以用 CDN 模式（ Vue 就有这种用法，不需要任何打包工具），以及 Bulma 之类的纯 CSS 样式框架。不光前端，各个技术栈都是这样的。
另外，一个东西如果没学明白的话，一定会有一种它复杂和难用的错觉（比如 C++语言、后端经典的 JavaEE ），Webpack 的 loader 和 plugin 搞明白了其实也就那么回事。
没有人喜欢大而笨重的东西，但凡是具有一定规模的前端项目都是囊括了各种角度刁钻的产品需求（特别是各种奇葩的浏览器兼容），不站在巨人的肩膀上纯靠手撸早就饿死了。
另外，一个东西如果没学明白的话，一定会有一种它复杂和难用的错觉（比如 C++语言、后端经典的 JavaEE ），Webpack 的 loader 和 plugin 搞明白了其实也就那么回事。
没有人喜欢大而笨重的东西，但凡是具有一定规模的前端项目都是囊括了各种角度刁钻的产品需求（特别是各种奇葩的浏览器兼容），不站在巨人的肩膀上纯靠手撸早就饿死了。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK