V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
weimo383
V2EX  ›  程序员

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

  •  
  •   weimo383 · 118 天前 via Android · 10728 次点击
    这是一个创建于 118 天前的主题,其中的信息可能已经有所发展或是发生改变。
    被 webpack 整晕的一天。想问问后端构建工具是不是很方便🌚🌚
    119 条回复    2021-08-11 23:13:02 +08:00
    1  2  
    nanzm
        1
    nanzm  
       118 天前   ❤️ 8
    ngn999
        2
    ngn999  
       118 天前
    后端无论 make,还是 CMake 都比 webpack 要简单太多
    Smash
        3
    Smash  
       118 天前
    不仅麻烦,而且技术更新太快,可能才学没多久的构建工具,立马就不管用了...
    rpman
        4
    rpman  
       118 天前   ❤️ 3
    屎堆多了自然麻烦
    okampfer
        5
    okampfer  
       118 天前   ❤️ 2
    因为我们写的前端代码需要做转码(transpile)后才能在浏览器中运行。我们本地开发习惯的那些方式,模块加载、路径解析等等,放到浏览器执行环境中会发生变化。我觉得正式因为这种差异导致前端工程化的复杂化。

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

    另外推荐使用比较现代化的脚手架代替手动配置 webpack,比如 vite 。
    sheepzh
        6
    sheepzh  
       118 天前
    最难得地方:配置文件不向下兼容
    yitingbai
        7
    yitingbai  
       118 天前   ❤️ 7
    我也被前端打包惊了, 一个普通 web 项目, node_modules 竟然有几万个小文件
    weimo383
        8
    weimo383  
    OP
       118 天前 via Android
    @okampfer 碰上 electron 啥的还是 GG
    KouShuiYu
        9
    KouShuiYu  
       118 天前   ❤️ 9
    应为它解决的问题本身就是复杂的🤷‍♂️
    walpurgis
        10
    walpurgis  
       118 天前 via iPhone
    webpack 配置工程师没听过吗,新项目没有浏览器兼容问题的话直接上 vite,又快又简单
    darksword21
        11
    darksword21  
       118 天前
    后端完全不懂前端想问一下前端的构建指的是什么?
    Rache1
        12
    Rache1  
       118 天前   ❤️ 34
    前端现状就是一堆吃上饭的人,一个劲的在研究怎么样新来的吃不上饭
    weimo383
        13
    weimo383  
    OP
       118 天前 via Android
    @Rache1 后端也是啊🌝🌝
    Mithril
        14
    Mithril  
       118 天前
    @okampfer 后端管这个叫做编译

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

    其实主要就是因为从一开始设计就只是个简单的脚本语言,根本就没想做完备的工程化解决方案。后面再加起来就很头疼。
    不仅仅是前端有这问题,Python 也是一样。
    dinjufen
        15
    dinjufen  
       118 天前   ❤️ 1
    @darksword21 就是想开发爽一点,各种新语法、框架、文件依赖、代码压缩等,但你开发爽了浏览器又不全认,所以得有个工具来干这个脏活
    emeab
        16
    emeab  
       118 天前
    @Mithril php 也是(
    KouShuiYu
        17
    KouShuiYu  
       118 天前
    @Mithril 我觉得前端面对文件类型的要比后端复杂 js,css,scss, json,各种图片, 再加上各种版本问题,兼容性问题
    netwjx
        18
    netwjx  
       118 天前   ❤️ 1
    如果你要编译的程序需要运行在

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

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

    后续程序的分发, 竟然还和编译有关(CDN , 静态资源更新)
    ztxcccc
        19
    ztxcccc  
       118 天前
    @emeab composer 比 npm 好多了
    lscexpress
        20
    lscexpress  
       118 天前
    @ztxcccc 是的,而且 composer 几乎没有自身报错的时候,我想尝试一下前端安装框架文档来 npm 也报错,而且看到过好几次前端的同事 npm 也报错。
    QHKZ
        21
    QHKZ  
       118 天前   ❤️ 23
    npm install 给我的感觉就是这样的
    https://imgur.com/r/wtf/nqfWVeV
    KatowiZz
        23
    KatowiZz  
       118 天前 via Android
    如果 c++有 cargo 的话...
    chengxiao
        25
    chengxiao  
       117 天前
    每次运行 npm 那一堆 warn 看的我都怀疑人生.....
    beginor
        26
    beginor  
       117 天前
    rollup 可以试一下, 感觉这几年逐渐崛起了!
    lululau
        27
    lululau  
       117 天前
    前端构建工具其实是后端技术😂
    gBurnX
        28
    gBurnX  
       117 天前
    题主对后端是不是有什么误会...您这只是晕一天,后端构建环境,一个特殊的 rpm 依赖都有可能要搞一天。
    crclz
        29
    crclz  
       117 天前
    angular 从来都没这种鸟问题
    Dragonphy
        30
    Dragonphy  
       117 天前
    @yitingbai #7
    刚做前端的时候都惊了,还能这么搞,windows 下删文件巨慢,WSL 还好😡👊
    namelosw
        31
    namelosw  
       117 天前
    前端有简单的,比如 rollup,写库可以,真正前端项目的话需求的功能更多。

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

    这样一比后端构建那点问题就是弟弟。
    WildCat
        32
    WildCat  
       117 天前   ❤️ 37
    Actrace
        33
    Actrace  
       117 天前
    tmpUI 完美解决痛点。。
    molvqingtai
        34
    molvqingtai  
       117 天前
    @lscexpress #20 npm 报错大概率是国情问题
    veike
        35
    veike  
       117 天前 via Android   ❤️ 1
    @molvqingtai too young too simple
    xsen
        36
    xsen  
       117 天前
    @Rache1 @12 哈哈哈,这总结经典
    xsen
        37
    xsen  
       117 天前
    @gBurnX @28 看来你不是个合格的后端。做后端连 docker 都不知道,确实少见
    jiyinyiyong
        38
    jiyinyiyong  
       117 天前
    如果项目小, 试一下 Vite.

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

    Webpack 发展到现在也就十年不到, ES Module 时间更短, 不成熟.
    huangsw
        39
    huangsw  
       117 天前
    有个东西叫脚手架,无论开发组件库、工具库,第三方脚手架基本都可以帮你解决
    Rebely
        40
    Rebely  
       117 天前
    node modules 无底洞 加上 webpack 孱弱的性能简直了。 期待一下 vite 和 esbuild
    michaelcheng
        41
    michaelcheng  
       117 天前   ❤️ 1
    前端其实可以说是面向资源开发,而不只是面向代码,所以构建这一步要处理的东西就多。

    同理,就跟我们讨论后台的时候,往往会带上运维相关的内容,一样的复杂。
    abcbuzhiming
        42
    abcbuzhiming  
       117 天前   ❤️ 4
    工程化的思维是近 10 年才引入前端的,后端则早的多了,至少人月神话那个时候就开始了。前端的构建工具不够好用的根源还是时间太短,坑没踩完。不说别的就光一个 npm 设计问题,连作者都觉得设计失败的玩意还是很多人说 npm 设计的好。。。再过个 10 年,等社区对什么是真正的好,达成共识了,估计前端工程化就成熟了,现在内部意见都不统一,你觉得好的东西我觉得是屎,这种环境下工具链不可能让人满意
    shintendo
        43
    shintendo  
       117 天前   ❤️ 16
    因为前端页面的复杂化(主要是富交互化),导致越来越需要开发的工程化,工程化的方式部分模仿了后端和客户端开发,也有一些前端独有的问题需要边摸索边前进,摸索的过程中就出现了各种框架各种工具的井喷,这也是“前端三个月换一个框架”的印象的来源(实际上现在的三大框架最年轻的也已经 7 年了)。

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

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

    需要打包的资源包括但不限于: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
        46
    whyso  
       117 天前
    构建?是编译吗? go build 拖拽文件就完了啊
    erlking
        47
    erlking  
       117 天前   ❤️ 1
    有多少公司的项目真的复杂到需要用 Webpack ?一般情况下有什么是 CRA, ng-cli, vue-cli 搞不定的?
    runze
        48
    runze  
       117 天前
    主要是 webpack 麻烦,不用 webpack 会简单得多
    mtmzorro
        49
    mtmzorro  
       117 天前
    @QHKZ haha 感谢承包了我今日的笑点,形象。
    gBurnX
        50
    gBurnX  
       117 天前
    @xsen

    合格的后端是吧?来,解释一下,我之前的问题,与 docker 有什么关系?
    fenglangjuxu
        51
    fenglangjuxu  
       117 天前
    我也觉得 所以我现在对 前端的技术 很抵制 不愿意去学 和接触
    比较喜欢偏原生的一些 html 项目
    lancelock
        52
    lancelock  
       117 天前
    不都有脚手架?大部分都不用自己配吧
    anguiao
        53
    anguiao  
       117 天前
    没那么复杂的需求就不要直接用 webpack 了,一般都有现成的脚手架,直接用就行。
    或者直接抛弃 webpack,用更现代的构建工具,比如 vite 。
    pacexy1
        54
    pacexy1  
       117 天前   ❤️ 1
    为什么 Chromium 这么复杂?不就是显示个网页吗?
    为什么 VSCode 这么复杂?不就是在网页里写个 textarea 吗?
    libook
        55
    libook  
       117 天前
    工具是用来解决问题的,不是用来制造麻烦的,所以如果真的有需求要用某个工具来满足,就用,没有的话也不必硬上,很多简单交互页面用原生 JS 和 WebAPI 写起来也很方便,最新的原生 Web API 功能多得令人惊讶,更别提 WebComponent 这种可以一定程度上替代框架的东西,就算用框架也可以用 CDN 模式( Vue 就有这种用法,不需要任何打包工具),以及 Bulma 之类的纯 CSS 样式框架。不光前端,各个技术栈都是这样的。

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

    没有人喜欢大而笨重的东西,但凡是具有一定规模的前端项目都是囊括了各种角度刁钻的产品需求(特别是各种奇葩的浏览器兼容),不站在巨人的肩膀上纯靠手撸早就饿死了。
    magicdawn
        56
    magicdawn  
       117 天前
    裸 webpack 很麻烦,用个 wrapper 就好了
    我推荐 https://poi.js.org/
    fkdog
        57
    fkdog  
       117 天前   ❤️ 1
    个人觉得从 jquery 时代过来的前端开发普遍缺乏工程化思想, 外加浏览器兼容原因, 导致前端工程化工具发展的初期, 各门派林立质量参差不齐.

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

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

    现在基本很少会有前端去纠结这类配置问题, 因为现在前端应用基本都是 vue 、reactjs, 他们都已经做好了相关的脚手架让你直接上手, 你只需要打命令 build 就行.
    nicevar
        58
    nicevar  
       117 天前
    主要是前期不够专业,想法又多,屎山堆得差不多了,谁来都解决不了,github 有意思的现象就是一个前端的项目一大堆的 issue 都是无法构建
    rekulas
        59
    rekulas  
       117 天前   ❤️ 5
    shakukansp
        60
    shakukansp  
       117 天前
    本质是前端没有办法知道你写的代码最终运行的环境是什么,只能兼容

    你写后端的时候最后部署在哪会没有 B 数吗
    charlie21
        61
    charlie21  
       117 天前
    前端构建工具分为两种,一种是 angular 、另一种是 非 angular
    pabupa
        62
    pabupa  
       117 天前   ❤️ 3
    我不做前端的原因就是,他们在把问题复杂化,,,,根本不解决任何问题,反而引入了很烦人的新问题……
    pabupa
        63
    pabupa  
       117 天前
    @pabupa 用 jqery 也完全可以写出来模块化的、漂亮的代码。
    pabupa
        64
    pabupa  
       117 天前
    @ZxBing0066 你并不需要兼容所有的选项,只选择适合自己业务的不久行了吗?
    xsen
        65
    xsen  
       117 天前
    @gBurnX #50 因为 docker 要解决的其中一个问题,就是你说的
    所以用 docker,就不会出现你提出的问题
    killerv
        66
    killerv  
       117 天前   ❤️ 39
    你们不要再吐槽 node_moudles 了,前几天救了我的命,我手滑 rm -rf 没提交的项目,发现之后赶紧 Ctrl + C,还好 node_moudles 还没删完,不然 src 肯定没了。
    kevin262516
        67
    kevin262516  
       117 天前
    @pabupa 业内这批顶尖的的人认可啊,普通人有什么办法呢;呵。。
    pecopeco
        68
    pecopeco  
       117 天前
    同意前端起步晚的说法,现在处在前端快速发展期间,而后端工具链基本已经很成熟了,公司里的老人根本看不懂前端在写啥,他们只能理解 js html css 一把梭
    timpaik
        69
    timpaik  
       117 天前 via Android   ❤️ 4
    打个比方,就好比你写 C++/Qt,但是你需要调用一堆 Python 脚本,还得交叉编译到 ARM,可气的是那堆 Python 脚本还 ffi 调用了一堆 rust x86_64 的库,当然还有更可气的,目标运行环境的 glibc 比 centos 6 还差
    Felldeadbird
        70
    Felldeadbird  
       117 天前
    前端历史遗留问题太多,以前很多优秀的库,作者没维护了。后面接棒的人要搞构建环境真的吃力和浪费时间。

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

    -------------
    对比起后端来说,一般只要运行语言版本对的上。构建就是把代码丢过去,或者 IDE 编译就完事。而且大多数错误网上都有各种案例,很少有冷门的问题出现。这应该算是和前端构建起来少出问题的原因把。
    randomboi
        71
    randomboi  
       117 天前
    后端构建工具是不是很方便: NO
    TomatoYuyuko
        72
    TomatoYuyuko  
       117 天前
    @pabupa 早年间我也用过 requireJS+jquery 写项目,处理数据密集型的功能太麻烦了,后来加了个 ko 才勉强好点。再后来数据可视化项目多了直接换 vue 了,外加移动端项目,要用到的技术变得越来越繁杂。我觉得前端复杂化是跟随互联网需求发展的,毕竟需要直接面对用户,网速越快,平台越丰富,前端屁事越多,没办法的事。
    zooeymango
        73
    zooeymango  
       117 天前
    你也可以自己写一个构建工具,大家看看怎么样
    code4you
        74
    code4you  
       117 天前
    webpack 长时间不用就忘记了~~

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

    看以前的配置回忆下 不知道是记忆不好的 还是因为工具复杂的~ 😶
    baipiaoguai
        75
    baipiaoguai  
       117 天前
    razzle 了解一下,基本的配置都直接搞定了,不用自己操心
    xujiahui
        76
    xujiahui  
       117 天前
    webpack3 的时候确实懵逼,4 简化后感觉挺好的,不需要怎么配置,可能是我没碰到特别复杂的场景吧,你们一般碰到什么场景需要配置复杂的 webpack ?
    byte10
        77
    byte10  
       117 天前
    @rpman 你这评论太精辟了,前端花里胡哨的东西多,自然不断的反复修改论证,估计真的是狮多了。
    @michaelcheng 好像也是有点道理
    @killerv 高级黑,笑死🤣。


    后端也是复杂的配置,比如 gradle,应该不比前端的坑少。脚本语言的通病,花里胡哨的东西贼多,带来的代价就是贼复杂的,对于初学者很不友好,容易出错。至于 c++ cmake 那些感觉还好一些。
    abear
        78
    abear  
       117 天前
    @Dragonphy rimraf
    dzzhyk
        79
    dzzhyk  
       117 天前
    vite 现在发展怎么样
    exonuclease
        80
    exonuclease  
       117 天前
    是吗 我记得我当初为了把一些代码抽出来做成 nuget package 一个 PR 改了 2000 个文件
    darknoll
        81
    darknoll  
       117 天前
    1. 没法强制用户用最新的浏览器,所以需要把新语法转成旧语法
    2. js 模块化机制糟糕,在 es module 之前没有好用的
    pabupa
        82
    pabupa  
       117 天前
    @TomatoYuyuko 复杂的业务就是需要复杂的实现,这是没办法的事情。原来用 jQuery 要做的事情,用了 React 之后,你还是要做,而且使用更复杂的方式去做……
    leetom
        83
    leetom  
       117 天前
    @QHKZ 鸭子跑到一半,突然门口一滩血,里面的鸭子出不来了。
    vance123
        84
    vance123  
       117 天前
    要不是浏览器钦定, lz 才不会用这垃圾脚本语言写程序
    catbestme
        85
    catbestme  
       117 天前
    @rekulas
    哈哈哈,形象!
    goodboy95
        86
    goodboy95  
       117 天前
    当时学 webpack 纯粹是因为想用 async……
    WildCat
        87
    WildCat  
       117 天前   ❤️ 1
    1. Webpack 配置不会请用 TypeScript 写 config: https://webpack.js.org/configuration/configuration-languages/

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

    另外,webpack 慢可以用 esbuild-loader https://github.com/privatenumber/esbuild-loader
    littlebaozi
        88
    littlebaozi  
       116 天前
    普通做个项目,用 cli 工具生成就行了 不用去学 webpack 自己配置啊 想要改配置再去搜就很快上手了
    是为了深入学习那就另说
    catbestme
        89
    catbestme  
       116 天前
    前端所谓的模块化,确实是搞的花里胡哨的,webpack 里面是配置套配置,模块套模块,关系搞得一塌糊涂,比后端的关系搞的还混乱,工具写的这么烂,真不知道有什么好自傲的
    Greatshu
        90
    Greatshu  
       116 天前
    Trim21
        91
    Trim21  
       116 天前 via Android
    后端发明一门新语言可以直接用对应语言的运行时或者编译器,要用新特性只需要更新工具链。

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

    而且模块化还是后来才出来的,为了用户体验也不可能全用浏览器原生支持的模块化方案。(看到个用 vite 的例子,因为依赖太多,浏览器开始渲染前要请求几百个 js )
    ada87
        92
    ada87  
       116 天前
    后端构建有没经历过这个时代( Java )?:

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

    停留在 jQuery 的当然可以说,同样是轮子,你的轮子能干的事我的轮子也能干,为啥偏要换?
    Obrigado0815
        93
    Obrigado0815  
       116 天前
    不是有脚手架吗??
    xd199153
        94
    xd199153  
       116 天前
    你用哪个 UI 框架不都有脚手架嘛,你刚开始搞,先跑起来再说,后面熟了再定制配置

    @ngn999
    还有就是我挺看不惯应该这种心态的,觉得前端就应该简单。
    新手你直接来配个 cmake 你说要多久。就算新手配置安卓环境那也不是分分钟就能配置好啊,为啥前端构建配置就不能花多一点时间来配置呢。
    DOLLOR
        95
    DOLLOR  
       116 天前
    说说你放着各种脚手架不用,铁着头去折腾 webpack 的理由。
    weimo383
        96
    weimo383  
    OP
       116 天前 via Android
    @DOLLOR
    来年春招做准备
    Seanfuck
        97
    Seanfuck  
       116 天前
    jquery 时代一把梭挺好的呀,又快又简单,前端就没多少页面需要搞什么工程化。
    qrobot
        98
    qrobot  
       116 天前
    我敢说,你们大部分说 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
        99
    leohxj  
       116 天前
    用脚手架干活, 用 webpack 整活.
    shayuvpn0001
        100
    shayuvpn0001  
       116 天前
    @QHKZ 21# 笑死
    1  2  
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2412 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 14:12 · PVG 22:12 · LAX 06:12 · JFK 09:12
    ♥ Do have faith in what you're doing.