不依赖 Gulp、Babel、WebPack，还能优雅地写代码吗？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

推荐关注

› Meteor

› JSLint - a JavaScript code quality tool

› jsFiddle

› D3.js

› WebStorm

推荐书目

› JavaScript 权威指南第 5 版

› Closure: The Definitive Guide

这是一个创建于 3050 天前的主题，其中的信息可能已经有所发展或是发生改变。

原文：http://iwritejs.com/complex-front-end/

纯属吐槽文，不服来辩。

不知道什么时候开始，前端开发已经到了不开一个 watcher 就无法工作的地步了。不依赖 Gulp 、 Babel 、 WebPack ，还能优雅地写代码吗？

那我就带你来回顾一下这一切是怎么发生的。

从哪开始说好呢？我们就从『前端打包』开始吧。

前端打包

很久以前（也就五年左右吧，但是五年前端已经大变样了），页面的 JS 压缩（混淆）一般是用谷歌的 closure compiler 做的。但是突然蹦出来个 Node.js ，前端开发者们就开始第一次小试牛刀了，用 Node.js 来做 JS 压缩，一般都是用 uglify-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 条附言 · 2016-07-17 22:41:29 +08:00

不服的同学，就说说，加了这些东西的好处是啥，然后我负责说坏处。

第 2 条附言 · 2016-07-17 22:44:15 +08:00

搞前端也要讲政治正确吗？你们就不要质疑我的动机，好好讨论利弊吧。

第 3 条附言 · 2016-07-18 12:06:39 +08:00

大家可以思考这么几个问题：

不用 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 条附言 · 2016-07-18 12:21:50 +08:00

你也可以只思考一个问题：
现在的 HTML 、 CSS 和 JS ，真的没办法直接用了？（大型项目里）用起来真的那么难用？非要转译。
你加上这些工具和转译后，就没有后果？

利弊讲清楚，我就服。

gulp

前端

语法

grunt

189 条回复 • 2016-08-28 08:48:38 +08:00

1 2

❮

❯

FrankFang128

2016-07-17 18:28:16 +08:00

How is digging going to get us out of this hole?

herozzm

2016-07-17 18:32:08 +08:00 via Android

已经跟不上前端的脚步，再用最原始的 jQuery

murmur

2016-07-17 18:33:16 +08:00

需求人员和用户需求都是相违背的，最简单的 PC 端上很简单的搜索引擎或者什么页面，到手机端都是翻不到底的今日头条，而且我也不知道哪里有这么多的资源可以加载。。。
是的，这里说的就是 ADUI ，是个应用都是今日头条，连垃圾清理结束的页面都是今日头条
实际上我就要一个搜索框或者天气预报啊， 200px 的高度都要不了。。
所以很简单的需求做的比登天还复杂，前端这水这么深有一大半是需求给挖出来的

congeec

2016-07-17 18:34:38 +08:00

我不写前端，不过发现 Github 里这几个 repo 好逗
https://github.com/NamPNQ/You-Dont-Need-Javascript
https://github.com/oneuijs/You-Dont-Need-jQuery
https://github.com/cht8687/You-Dont-Need-Lodash-Underscore

elvba

2016-07-17 18:53:24 +08:00

不过我还是想问一下，文章中的 H5 指的是什么？

learnshare

2016-07-17 18:58:19 +08:00

不用 watch + LiveReload 的，因为我只想在该刷新的时候刷新；
不喜欢先编译后执行的前端开发流程，写代码 -> 保存 -> 手动刷新，这才是我的节奏；
只在发布之前用 Gulp 编译打包。

jspm 能很好地满足各种文件的热加载，除了 SASS 等少数速度奇慢（我用 LESS ），整体加载速度应该不比 watch -》 build -> LiveReload 模式差。

我目前在用 https://github.com/LearnShare/jspm-angularjs-1.x 这个项目结构。
对比过上面这个项目结构和 Angular2 的 ng-cli ，速度不错（虽然不太具有可比性）：

ChiangDi

2016-07-17 18:58:24 +08:00 via Android

写后端不也是要各种框架和工具，这不是很正常

