我终于理解了这些前端构建工具,相信你也可以

版权申明:此文章无需授权即可转载,转载时请务必注明作者

题图

即便像我这样非常有经验的开发者,对于一些前端构建工具,也会产生疑惑。解决办法是在概念层面上理解它们是如何工作的,以及如何共同工作的。

这篇文章是我个人对于前端开发工具的理解,抛开代码层面,我们从理念层面来谈它们是如何完成它们的工作的。

不要对新技术产生恐惧

目前已经有太多的前端构建工具:Node, NPM, Grunt, Gulp, Bower, Webpack, Browserify, Yeoman, Brunch……很容易让人产生跟不上节奏的感觉。

关键点就是不要害怕,所有这些工具都是为了让你更高效而设计的。

要理解它们是什么,为什么用它们,怎么用它们,我们只需要理解以下几个概念。

概念#1——构建工具的核心作用“安装 vs.运行”

构建工具做两件事:

  1. 安装
  2. 运行

当你碰到一个新的工具,第一个问题应该是:“这个工具想要帮我安装还是运行?“

npm,Bower和Yeoman都属于”安装“工具,他们能把安装这件事做的很漂亮。他们可以安装前端库,例如Angular.js或React.js。它们可以在服务器上安装开发环境,它们可以安装测试库。他们甚至可以帮你安装其他的前端构建工具。

“什么是bower?”

”一个包管理器,用npm安装它。”

“什么是npm?”

“一个包管理器,你可以用brew安装它。”

“什么是brew?”…

——@ddprrt

简短的说,它们可以安装你可以想象的和代码相关的东西。

Grunt,Webpack,Require.js,Brunch和Gulp都是“运行”工具,它们比安装工具更复杂。它们的目标是自动化web开发中的体力活和容易出错的任务。运行的事情往往被称作“任务”。

为了执行这些“任务”,需要使用它们各自生态系统中的包和插件。每个工具执行任务的方式有差别,它们不会做相同的事情。有些“执行”工具试图做你抛给它的所有事情,其他的专注于一件事,例如解决Javascript依赖(例如Browserify, Require.js)

有时,在同一个项目中,可能会使用好几个这样的工具。

这里有一个被“执行”工具自动化的任务列表:

  1. 在文件中替换一个文本字符串
  2. 创建文件夹,并将文件移入
  3. 一键执行单元测试
  4. 保存文件时刷新浏览器
  5. 合并所有Javascript为一个文件,所有CSS文件为一个文件
  6. 最小化我的Javascript和CSS文件
  7. 在html页面中修改<script>标签的位置

当你理解了工具的安装功能和执行功能,对它们进行分类也变得非常容易:

分类

概念#2——Node和npm是所有构建工具的祖先

Node和npm可以安装和执行所有这些构建工具,所以你的项目会有迹可循。正因为这一点,大多数开发者在求助于其他工具前,都会尽可能的使用这两款工具。

Node和npm落到我们的二分归纳法中,Node是执行工具,而npm是安装工具。

npm可以安装像Angular.js或React.js之类的库。为了开发方便,它还可以安装一个服务器,从而在本地运行你的app。它甚至可以安装例如最小化你的代码的可执行工具。

另一方面,Node是”执行“工具,例如运行Javascript文件,服务器等等。

如果你刚开始学习,从Node+npm开始,并且多这两个工具上多花一些时间。当你的项目大到一定程度,你会遇到Node和npm自动化的限制,那时你再考虑使用其他的构建工具。

概念3——有一种构建意味着你的应用已经就绪

开发者经常把Javascript文件和CSS文件分成很多个文件,这样可以让我们写出模块化的代码,并且每个文件只完成一件事。一个文件只做一件事可以减少你的认知负载(如果你认为多个文件比起一个大文件来说会让你更困惑,试图在一个5000行的源文件上工作,我想你很快会改变你的想法的🙃)

但是,当你的产品发布后,太多文件不是一个好事情,当一个用户访问你的网站,你的每一个文件都需要使用一个额外的HTTP请求,这会使你的网站加载速度变慢。

作为补救,你可以为你的应用做一次“构建”,它会将所有CSS文件合并为一个文件,对于JavaScript文件也一样。结果是,你把文件大小和文件数最小化后,用户拿到的就是优化过的文件了,要这样做,你需要用一个构建工具。

