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

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

最后送给前端们一幅图：

lovelypig5

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

个人觉得，工具都是为了项目服务的。
如果一个项目， 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 ，这仅仅是工具，最后还是要看人的选择

g0thic

2016-07-18 12:13:29 +08:00

@FrankFang128 原生 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 写单页面应用写的也很爽啊，这和语言这么否定自己有啥关系么。不过楼主要是因为自己不喜欢这一套但是团队又在用，觉得不爽吐槽一下是可以的