Balthild

2016-07-17 19:06:55 +08:00 via Android

我现在还在用 jQ ……

另外同问 H5 是什么

learnshare

2016-07-17 19:13:13 +08:00

@FrankFang128 对于整个前端的发展，目前的工具和框架都是想提高 HTML 、 CSS 和 JS 的生产力。

HTML 、 CSS 和 JS 作为应用最广泛的 GUI 开发技术，因为其历史原因，并不能胜任现代 Web 应用的需求。我认为与其不断修补和增加新功能，不如从零创造一套现代化的 GUI 开发技术更加容易。但短时间内，不太可能有 HTML 、 CSS 、 JS 及浏览器平台这样极高的普及程度。所以大家还是在这个平台上继续修修补补。

learnshare

2016-07-17 19:21:36 +08:00

@elvba
@Balthild

H5 ？这是一个骗人的概念。

可以认为这是一种营销的产物。比如某段时间，一切产品都是“纳米技术”、“航天材料”

steven_yue

2016-07-17 20:11:23 +08:00 via iPhone

其实如果从一开始就抛弃 javascript ，什么事情都没有了

2016-07-17 20:20:48 +08:00

答曰：不能。有何意义？如果不能搞一个更好的轮子，何必急于向老的轮子开炮？

LancerComet

2016-07-17 20:25:23 +08:00

谁让前端项目的复杂度一直飙升，而 JS 的加载方式却自打出生没变过。浏览器原生模块化支持能解决一部分问题。

yiyizym

2016-07-17 20:28:49 +08:00

追新的永远都只是一小部分人，但他们往往叫得很大声。让人以为他们已经占据主流，但很快他们又会被下一波人掩盖。

yiyizym

2016-07-17 20:36:27 +08:00

话又说回来，我现在写前端还真不用 Gulp Babel Webpack 。

用户才不在乎什么单页应用，他们只想尽快用到产品。轮子换完一个又一个，生产效率说实话真的提高了吗？

lwbjing

2016-07-17 20:37:16 +08:00

不管框架怎么变， jQuery 依然是大爷...

rashawn

2016-07-17 20:39:39 +08:00

从之我要用到的开源项目就用了那些工具我不会的话 ………

int64ago

2016-07-17 20:40:27 +08:00

我想这个问题很久了，确实太累了

wxt2005

2016-07-17 20:46:50 +08:00

还不是因为前端要做的事情越来越多了。
没什么不好啊，多学点东西，多涨点工资。
等到三五年都没啥变化，公司发现人招多了，那才是最恐怖的阶段吧。

FrankFang128

2016-07-17 20:52:56 +08:00

@lwbjing 现在 React 、 Angular 、 Vue 这些框架已经开始排斥 jQuery 了

FrankFang128

2016-07-17 20:53:50 +08:00

@fy 为何不能呢？用上这些的好处真的大于坏处吗？

songjiaxin2008

2016-07-17 20:55:26 +08:00

这也正是前端的魅力所在，相信过几年，才会沉淀出几个真正的有质量的可选项。

aivier

2016-07-17 20:56:33 +08:00

现在只用 Gulp ，不用 Babel 和 WebPack ，项目规模比较小，用 WebPack 写个配置文件都快相当于一个功能了， Babel 的话总感觉不靠谱，所以还是 NodeJS 上写 ES6 ，浏览器上的写 ES5

shenqi

2016-07-17 21:19:22 +08:00

@congeec 不错不错。

defmacro

2016-07-17 21:21:02 +08:00

跟楼主想到一块去了，我最近想实践的想法更极端一点，是完全不用 node.js 来做前端项目，只依赖于浏览器端的 JS 引擎。无奈太忙没有时间实践

Powered

2016-07-17 21:26:53 +08:00 via Android

核心还在于，单页面的需求匹配不了对应它的技术的热度

shiye515

2016-07-17 21:30:31 +08:00 via Android

你们干嘛呢？
修高速公路
有什么用？
可以跑汽车
我这牛车在上面能跑的更快吗？
牛车不能上高速
那你们这不都是白忙活

