原文: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 。
同时期, 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 任务的初衷到底是什么?是否解决了问题。
从目前的结果来看,基本可以总结为
基本把能抛弃的都抛弃了。
实际上这些变化非常适合复杂的 Web 应用,然而 90% 的页面根本不是单页面应用好吗!
能不能让我写一个 CSS 一个 JS 刷新一下就能看到效果!为什么我要花那么多时间来学习转译工具,以及解决转译过程中的各种问题。
总感觉『弊大于利』。甚至有的时候觉得这是『没有问题,创造问题也要上』。
最后送给前端们一幅图:
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.