下图是一个开发中的应用代码截图,注意到它拥有5个<script>标签和3个<link>标签,如果你注意到左边,你可以看到DEVELOPMENT文件夹下有10个文件

Your app in development

同时下图是相同的应用,只不过被构建工具施展了“魔法”。

注意到我们是怎么只有一个<script>标签和一个<link>标签的?和之前DEVELOPMENT下有10个文件比起来,现在只有4个文件。

应用每行都是一样的,只不过我们将其压缩到一个优雅的小包里,我们称之为“build”。

Your app in its build form

既然这样做仅仅只会节省用户几十毫秒的加载页面时间,你可能会想知道这样做到底值不值。可以这样说,如果你的网站只为少数一些人提供服务,你不需要关心这件事。构建工程仅仅只适用于大流量的网站(或者那些被认为即将成为大流量的网站😎)

如果你刚刚学编程,或网站流量较小,这样做将不是太有价值。

概念4——构建和运行的分界线比较模糊

没有一个工具是只做一件事且其他工具做其他的事,他们都会拥有构建和执行功能。但是大多数情况是,一个工具更趋向于构建或更趋向于执行。

一个“安装”工具有时也会执行程序,npm经常这样做,npm也可以执行命令和脚本——不仅仅是安装文件。一种工具,就像Yeoman,在你的机器上安装预编译引用的应用,同时它也会按需动态生成新文件,模糊了安装和执行间的这条分界线。

概念5——对于构建工具,没有唯一的组合

在项目中使用哪些构建工具,完全取决于你自己。

你可以选择不使用任何工具,仅仅记住复制,粘贴、最小化、开启服务、以及其它相关操作能够高效运作即可。

或者你仅仅只是用Node和npm来完成这些工作。对于初学者来说可以满足,但是当你的工程增长到一定程度,你可能会感觉到体力劳动越来越多。

这时你或许可以选择Node及npm上游的几个工具。所以你可以把Node和npm作为你自己的核心,也许还可以加上Grunt+Bower或Webpack或Gulp+Bower。

使用Node+npm上面的几种组合中的一种或几种,可以让你的工程中的大部分任务自动化,代价是学习这些工具的学习曲线很陡峭。

Build Tools in order of increasing complexity, but decreasing tediousness

概念6——构建工具的学习曲线很陡峭,所以只需学习什么是必须的

构建一个应用足够难,你可能会学习一门新语言或者一个新的框架,或者你有比较取巧的商业逻辑,而合并一个构建工具可能会把额外的一层错综复杂的事物加到你的项目中。问题就在于写构建工具相关的代码的人并不属于你的团队。

我的建议是只学习你需要在你工作中涉及到的部分,其他的不学。

最佳的学习新事物的办法是你有一个真实的任务去完成。例如,不要单纯理论学习Grunt怎么拷贝文件的。取而代之的是,直到你确切需要这样做的时候,再使用它来解决吧。

记住:早期就把问题复杂化将会让你变慢。

概念7——所有的构建工具拥有共同的目标:通过自动化所有体力劳动从而让你开心

当你发挥了你的构建工具的所有潜能,我把这种状态称作“构建工具涅磬”。这是一种当你保存一个文件,或运行一个命令,于是大量的任务便会自动执行的状态。

如果你的工具仍然需要你手动移动文件,改变值,或者运行命令才能编译,那么你还没有达到“工具涅磬”的状态。

拥有构建工具的好处便是保存一个文件,可以引发你的应用的编译,并发送到浏览器从而刷新新的内容。这会显著的加速你的前端开发工作流。

所以如何衡量你该付出多少努力在配置和设置构建工具上?很简单:只到它所做的事情让你高兴为止。

概念8——不只是你,很多人都觉得这些工具的文档很糟糕

事实上,很多这些工具的文档都不足,经常让我们做一些基本的任务都变得很难。

预先定义好的文档非常之少,你会看到很多不同的操作都导致同样的错误——在StackOverflow上经常看到回答的是同一个问题。

即便文档少这件事非常厌烦,但这些工具仍然可以增强你的代码技巧,并实现了很多创造性的事情。

总之,你现在知道我们会用这些工具了吧?

原文:https://medium.freecodecamp.com/making-sense-of-front-end-build-tools-3a1b3a87043b#.hpbycrwz3 作者:@roneesh 翻译:jieniu