smallpath

2016-07-17 21:39:52 +08:00

这个，我通篇都看到楼主在细数前端的进步，怎么最后突然画风一变就成了批评了

hanai

2016-07-17 21:41:38 +08:00

这些东西都是为了前端项目工程化的，而不是为了你想的那种修改一下立即就看的 demo

Vincent720

2016-07-17 21:44:33 +08:00 via iPhone

不整点新东西怎么涨工资哦

FrankFang128

2016-07-17 21:55:13 +08:00

@smallpath 进步的同时，引入更多坑

FrankFang128

2016-07-17 21:59:17 +08:00

@shiye515 没觉得是告诉公路，顶多是有坑的高速公路， React 模板里报个错，你都不知道要去哪里调试。

FrankFang128

2016-07-17 22:01:17 +08:00

@ChiangDi 后台不会像前端一样抛弃原生的 DOM CSS 和 JS

ericls

2016-07-17 22:01:19 +08:00 via iPhone

最厉害的应该是 redux 这个东西让你可以写没有副作用的代码

LancerComet

2016-07-17 22:09:39 +08:00

@hanai 仁兄说道点子上了

kookxiang

2016-07-17 22:13:50 +08:00

H5 ？其实就跟前端说的 IE6 一个道理~

sarike

2016-07-17 22:34:30 +08:00

@FrankFang128 楼主重新思考了些啥？“不好用”到底是哪里不好用，楼主有真正考虑过这些新玩意儿真正解决的问题吗？我觉得这更像是给那些面对迅速发展的前端技术却懒得去学习的人的借口吧。

> 实际上这些变化非常适合复杂的 Web 应用，然而 90% 的页面根本不是单页面应用好吗！

复杂的 Web 应用就一定是单页应用吗？再说了，为什么不用单页技术呢，现在单页完全可以在提升用户体验的基础上做到 SEO 友好。

当质疑一个甚至是一系列新技术的时候，我首先会想的是这些技术或者框架的创造者的从业经验、技术能力远大于我，他们面临的系统规模所带来的问题是我预想不到的，我相信我现在所质疑的问题是他们所综合考虑过的，这种想法会驱动我更深入的学习这项技术或这个框架，而且事实证明，随着对作者意图更深入的了解，自己之前的质疑会渐渐消除，甚至最终会喜欢上它……

犹记得乔帮主那句话： stay foolish stay hungry.

FrankFang128

2016-07-17 22:38:51 +08:00

@sarike 没有重新思考，只是吐槽。
在阿里用 React 开发基础 UI 框架算解决问题吗？

为什么要用单页面呢？好处是什么？坏处很明显，内存暴涨，维护困难。

预想不到的困难不是每个人都能遇到的， 90%的人遇不到。

用了 React ，然后，不喜欢。

littlebaozi

2016-07-17 22:56:06 +08:00 via Android

有感，之前想接触点 react ，推荐用 webpack ，配置文件写得头疼。不过各种配置好了，开发起来还是挺爽的。

geektony

2016-07-17 23:02:03 +08:00

@FrankFang128 抛开一切技术问题~ 技术界一直都是用脚投票的， star 数量，各种 React Conf ，组织，交流会。我相信比我们聪明的人很多，他们选择肯定有各种原因。大家也应该不会追求一种「不值得」的技术。很多时候，一个技术，不单单只为了产品本身，还有涉及产品开发的整个流程，例如协作、自动化等等。如果技术能提高团队生产力，那么就有存在价值。

另外，我在使用过程中，这些前端框架，技术都带给我高效的开发体验。我也很庆幸我在 Web 技术中的收货。

sarike

2016-07-17 23:02:28 +08:00

@FrankFang128 内存暴涨，维护困难

这是个技术问题，单页系统带来的是用户体验的提升，因为一个并非没有解决方案的技术问题而抛弃用户体验，我觉得这不是一个阿里技术人员的基本修养吧。哈哈……

jsq2627

2016-07-17 23:04:32 +08:00

