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

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

最后送给前端们一幅图：