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

原文：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 刷新一下就能看到效果！为什么我要花那么多时间来学习转译工具，以及解决转译过程中的各种问题。

总感觉『弊大于利』。甚至有的时候觉得这是『没有问题，创造问题也要上』。

最后送给前端们一幅图：

sunshinewu85

2016-07-18 14:05:24 +08:00

这篇文字写得挺有意义，也挺能激起技术嘴仗来着，只不过有些童鞋有点过敏，立马下一个“楼主对新技术无感、懒”的定论，只是讨论和反思嘛！我觉得前端圈能变成现在介个样纸，原因多少有这些：

1 、无法满足前端切图仔 “翻身农奴把歌唱” 日益蓬勃的「逼格感提升」这个迫切需求。（说白了，这年头，动不动就讲逼格，团队逼格，对！说得就是你！你这个 Zhuangbility 的前端， 2333333 ）

2 、一切的始作俑者或导火索，确实跟 Node.js 的出现分不开。突然让前端人对后端各种好模式\工程自动化构建\组件模块化开发等那种长久“咬牙切齿羡慕嫉妒恨又无处施展的抱负”有了一一实现的可能，更是凭借其朝着让 JS 走遍天下大一统的野心道路全速前进；

3 、 W3C 、 ES 等标准早期的无所作为，加上确实相对落后的前端工程化早期现状。不过这几年随着各方推动，整个标准的定制之路也随之快速全面完善起来，故前端的现有各种工具\库\组件在标准出台之后，可能会逐渐谢幕？现在的这些感觉都只会是过渡阶段产物~这些确实实实在在增加了重复学习各种工具的成本，也导致出现了新人望着名目繁多各种名词两眼一抹黑的窘境，那个内心无处安放呐~

4 、前端，不再是可有可无的岗位，这些的改变，形成了更多后端&专业前端之间的技术壁垒。（这或许是有些前端人希望看到的，专业事交给专业的人干，以往后端随便都能写几个页面的历史从此不再。。。所以，薪资，必须提上来，是吧）

5 、大中型项目良好的用户体验及敏捷开发团队的快速迭代需求所愿。（对待平常较小的商业项目，杀鸡用牛刀，确实没必要，需求决定技术选型及一切，毕竟开发成本还是要为公司考虑的。只不过开发者自个儿应抱有持续学习的心态，业余时间倒是有必要适当的“杀鸡用牛刀”整些新鲜的私人玩意儿，你说呢？）