@learnshare Java Applet 、 Flash 、 Silverlight 在各自鼎盛时期客户端普及度都很不错，现在全挂了。我觉得根本问题不是技术和浏览器普及度问题，而是商业模式的问题，是闭源输给开源的案例。
现在缺乏的是一种能以开源模式发展的优秀 GUI 框架，好在现在前端领域得到了业界足够的关注，即使目前的努力都集中于对现有 HTML/CSS/JS 的修补，我还是相信未来会有更多像 React 一样开创新基础体系的框架。

kokdemo

2016-07-17 23:04:55 +08:00

工程量决定工具。

shiye515

2016-07-17 23:05:54 +08:00

@FrankFang128 那也别用 css3 动画了 gpu 负载暴涨

bdbai

2016-07-17 23:13:16 +08:00 via Android

@FrankFang128
> React 模板里报个错，你都不知道要去哪里调试。

姿势问题。调试用未压缩的 React ，它会告诉你哪个组件出了错。加了 source map 的源码配合 Chrome 的调试器单步进去，周围看看就出来了。

scarlex

2016-07-17 23:40:51 +08:00

我写 demo 级别的东西都不需要用 gulp ， babel ， webpack 之类的工具啊...

murmur

2016-07-17 23:48:42 +08:00

@sarike 赞同这个观点，但是我一直在想，这么多年了，像支付宝+淘宝的组合，越来越少，刚需越来越少，如果撤掉砸的钱，还会有多少企业活下来。。
现在是个 app 都想成为今日头条，但是用户需要的是什么

3dwelcome

2016-07-18 00:05:26 +08:00 via Android

@murmur 我觉得用户并不需要什么、现在的前端、很大一部分是做 app,最后的命运绝大部分、都是被 app 红海吞噬淹没、这和前端的质量、并无太大关联。
所谓的编译式前端技术发展、更多的是对于自我的一种追求升华。而不是为了更好的满足用户需求。

jhdxr

2016-07-18 00:11:13 +08:00

这个问题我也思考过，不光是前端，其实后端或客户端也有这样子的现象 /问题，只不过没有前端这么显著而已。
我对这个问题的态度是，本身只是为了解决一个小问题所做的工具 /采用的方法，很多时候到后来为了 KPI/名望，把它越做越复杂，然后最后没法维护了就再另起炉灶来一个。

1. 加在一起就是灾难
2. 相信历史的沉淀

FrankFang128

2016-07-18 00:23:41 +08:00

@shiye515 GPU 一般是闲着的呀，降低 CPU 负荷蛮好

FrankFang128

2016-07-18 00:25:41 +08:00

@geektony 真要论用脚投票的话，

FrankFang128

2016-07-18 00:28:21 +08:00

@geektony 真要论用脚投票的话，使用 jQuery 和 Backbone 的人，远多于新的。至于 conf ，一般都是找新技术说，不会找成熟的说。只能作为佐证，不能作为主要论据。

geektony

2016-07-18 00:36:31 +08:00

@geektony 如果我们这么看呢，回到 jQuery 和 Backbone 推出的时代，它们也遇到 React Vue 现在的情况。其实运用各种手段都能解决问题，剩下的更多是使用者本身的决定。人才是技术的关键，而不是技术本身。所有的所有，最终都回到主观意识。创新本身就是我们自身对世界的探索，拥抱一下嘛~ 哈哈 :)

qwerasdf

2016-07-18 00:50:57 +08:00

“ 实际上这些变化非常适合复杂的 Web 应用，然而 90% 的页面根本不是单页面应用好吗 ”
但是 90% 的付薪水的工作，都要求用到那些东西， so ...

you want a work with Gulp 、 Babel 、 WebPack 、 React , or no work in this field ...?

个人项目基本用到 browserify 就完事了 ( 后端数据比较简单 ) ，公司项目跟 React ( 后端数据也比较简单，但要为变复杂的可能性作准备 —— 包括公司项目的复杂和我的下一步跳槽作准备，有备无患 ) 。不用辩

FrankFang128

2016-07-18 00:54:06 +08:00

@qwerasdf 我就喜欢你这样的，坦白承认不是为了用户需求而使用新技术。

