02:16:04 UTC
例如： 我的工程如下，然后我想将：button下的index.jsx编译为当前目录下的index.js将grid下的index.jsx编译为当前目录下的index.js然后将他们公用的库，编译到demo下面的common.js
02:46:44 UTC
查了一下，webpack貌似没有针对每个文件配置编译后的路径。
个人建议将文件统一生成到一个目标目录比较好，题主说的生成到“当前目录下“不是好的实践，发布代码应该与源码进行目录分离。如果担心重名的情况，可以配置规则解决：
"button": "demo/button/index.jsx"),
"grid": "demo/grid/index.jsx")
'dist/js',
filename: "[name].js",
chunkFilename: "[name].js"
plugins: [
new CommonsChunkPlugin("common.js", ["button", "grid"])
output中的[name]对应于entry中的key值，因此生成后的文件名是button.js和grid.js。
07:38:17 UTC
谢谢你的解答，想了一下午，想出了个解决办法首先在定义entry的时候可以，entry = {
"/demo/button": "demo/button/index.jsx"),
"/demo/grid": "demo/grid/index.jsx")}然后输出的时候，就能建到指定目录下去了
08:52:14 UTC
也是可行的方案，对这个问题有效不依赖 Gulp、Babel、WebPack，还能优雅地写代码吗？ - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
已注册用户请 &
- a JavaScript code quality tool
不依赖 Gulp、Babel、WebPack，还能优雅地写代码吗？
· 310 天前 · 11223 次点击
纯属吐槽文，不服来辩。
不知道什么时候开始，前端开发已经到了不开一个 watcher 就无法工作的地步了。不依赖 Gulp 、 Babel 、 WebPack ，还能优雅地写代码吗？
那我就带你来回顾一下这一切是怎么发生的。
从哪开始说好呢？我们就从『前端打包』开始吧。
很久以前（也就五年左右吧，但是五年前端已经大变样了），页面的 JS 压缩（混淆）一般是用谷歌的 closure compiler 做的。但是突然蹦出来个 Node.js ，前端开发者们就开始第一次小试牛刀了，用 Node.js 来做 JS 压缩，一般都是用
JS 压缩做了， CSS 压缩是不是也可以做？ JS lint 是不是也可以做？自动测试是不是也可以做？文件合并是不是也可以做？
于是 grunt 应运而生，它可以帮你把这些事情都做了，只需要配置一个简单的 Gruntfile 即可。
同一时期， AMD 和 CommonJS 也出现了， Node.js 用 CommonJS 加载模块，浏览器用 AMD 来加载模块。前端们觉得可以统一一下，都用 CommonJS 来写，于是用上 browserify 之类的工具。
好了，这个时候一个前端项目需要有一个 Grunt （后来又有了 Gulp 等）任务用来打包前端资源，看起来就是一个标配了。
框架的兴起
前端们一直吐槽新手们用 jQuery 写出的「意大利面条」式的代码，于是发明的了一些框架，一开始比较火的是 MVC 框架（如 Backbone.js ），火了没多久，前端们发现 MVC 框架有很多相似的代码都是在做「绑定事件」「更新 view 」这些事情了，于是发现了 MVVM 框架（一种早年间被微软玩过的设计模式），最著名的库就是 AngularJS 。
此时的库都是不需要额外用 Grunt 做转译的。
直到 React 的出现。 React 背后的工程师（显示不是前端）发明了一种新的语法—— JSX ，把 HTML 和 JS 混合起来写。前端们看了一眼表示这才是写模板正确的姿势。唯一的问题是这种语法浏览器不支持，于是需要把 JSX 翻译成 JS 。
此时 Grunt 大概也因为性能太低被 Gulp 取代了。
于是此时用 React 的项目一定会去用 Gulp 将 JSX 翻译成 JS 。
ECMAScript 的发展
同时期， ES 发展也是非常迅猛。
IE 8 不支持 ES5 ，于是前端们说，「 IE 8 去死吧」，不想再支持 IE 8 了，因为那几年移动端发展迅猛，网页主要都是 H5 页面（不要问 H5 是不是 HTML5 ，不是 HTML5 ），所以很多前端确实不需要管 IE 8 。现在想想， Windows Phone 的失败，真是前端的福音啊。
前端就开始追新了，一定要第一时间用上最新版的 JS 语法。但是即便是 Chrome 和 Firefox 也不可能那么快就支持最新语法。于是前端说，不过就是在 Gulp 里再加一道转译嘛，用 Babel 把 ES 2016 的语法转译成 ES 5 就好了。
于是 Gulp 里又多了一项任务。
经过这两三年的飞速发展，前端们是不是应该重新思考一下，做一个网页之前要加这么多 Gulp 任务的初衷到底是什么？是否解决了问题。
从目前的结果来看，基本可以总结为
DOM 不好用，换成虚拟 DOM
CSS 不好用，换成 CSS in JS
浏览器支持的 JS 不好用，换成 ES 最新版语法，然后转译为浏览器支持的 JS
DOM Event 不用了，去新造一个 Event 机制。
Gulp 用得太多了 watch 很慢，于是加上了 hot module replacement
基本把能抛弃的都抛弃了。
实际上这些变化非常适合复杂的 Web 应用，然而 90% 的页面根本不是单页面应用好吗！
能不能让我写一个 CSS 一个 JS 刷新一下就能看到效果！为什么我要花那么多时间来学习转译工具，以及解决转译过程中的各种问题。
总感觉『弊大于利』。甚至有的时候觉得这是『没有问题，创造问题也要上』。
最后送给前端们一幅图：
第 1 条附言 &·& 310 天前
不服的同学，就说说，加了这些东西的好处是啥，然后我负责说坏处。
第 2 条附言 &·& 310 天前
搞前端也要讲政治正确吗？你们就不要质疑我的动机，好好讨论利弊吧。
第 3 条附言 &·& 310 天前
大家可以思考这么几个问题：
不用 bable，用浏览器支持的 ES 行不行？（IE 8 不支持？shim？）
不用 JSX（React 写起来就不爽了，最讨厌 React 这点了）行不行？
不用 Webpack 行不行？如果你依赖的 Webpack 被前端界抛弃了怎么办？显然 JS 加载器的标准会出来的。你到时候怎么看 Webpack 都别扭。
在想得狠一点，前端很多东西发展到现在，都违背初衷、过早优化、过度设计了。
模块化：文件划分模块-& 命名空间 -& AMD -& CommonJS -& UMD -& …… （问题越来越多）
加载器：script src -& load script -& requirejs -& browserify -& webpack -& hot module replacement -& …… （开发是爽是爽了，执行和调试可不见得）
你们都看不到弊端是吧？
第 4 条附言 &·& 310 天前
你也可以只思考一个问题：
现在的 HTML 、 CSS 和 JS ，真的没办法直接用了？（大型项目里）用起来真的那么难用？非要转译。
你加上这些工具和转译后，就没有后果？
利弊讲清楚，我就服。
189 回复 &| &直到
08:48:38 +08:00
& &310 天前
@ @ 不要去搞配置，直接从最简单的入手吧。
& &310 天前
@ 你光看体积不够，还要看看调试、新人学习、坑多不多，疑难好不好解决，特殊需求好不好处理。不过我相信中型项目是利大于弊的。
& &310 天前
@ 不要去搞配置，直接从最简单的入手吧。
& &310 天前
只是举出一个体积这么一个指标来反驳而已
看调试：调试是有工具的
新人学习：如果项目本来就用新技术，那么你干嘛不请一个本来就会新技术的新人？
坑，疑难：坑，疑难这个肯定会比旧技术多，不过你可以选新技术中已经成熟了的版本，比如 Angular 1.x 而不是 2.x
特殊需求：就是因为有特殊需求才搞出新技术的……
其实按照你那么说，根本就不是新技术的锅，而是技术选型的问题
& &310 天前
react 一直比较激进
JSX 在某些场景下还是很好用的，比如在教程里面
react 比较好的是 react native
& &310 天前
@ 如果是根据需求选型，我是无法反驳的。不过现在大部分项目都是跟风选型，不需要搞那么多转译和框架的，也搞得那么复杂。然后还不准说 React 的不好。。。明显，有些项目就是不需要用 React
& &310 天前
@ 如果楼上都像你这样列出利弊，就事论事，就很好讨论问题了
很多人诛心是啥意思，我懒不懒想不想学新技术跟这个帖子有关系么。
& &310 天前
@ 我同意 React Native 才是 React 最大的卖点，其他都是可有可无的。
& &310 天前
我说了，熟悉前端的前提下，反正我用了不到十分钟看了一遍 webpack 的文档的使用部分然后就知道怎么写配置了，几十分钟是学 webpack 的 loader 开发了吧；
gulp 的使用就更简单了，就一个 task 一个 watch ；
es6 ……说实在的， es6 的新增语法和特性是浏览一遍就大概明白的；
我没觉得现在的打包工具很好，但是很容易使用，你要是觉得不会开发这些工具的插件就不算会用的话，当我没说……
& &310 天前
@ 如果是边用边查文档边踩坑的话，你的方法和时间是可以的。。。
& &310 天前
作为一个菜鸡后端，表示我前端还停留在写 LESS 上……
各种自动构建器只是听说过，从来没去使。
& &310 天前
看了文章和评论有点觉得楼主纯粹是因为不喜欢 React 就来喷 JS 这些年来的的新东西，真是没意思啊...
当然如果楼主想要否定这些年前端的组件化和工程化发展方向那也没啥好说的了。
记得以前写 less 还要专门用其他的工具转成 css 再来用，记得腾讯那会还出过一个专门的 GUI 软件，图片转成 base64 或压缩图片或压缩 js 还要专门找一个线上网址去完成，本地起一个 web 服务还有开启 php 环境或者用 python 启动，还有很多等等。。。现在 Gulp 把这些东西放在一个命令了全部能完成有啥不好嘛？如果你项目不需要就不用就是了，很多人还是会按照自己的需求来添加任务的，这有啥好质疑的嘛？也没人让你写一个海报页面把 webpack ， gulp 这些都搬出来啊
任何新技术新轮子出来都是有目的的，不管是像阿里一样为了 kpi 还是为了开源好玩，但是新的东西能流行起来肯定是有迎合到部分人的需求的，你可以认为有的人是为了跟风，但那也只是小小部分啊。
看过楼主之前那篇前后端分离感觉也是为了喷而喷，所以没啥好说的，楼主开心就好
& &310 天前
程序开发这件事上面……不可能有一下子全部搞明白然后投入开发不踩坑的吧
& &310 天前
just simply javascript fatigue fatigue
& &310 天前
@ 都说了是吐槽文。
我喷的不只是 React ，去年我还喷 Angular 1 了。希望这个不要也死掉
& &310 天前
@ 不是去年，是前年喷 Angular ，但是 NG 还是很火的。
然而我还是使用 NG 做项目了。
你可以看下标题，我喷的是，加这么多工具，最后没工具网页都不能预览了。原生 HTML 、 CSS 都抛弃了， JS 写得也是不能在浏览器上运行的版本，这还不奇怪吗？我没看到什么语言这么否定自己。
& &310 天前
@ 你没觉得我那篇喷前后分离的是真相么……
& &310 天前
先马后看，本帖讨论的问题很有意义。前端现在确实发展很乱，很多项目功能重叠且相互排斥，完全是群雄争霸的状态，新人入门经常迷茫应该学什么。稍微不幸运站错了队就可能付出时间学了一个刚会用就被淘汰的东西。
& &310 天前
现在的所谓前端工程化
1. minify - ok
2. less / sass - maybe ok ，毕竟 CSS 选择器写起来很麻烦，但也只是写起来爽了，稍微加快效率。
3. concat - maybe ok, HTTP/2 上了， concat 就收益不大了。
4. live reload - not ok 。 经常在我不想刷新的时候刷新了。
5. wabpack - 工程化，写起来爽了，没看出来解决了什么很大的问题。
6. jsx 、 bable 、 react - 全家桶， react 是选型问题，我还是那个太少， 90% 的网站不应该用 react
7. hot module replacement - 哈，是为了解决上面任务太多， watch 太慢，而不得不加的东西
8. 依赖分析 - 用上 CommonJS 后带来的副产品，文件太细，还想动态加载，又不想动态加载得太多，然后还延伸出更多关于依赖管理的问题，甚至改变了前端写代码的方式， inline script 直接不让写了。评价就是半成品的工程化，需要人为做很多事情。
& &310 天前
纠正： 我还是那个太少-&我还是那个态度
& &310 天前
个人觉得，工具都是为了项目服务的。
如果一个项目， 1 个静态页面。什么打包压缩统统靠边，因为增加这些的附加成本可能大于维护成本。
前端出现了 grunt ， gulp ， webpack ， babel 设置与各种浏览器的 pollfill ，这都是因为工程化的需要，现在的前端页面都有着大量的交互。与其说是简单的 web ，我更倾向于认为是 web app 。
当我们选择 less/sass/stylus ，是因为 css 的纯静态化，当在工程项目中需要维护时，无论是一个颜色，或者是一个边框。如果是全局配置， less 可以通过变量实现， css 却需要全局替换（增加了出错成本），这是在项目维护成本上体现的。
压缩静态文件，这点必不可少，流量=钱
es6 甚至 es7 ，为什么有人用，因为提供了大量的新特性：类定义，异步回调等等，这都能减少出错成本。众所周知， js 的优雅一半取决在回调的处理上
html5 ， css3 为什么有人用，因为大大方便了我们。 html5 的标签语义， css3 的新特性。当前浏览器不支持的情况下，各种 pollfill 也随之产生，等浏览器支持了，去掉 pollfill 就可以了。
所以，这也是在工程中，有架构师存在的理由：一个对所有技术都了解的人，会更好的平衡时间成本和项目成本，系统维护和持续迭代，才是工程的大头。这也是前端工程化的意义，我们需要更好更优雅的写代码，程序员应该只关注到代码提交，后续打包压缩上线，工具都应该自动帮你完成（ CI ），以前是 grunt ， gulp ， webserver ，现在是 webpack+nodejs ，这仅仅是工具，最后还是要看人的选择
& &310 天前 via Android
hot module replacement 是因为 watch 太慢？ 难道不是为了保留 dom 状态刷新
& &310 天前
@ 那个也是功能之一，但是意义不大，跟 live reload 一个性质，节省几下鼠标点击而已。
如果 watch 太慢，你就必须加 hmr 了。
& &310 天前
@ 原生 HTML 、 CSS 都抛弃了， JS 写得也是不能在浏览器上运行的版本。
所以说还是看你什么需求啊，一个简单的页面肯定还是用 html,css,js 写啊。但是如果有个需求复杂的项目，你用纯 html ,css ,js 写的效率和可维护性有用这些新东西来的好嘛？没有的话为什么不用呢？
至于语言为啥这么否定自己，我倒不是这么觉得，一来 web 诞生之出那会的 web 产品对 html ,css ,js 的要求没这么高，所以那会的语言和 api 都不像现在这么强大和丰富。但即使现在 html5 和 css3 强大了很多，还是不能满足一些人的需求啊。咋办呢，只能通过 js 来实现自己的需求啊，要是 js 能让 htm l 和 css 变得更适合他们的需求他们肯定会去实现的啊，谁让这三个是一伙的呢，所以就有了 react
jsx 这种别人看起来四不像的东西啊。但这只是部分人的需求啊，你赞同这种思想有这种需求就用啊，没有就用 jq 或者其他的框架呀，在没用 mv*框架之前，我用 jquery 写单页面应用写的也很爽啊，这和语言这么否定自己有啥关系么。不过楼主要是因为自己不喜欢这一套但是团队又在用，觉得不爽吐槽一下是可以的
& &310 天前
@ 能有多少网页是 app 啊……淘宝手机客户端那些页面我都不认为应该全部做成 web app 。
& &310 天前
@ 按照现在前端的节奏，永远不会去掉 polyfill 的
& &310 天前
@ 我是觉得前端工具已经可以用丧心病狂来形容了，一个简单的问题，被复杂化到不行了，现在加一个 babel ，得先下载 70 兆左右的 NPM 依赖，呵呵。
& &310 天前
@ 不觉得，你喷也要按照基本法啊，技术也要跟着市场走啊。你说要是招个半年都没招到一个会设计数据库和 css 写的好人，但是一个月就能找到一个会设计数据库的后端和一个写 css 的前端。如果你是老板你会继续去招那个所谓的全栈还是先招那两个只会后端和前端的来把产品先搞上线呢？
& &310 天前
@ app 是看交互复杂程度的，还有如果用了某框架，团队可以省 50%开发或者维护成本，那肯定会选。
pollfill 渐渐会去掉的。在 web 2.0 时候可能 webpack 也会精简了，浏览器原生支持模块异步加载的情况下。
至于 babel 大小，你管他干嘛。比如 100M 带宽， 2T 硬盘，这点大小可以忽略吧。起码我是除非影响我性能的 app ，其它我都不会管它
& &310 天前
@ 你说的是，大公司之所以细分，目的之一就是这个。但是细分的缺点我也需要点明是不是。如果某些小公司不明就里，向大公司学习，搞前后分离，只会自己吃亏。
& &310 天前
@ 大意为着复杂，复杂意为着有 bug ……
我偏向于一行依赖都没有的原生 ES 语法。而不是构建在 70 兆 JS 代码上面的浏览器还没支持的最新 ES 语法。
& &310 天前
@ 你说的是，大公司之所以细分，目的之一就是这个。但是细分的缺点我也需要点明是不是。如果某些小公司不明就里，向大公司学习，搞前后分离，只会自己吃亏。
这个是对的，看项目选择。
新语法的话看个人习惯了，我觉得方便使用的，我都会去试，前端发展太快，需要保持一种对技术的活力，乱七八糟的新技术太多，只有尝试以后能留下来的才是好的。才可以进项目
& &310 天前
@ 还有工程化也是一门学问，可以好好研究下。当项目，时间，人力结合在一起的时候。不是我们一个人简单写代码就可以了
& &310 天前
@ webpack 的文档很烂啊， loader 更是基本没文档。 查起来都累。
& &310 天前
@ 我不认为现在前端的工程化是好的工程化，就说一个，版本依赖问题，
假设我有个前端基础库
class.js
然后所有组件（ c1.js
c3.js ... c10.js ）依赖 class.js
然后页面依赖了 c1.js c2.js c3.js ... c10.js
好，现在 class.js 升级了，我是不是要去 c1.js ... c10.js 里全部改写 package.json ，发布一次。
当然，这不只是 JS 遇到的问题，其他语言也有，但这种情况在浏览器上是很麻烦的，因为你不能只升级 c1.js 而不升级 c2 ... c10 ，否则你的页面里就有两个版本的 class.js ……
这不是好的工程化，甚至比之前的 script 引入还要复杂和麻烦。
& &310 天前
我觉得楼主说的挺对的啊
& &310 天前
@ 共有依赖，这个处理方式和 jquery 一样， jquery 是怎么引的，这个差不多就怎么引。而且是不是该上 cdn 呢。这种举例都太细，没必要深究，取决于解决方式。其实最终目的就是为了给项目节省成本，提高质量，利于维护的意思。
说到这点，我记得我之前公司的前端团队做的就很好，我们前端代码，后端看了都是一目了然的。每个人代码风格，实现逻辑上可以有不同，但是总体的代码结构是基本一致的。这不是不尊重个性，其实也是最大限度自由后发挥个性的表现。
扯远了，我觉得差不多该说的都说了。
观点就是技术是为了项目服务的，最终从企业来说，需要考虑成本，所以一切能省成本，又不影响代码质量前提下，所有可以用的工具都是会上纲上线的。程序员角度，在没有 ci 情况下， webpack 这种能一键压缩完成的，还是挺省事的
& &310 天前
等 wasm 出来吧 这些就统统作废了
& &310 天前
说这么多，很想看看楼主的代码，这么多东西都吐槽，
说白了前端这些工具很明显的不适合构建复杂的项目，这些语言上的改进，框架和库的兴起，都是有原因的，效率是一方面，更好的构建项目，应对更复杂的工程才是关键
来，发下代码吧，看看楼主是如何不采用上述技术，构建一个健壮的复杂项目的
& &310 天前
@ 这些技术我都用了……边用边吐槽。如果我有更好的，我就发了。
& &310 天前
@ 当然其实我是有一个基于 jQ 的小框架的，不过改进不大，唯一的改进就是不需要 watch ，用原生，有 MVC 、有组件、利用原生 DOM Event 做模块通信，用在
的商家页面里了，并没有好到可以秒杀其他。
& &310 天前
觉得楼主说的挺对。前端的东西很碎片
前端就是——语言不够框架来凑
& &310 天前
其他语言都有预编译, 你怎么不说多余的呢. 前端加上这些才能说是正在的在完善生态吧.
& &310 天前
1. bable IE8 这个没的吐槽，前几年的 IE6 不是也就这么过去了么，现在 17%的占有率其实也就 1 年的时间了，和技术无关
2. JSX 相对于 angular 的 template 用字符串，这已经好太多了，我们还不讨论 angular 1 的 directive 设计的有多么糟糕， react 的组件只用了非常简单的理念就解决了 directive 解决不好的问题
3. 请找出一个比 webpack 更好的解决方案来
4. 现在前端工程的复杂度上讲过渡设计这件事情是要看项目的，简单项目 jq 自然几句话解决了，前端技术上的选择面很多，比比没有选择的时候
5. 模块化上， webpack
sourcemap 调试要完爆各种其他调试
& &310 天前
@ 对于组件的通讯，来说目前看来，在复杂的项目上，没有 flux ， redux 的理念，事件维护性上非常差，特别是需要大量维护状态的时候，非常难于管理，维护时难于梳理，项目简单的时候到还好说
& &310 天前
说这些，所表达的意思是，技术在前进，而且在通往更好的时代
& &310 天前
这些框架的出现都是为了解决相应的问题， grunt 的出现为了编译 js ， less ， gulp 的出现为了更快的编译，更舒适的写任务， webpack 的出现，则解决了异步加载，版本号等问题。出现问题，选择相应的框架，而不是，一开始就不带任何目的用框架，没有意义。
& &310 天前
这篇文字写得挺有意义，也挺能激起技术嘴仗来着，只不过有些童鞋有点过敏，立马下一个“楼主对新技术无感、懒”的定论，只是讨论和反思嘛！我觉得前端圈能变成现在介个样纸，原因多少有这些：
1 、无法满足前端切图仔 “翻身农奴把歌唱” 日益蓬勃的「逼格感提升」这个迫切需求。（说白了，这年头，动不动就讲逼格，团队逼格，对！说得就是你！你这个 Zhuangbility 的前端， 2333333 ）
2 、一切的始作俑者或导火索，确实跟 Node.js 的出现分不开。突然让前端人对后端各种好模式\工程自动化构建\组件模块化开发等那种长久“咬牙切齿羡慕嫉妒恨又无处施展的抱负”有了一一实现的可能，更是凭借其朝着让 JS 走遍天下大一统的野心道路全速前进；
3 、 W3C 、 ES 等标准早期的无所作为，加上确实相对落后的前端工程化早期现状。不过这几年随着各方推动，整个标准的定制之路也随之快速全面完善起来，故前端的现有各种工具\库\组件在标准出台之后，可能会逐渐谢幕？现在的这些感觉都只会是过渡阶段产物~这些确实实实在在增加了重复学习各种工具的成本，也导致出现了新人望着名目繁多各种名词两眼一抹黑的窘境，那个内心无处安放呐~
4 、前端，不再是可有可无的岗位，这些的改变，形成了更多后端&专业前端之间的技术壁垒。（这或许是有些前端人希望看到的，专业事交给专业的人干，以往后端随便都能写几个页面的历史从此不再。。。所以，薪资，必须提上来，是吧）
5 、大中型项目良好的用户体验及敏捷开发团队的快速迭代需求所愿。（对待平常较小的商业项目，杀鸡用牛刀，确实没必要，需求决定技术选型及一切，毕竟开发成本还是要为公司考虑的。只不过开发者自个儿应抱有持续学习的心态，业余时间倒是有必要适当的“杀鸡用牛刀”整些新鲜的私人玩意儿，你说呢？）
& &310 天前
说白了，工具是为了人服务，技术是为了业务服务，什么样的业务场景需要什么样的技术选型。如果只是做两个静态页面，完全可以靠手写，但是如果是做 100 个页面呢？ 1 个人做业务用啥都行，但如果是 5 个， 10 个人呢？如果页面是 10 个人访问，可以不考虑性能，但如果是 1 百万个人呢？之前前端都是多页面开发，为了用户体验出现了 spa ， mvc ， mvvm 等一堆框架，技术复杂度又提升了不少。不是工具越来越复杂，而是随着业务的增长在一步一步满足各种各样的需求时变的复杂起来。杀鸡不要用牛刀，打蚊子不要用大炮，合理的技术选型才是关键。
& &310 天前
Ember 才是前端框架公认的最后的王者
& &310 天前
贵端真乱。。
& &310 天前
调试方面不觉得麻烦吗？
-- 调试并不麻烦，本地双击 html 调试运行无法加载跨域 js ，导致务必运行一个小型服务器， webpack 的热加载功能让实时调试变得更简单
还有新人学习成本如何？
-- 个人觉得学习成本挺大的。我从 document.write 到现在的 react 断断续续花了一年。
还有一些 jQuery 的组件用不了了是不是都要重写？
-- 这个不太了解，不太用第三方组件
我的体会是隐性成本很多。我这里最大的成本就是，以前后端可以帮忙写页面，写在他看都不看全给我们前端了。少了很多人力！
-- 我现在的岗位前端比较重，设计师要求各种奇奇怪怪的页面，使用组件化的架构确实能减少大量成本，其中最重要的是静态资源管理的成本。不过不同需求结果不同，我同意你说的简单的页面其实并不需要打包系统。
& &309 天前
前端最麻烦就在于 不能直接基于后端的思维去 解决问题。
前端技术给我一种感觉就是，每天变着花样写页面。。
& &309 天前
客户端工程师、后端工程师、前端工程师用硬件工程师发明的时空穿越机来到了三年后。
只有前端工程师没有找到工作。
& &309 天前
前端就是折腾！
& &309 天前
@ 「最后没工具网页都不能预览了」
所以我喜欢那些 standard compliant 的工具。
比如 JSPM 你就可以选择离线编译或者在线编译（虽然性能很差），不用在命令行里输什么命令。随着浏览器支持 script[type=&module&]，在线编译的成本也越来越小，如果不需要 css! 之类的 custom loader 的话，甚至可以完全去掉转译这一步。
然后 PostCSS ，如果只用那些符合标准的插件的话，在最新版浏览器里调试时完全不需要构建。
我个人还是觉得未来的前端工具最终目标将是类似于标准 polyfill 的服务。
当然，前提是标准够好用，工具能力够强大……
目前的情况还是有点悲观的， JSPM 发展远不如 Webpack ， PostCSS 社区很多广泛使用的插件并不与标准兼容。
& &309 天前
至于我个人，只有 autoprefixer 这一个工具是「不用了就写不好代码」的，因为我真的记不住那么多 flex 标准……
& &309 天前
哈哈哈，吵吵挺好的
没人 bb 了说明狗带了
就这样接着吵呗
& &309 天前 via Android
看了这些回复……感觉总结成一句话应当是，不考虑实际场景直接下结论的行为就是耍流氓…
& &309 天前
@ 信不信 wasm 出来更乱
直接就可以把浏览器踢开自己搞了
& &309 天前
能加薪的技术就是好技术, 谁管什么用户体验,性能,速度. react 就是程序员的福音, 用完 react + redux 一整套, 大型项目一年后自己都不敢维护了, 绝对是加密利器
& &309 天前
不考虑需求都是耍流氓，就跟说房价不考虑地域一样，都是耍流氓
& &309 天前
即使考虑需求，我还是认为， 90% 的网站，不需要这么复杂的工具和框架。
也就在线 IDE 、编辑器、作图工具，才需要搞这么复杂。
& &309 天前
@ 刚看到 2/8 定律，就 2/8 分吧。新的东西出来都是有原因的，或者解决某种需求。 jQuery,在移动互联网就没有那么火了，我想总是有原因的。当然也能解决一些需求。更多的看需求，其实真正的在解决某种需求，技术都是为了实际需求才得以发展的。真没有看到为了创造技术而创造技术的，或许自己孤陋寡闻了。
& &309 天前
这些技术都是工具，要根据自己的业务需求来选择合适的工具，而不是盲目的乱用，也不是盲目的批判
就像现实生活中的工具一样，锤子，锄头，镰刀，推土机，吊车，机械化挖土机等等这些工具
来，你说说有锄头就可以挖坑了啊，干嘛还要挖土机呢，操作麻烦，噪声大还耗油，对于我这种想挖个小坑种个菜的人来说，真是没用的东西，都不知道发明出来干嘛
是的，你种点菜挖点土，用锄头真是再合适不过了，但你想想如果要你挖基角，建高楼大厦呢，还用锄头吗？用专业挖土机，蓝翔毕业人士效率不比你高 N 倍？
这是生活中随处可见的例子，生活中你知道要根据自己的需求来选择合适的工具，为什么编程写代码的时候就不懂这个道理了呢？
小项目就像你挖土种菜一样，怎么方便怎么来，大项目就像建高楼大厦一样，需要有工程师来评估用什么工具，什么框架快速稳妥的来实现需求
大项目不使用合适的工具，合适的技术框架来开发，真不知道会乱成什么样子，特别是多人合作的情况下，根本就没法开发，按照你的想法就使用原生 HTML,CSS 来手写，就命名问题就可以让你痛不欲生
& &309 天前
至于你说的&甚至有的时候觉得这是『没有问题，创造问题也要上』&，只能说你遇到的业务类别少
工具都是因为有需求才被创造出来的，而不是创造了工具才来想需求
就像你说的复杂的 web 网页是非常适合用这些工具的，就是因为做复杂页面的人遇到了这些问题，才创造出这些工具的啊
你的问题就在于自己没有碰到这样的业务需求，却硬要用这些工具，这是自己误用工具，而不是这些工具没用
& &309 天前
@ @ 你说的我不分认同，但真没那么多复杂项目，我做过最复杂的事在线图片编辑，也是用 backbone 做的
& &309 天前 via Android
如果没理解错的话，楼主主要围绕着大意『前端离开了这些新技术新工具就无法工作无法优雅地写代码的地步』展开。
这么早就下这么肯定的结论是不是给人一种钦定的感觉。。我倒是觉得，大部分作为会这些新技术新工具的人，他们离开这些工具也能写出质量不错的代码，而大部分不会这些的人他们不会也不想去学这些，前者大多集中在大公司独角兽，后者大多集中在小公司外包，他们的选择都很好因为都是最适合他们当前场景的。而作为白纸新人的我，还是希望能够赶上一波历史的进程吧
& &309 天前
@ 没那么多复杂的项目？骚年，只是你没遇到罢了，你也会说你做过的最复杂的是在线图片编辑，比这复杂难度高的项目多了去了，你没做过，不代表没有啊。
去看看国内一二线互联网公司的前端项目吧
& &309 天前
@ 我一直在一线互联网公司呀……
& &309 天前
@ 你的翻译不对吧……我在吐槽现在的新框架对工具依赖太重，没有工具，无法写代码，因为代码不能运行在浏览器里。
& &309 天前 via Android
在我负责构建的前端项目里，全面使用了 es2015 和 modules ，就是建立在 babel 和 webpack 上的。
因为构建过程对于源代码完全透明，取代这些工具的成本很低（如果有更好的方案），我是乐于见到上述工具被淘汰的，比如只需支持 chrome50+ / edge14+ / firefox48+ ， babel 这一步完全可以省略（什么你要 stage-0123 ？还有 jsx ？），再如将来 http2 的普及和浏览器支持 import ， webpack 也大可被替代。
这都几乎与所写的代码无关。我说的这些工具都只是把已经确定要来的未来做铺垫而已。
最后回答楼主，是，没有这个未来环境，（我）没法写了。
& &309 天前 via Android
@ 用 ES 6 好处很大么？ 我倒觉得变复杂了。我只喜欢 async await ，可以还没有。
就算浏览器准备好了，你也不会去掉转义的，因为 babel 用上了就停不下来，这只是我猜啊。
要真是与代码无关就好了，最大的关系就是能不能直接运行。我就是很在意，我写的代码不能运行这件事。
我也很在意，以后不能直接操作 DOM 这件事。也很在意， CSS 要写成 JS 。也很在意 Event 都不能用了。
这还是 Web 吗？
& &309 天前 via Android
@ 语言的好处见仁见智吧。
babel 可以停下来的，因为 es2015 年是分界线，以后的 es201x 不会像这次那样憋个几年一次过全更新了。
代码用到 webpack 的语法还是有一些 ， ensure 和 context 啰，合理使用还是能无痛迁移的。
CSS in JS 只是 React 的哲学，你我都知道它不是只面向 web 的。我同意不是大部分的 website 都有必要用 React 或其它框架。
既然是简单的 website ，也不必担心那些有复杂场景，以长得像 App 为荣的 webapp 的过度工程啊。
& &309 天前
Gulp 、 Babel 、 WebPack ，我一个都没用，还算前端开发吗？
& &309 天前 via iPhone
小胖喷的就是过度工程化，让原本简简单单的代码变得复杂化。让人没有工具，就没办法好好写代码了
& &309 天前
一大早看到这个帖子 感觉心好累
& &309 天前
@ 在某些人看来，可能不算『新·前端』吧
& &309 天前
@ 嗯？怀疑人生了吗？
& &308 天前 via Android
得亏当初选了后端方向
& &304 天前
@ wasm 出来以后 就变成现有的大平台上去了
& &292 天前
& &287 天前
其实就是为了写得爽而已
& &280 天前
其实东西是太多了，太头疼。 可是会用之后，又觉得真的很方便。
& &280 天前 via Android
现在依然用最原始的方式来写前端。。。。。
& &280 天前
讲了那么多，最后还不是打包压缩了吼？有啥区别，只是开发过程更 dev 了
& &280 天前
当然可以，不过写起来会很累而已。就好比让你写纯 CSS/JS 肯定没有写 Sass/jQuery 代码效率高
LZ 所说的『弊大于利』其实很大程度上是因为前端开发的领域各种设施不完备造成的，很多时候用这些东西也有些无奈。打包工具用久了的确很怀念以前直接手动写代码的那种即拿即用爽快感。但是时代不一样了，前端要做的事情和责任也不一样了
& &269 天前 via Android
？这些工具很难用？你应该不是前端吧，我当时学着用的时候 1 天基本就能正常配置用了~小项目最后也会维护，用个 css 预处理器，加点前缀用 gulp 很方便，还能 watch ，不然你手动呀。按需要配置才专业，不需要的又没让你配，不想用只是你还没深入学会，所以还处于舒适区~
& &269 天前 via Android
对了，你回上面照顾新人。新人不更应该多折腾学习么？难点就难点吧~学会拥抱变化，而不是说什么什么不好，选择你需要的，又没强迫你用
& · & 2086 人在线 & 最高记录 2466 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.7.5 · 84ms · UTC 07:56 · PVG 15:56 · LAX 00:56 · JFK 03:56? Do have faith in what you're doing.