3dwelcome

2016-07-18 00:59:38 +08:00 via Android

@FrankFang128
后端其实也在进步的、比如 c++、 conference 上不断的推出新语法、 c++11->c14->c17. 要说解决的多大的问题、也并没有。大神用 c99 、照样能写出牛比的代码。
只是人类的天性就是创作工具、使用工具、进化工具。这是使命、也是必然规律、和需求无关。现在 gulp 投票的人不多、再反复重构后、终将会替代现有的前端工作流。唯一需要的、只是时间的沉淀。
很多时候、想要跳的更高、就必须往后退一下、这阶段叫畜力。不能因为新的前端工具解决问题的效率不如老工具、就扼杀他们的存在价值。先阶段他们更多的是在探索、终有一天、会颠覆和影响浏览器的发展、我们需要的是多一点的耐心。

RaymondYip

2016-07-18 01:10:36 +08:00

看情况把，写几个简单的静态页，就加个 Browsersync 和 Gulp 我觉得很好。。
复杂的 Babel, webpack react 加起来不错

Powered

2016-07-18 01:11:34 +08:00 via Android

单页面应用 seo 不友好，所以这些单页面框架显得被高估

FrankFang128

2016-07-18 01:23:50 +08:00

@3dwelcome 但是后端没有出现前端这种『不用新工具的都是懒鬼』这样的『政治正确』的观点。现在前端你敢说一句 React 不怎么好啊，都会被认为是老古董了。

but0n

2016-07-18 01:26:24 +08:00 via iPhone

还是搞底层单纯些

Matrixbirds

2016-07-18 01:26:57 +08:00

私一般都会在 top level 上加一个`优雅`的注释

3dwelcome

2016-07-18 02:10:57 +08:00 via Android

@FrankFang128 没办法、后端可以自制工具、而前端基本只能使用工具。对于只能用工具的设计师来说、工具的先进程度直接决定了 b 格高低。
在人才辈出的年代、很难从设计上、本质和新人拉开明显差距、请允许前端设计师、用最先进的工具、来维护仅存的那点骄傲和虚荣。

Wangxf

2016-07-18 02:28:17 +08:00 via iPhone

从题主的意思可以看出来不想学习新技术

cuebyte

2016-07-18 02:47:07 +08:00

@Wangxf 从你的意思可以看出来很少思考

3dwelcome

2016-07-18 02:49:07 +08:00 via Android

@Wangxf 有本编程书叫算法的艺术、作者写了里面大部分算法、 90%的读者估计一辈子都用不到。

提主的意思是、不用编译的前端代码、已经足够满足现有需求、为什么一定要用类似 jsx 的编译语言、来写未来浏览器才可能支持的 js 语法。

其实无它、就是逼格高啊、哈哈。

Wangxf

2016-07-18 03:09:08 +08:00 via iPhone

@3dwelcome 新技术的出现一定是为了解决某种需求， react 的推出肯定是优先解决 facebook 的需求，你鄙视它只是因为你还没遇到 facebook 遇到的问题，虽然绝大多数是用不到 react 的，但是不能因此否定 react 存在的价值

3dwelcome

2016-07-18 03:19:05 +08:00 via Android

@Wangxf 我个人的观点、一开始就说过了、创造和改进工具、是人类的本能。和实际需求关系并不大。

我也没说 react 不好、只是说需要时间来完善、要培养到成熟期、需要一定的时间。

如果你一定要认为用未来 js 语法、是为了用户需求、那我也无话可说。

Wangxf

2016-07-18 04:05:17 +08:00 via iPhone

你也可以不用 jsx 啊，又没强制你用，用 jsx 的原因是为了更好的用 react ，不用 jsx 也可以，你可以理解为语法糖，哎，你这都没了解过就开喷，我无力…（葛优躺

3dwelcome

2016-07-18 04:33:36 +08:00 via Android

不用 jsx 的 react,逼格明显不够看.要说需求、 jQuery 也是为了满足需求、本质上并没有太大区别。 facebook 那帮高人、我相信用其他框架、也同样能完美实现用户需求。软件能达到的高度应该是看人、而不是看工具。

React 这种编译式前端、让发明者自己爽到的目的、远大于需求。对于重复代码的一种抽象。

作为码农、表示能用到让自己爽到的工具、是最开心的。

fuermosi777

2016-07-18 07:40:22 +08:00

这就是历史的车轮

lxrmido

2016-07-18 08:28:16 +08:00

现在复杂的前端需求越来越多了，多到了我要主动寻求节省时间的办法，于是自然而然地用上了，当然写简单页面的时候我是不用这些东西的。
1 、 es6 的语法能省好多好多好多时间，逻辑看起来也更清晰；
2 、 es6+webpack+gulp 能降低维护成本，因为代码的耦合性降低了，当然不能让前端新手维护老项目也是个麻烦事；
3 、学会这些，对一个熟悉前端的开发者来说，只要几十分钟；
4 、到目前为止，还没有 react 的什么事；
5 、然后来说 react ， react 引入的虚拟 DOM 的概念让人茅塞顿开，从此解决了混乱的模板问题，但是 react 的学习曲线对于还没玩腻传统前端开发的人来说是挺可怕的，因此用不用就见仁见智了。

┑(￣Д ￣)┍

综上，就我个人而言，在开发过程中用上这么一大坨工具的原因就两个：
1 、省时间；
2 、传统前端架构玩腻了，而且我已经是全栈好多年了，不找点新的玩具怎么行；

imdoge

2016-07-18 08:38:54 +08:00

让我想起以前看过的这篇文章
http://codeofrob.com/entries/you-have-ruined-javascript.html
我是写 ng 的，确实觉得有些繁琐过度了，虽然原文观点太偏激

FrankFang128

2016-07-18 09:04:56 +08:00

@Wangxf 你猜错了。。。

leeloto

2016-07-18 09:05:07 +08:00 via iPhone

加了个前端新手群，里面整天讨论 react,vue,angluar 什么的，然后他们找工作又不找特别指定这些技术的公司，我就无语了，不知道怎么想的

FrankFang128

2016-07-18 09:07:38 +08:00

@fuermosi777 有遇到什么弊端吗？觉得可以忍受吗？

fuermosi777

2016-07-18 09:25:06 +08:00

@FrankFang128 弊端就是对于简单的小项目搭建起来很麻烦。我用一年时间经过了你描述的全部过程，目前在生产环境上使用 React 和 Webpack 。对于规模较大的项目确实方便，少考虑很多事情。但如果临时搭建个小原型，花在搭环境上的时间就已经比实际写代码的时间还多了。除此之外并没有什么特别讨厌的地方。毕竟这就是需求所致，是历史的车轮滚滚向前...

Geeker

2016-07-18 09:27:34 +08:00

用 Makefile 吧

messense

2016-07-18 09:33:09 +08:00

@fuermosi777 所以一般都会有 starter-kit 嘛，用 Yeoman 之类的从 template 生成基本的项目结构。

crabRunning

2016-07-18 09:34:11 +08:00

不错这个很 js ，一日不见，已换三代～！

lijsh

2016-07-18 09:43:23 +08:00

项目开始配置一次，整个团队都能复用，哪里麻烦了？

repus911

2016-07-18 09:44:26 +08:00

不想用就别用然而阻碍不了 JS 的发展

muziyue

2016-07-18 09:45:22 +08:00

我觉得最苦逼是的后端，以前还会写点 jQuery ，现在根本改不了前端的代码了

nonoroazoro

2016-07-18 09:49:12 +08:00

对于会玩的人来说，轻松写意自动化，这些就是起飞的工具。对于不会玩的人来说，学习成本太高，这些就是累赘。

先进不先进，依赖不依赖也没那么重要，互联网领域喜欢玩新的不是一天两天的习惯了，你看看传统行业都怎么玩的。

所以有啥好吐槽的，爱用不用，路都是自己走出来的。

nonoroazoro

2016-07-18 09:52:14 +08:00

@fuermosi777 可能要先想办法把 webpack 的 config 理一理吧，然后做个基础模板（能启动的最小项目，包含各种配置）的自动化，加到 mac 或者 win 的右键菜单里，一键创建小型（测试）项目，不要太简单啊。

nonoroazoro

2016-07-18 09:53:05 +08:00

@leeloto 开拓视野，业余时间多玩玩一些所谓的新技术，没坏处。

killerv

2016-07-18 09:59:40 +08:00

@muziyue 我也是这么感觉，前端时间才发现，原来前端已经不是简单的 jquery Css 这些了，跟不上了……

gimp

2016-07-18 10:00:50 +08:00

再给三年沉淀，等前端稳定了再深入学习。

simpx

2016-07-18 10:14:32 +08:00

@muziyue 感同身受

后端几个月过去，最多多一个 feature 。前端几个月过去，语法都看不懂了

learnshare

2016-07-18 10:17:34 +08:00

@FrankFang128 我旁边的同事在写 React ，反正我看过之后我决定先不学。

不是这门技术不好，而是用的人没好好用。嗯，不清真。

shiye515

2016-07-18 10:27:52 +08:00

@FrankFang128 内存没闲着？

FrankFang128

2016-07-18 10:44:34 +08:00

@shiye515 我 4G 的 Air ，开 Chrome 经常用光内存

FrankFang128

2016-07-18 10:46:05 +08:00

@lijsh 等项目大了， build 一次等一分钟， watch 一次等两秒，就麻烦了

FrankFang128

2016-07-18 10:47:01 +08:00

@messense template 三个月后就得换了 😂

FrankFang128

2016-07-18 10:49:49 +08:00

@fuermosi777 调试方面不觉得麻烦吗？还有新人学习成本如何？还有一些 jQuery 的组件用不了了是不是都要重写？我的体会是隐性成本很多。我这里最大的成本就是，以前后端可以帮忙写页面，写在他看都不看全给我们前端了。少了很多人力！

zzNucker

2016-07-18 10:52:58 +08:00

@lxrmido 3 、学会这些，对一个熟悉前端的开发者来说，只要几十分钟；

我不信，学一个 webpack 都不止几十分钟，别说 es6+webpack+gulp 了，张口就来么。。。

zzNucker

2016-07-18 10:53:36 +08:00

就 webpack 那个烂文档。
话说其实我也觉得现在打包工具多的有点烂了。

FrankFang128

2016-07-18 10:55:44 +08:00

@simpx 后端几个月过去，最多多一个 feature 。前端几个月过去，语法都看不懂了
然后一个 feature 都没加，只是重构 😂

yolio2003

2016-07-18 10:55:46 +08:00

现实就是，有没有这些，写的都不优雅，有了这些，更不优雅了。。。

exoticknight

2016-07-18 10:59:13 +08:00

前端发展出这些东西的原因在于旧技术没有或者说很难应用上“软件工程”的思想
我刚开始做前端的时候，还是 jQuery 横行天下的时候，个人还是很喜欢的

不过 jQuery 太简单，随便学一学就会，应对复杂场景根本不行
作为对比，我实习时遇到过一个真实项目，原来是用普通 CSS 框架和 jQuery 以及基于 jQuery 的控件框架做的，只能在移动端上用
我用 vue + webpack 的开发方式重写了，加载文件体积平均减少了 50%，还能分开电脑端和移动端加载不同组件
开发过程完全不用管什么打包，压缩，拆分的事情，只需要用工程化的思想来写代码（还是爽爽的 ES2015

其实在远古的 jQuery 时代，也有很多人在想“不知道什么时候开始，前端开发已经到了不用 jQuery 的地步了。不依赖 jQuery ，还能优雅地写代码吗？”，所以楼主你看，历史不是简单的重复，但却有惊人的相似。
另外现在的浏览器对标准的支持度都很好了，写简单页面，连 jQuery 都可以不用，直接上原生 JavaScript 就很好（当然也因为 jQuery 越来越大了

拥抱新技术，岂不美哉？

100

FrankFang128

2016-07-18 11:06:54 +08:00

@exoticknight Vue 比 React 好的一点就是可以不用 JSX

1 2

❮

❯