@ywxgod
感谢您,完成了第一篇翻译贡献 !
This commit is contained in:
Xingyu Wang 2021-05-25 11:22:27 +08:00
parent 0a3be179a6
commit 58c0c67e1a

View File

@ -1,18 +1,20 @@
[#]: collector: (lujun9972)
[#]: translator: (ywxgod)
[#]: reviewer: ( )
[#]: reviewer: (wxy)
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (6 predictions for JavaScript build tools)
[#]: via: (https://opensource.com/article/20/11/javascript-build-tools)
[#]: author: (Shedrack Akintayo https://opensource.com/users/shedrack-akintayo)
Javascript构建工具的6个预测
JavaScript 构建工具的 6 个预测
======
Javascript前端工具的生态系统充满着变数和竞争且只有最好的工具才会存活下来。
![Magnifying glass on code][1]
生产中的代码与开发中的有所不同. 在生产中,我们需要构建一些能运行得够快,能管理各种依赖关系,能自动执行任务,能加载外部模块等功能的包。而那些将开发中的代码转为生产代码的[javascript][2]工具我们就称之为 _构建工具。_
> JavaScript 前端工具的生态系统充满着变数和竞争,且只有最好的工具才会存活下来。
![](https://img.linux.net.cn/data/attachment/album/202105/25/112116d5z1lrywl6k25mur.jpg)
生产中使用的代码与开发中的有所不同. 在生产中,我们需要构建一些能运行得够快、能管理各种依赖关系、能自动执行任务、能加载外部模块等功能的包。而那些将开发中的代码转为生产代码的 [JavaScript][2] 工具我们就称之为 _构建工具。_
我们可以通过各个构建步骤以及其重要性来解释前端代码需要被“构建”的原因。
@ -20,90 +22,84 @@ Javascript前端工具的生态系统充满着变数和竞争且只有最好
前端代码的构建涉及下面的四个步骤:
#### 1\. 转译
通过转译,开发者可以使用到语言最新,最热门的更新和扩展,以及浏览器兼容性的处理维护等。 下面是使用[Babel][3]的一个例子:
#### 1、转译
通过<ruby>转译<rt>Transpiling</rt></ruby>,开发者可以使用到语言最新、最热门的更新和扩展,并保持浏览器的兼容性等。下面是使用 [Babel][3] 的一个例子:
```
// arrow function syntax in array map
const double = [1, 2, 3].map((num) =&gt; num * 2);
// after being transpiled
// 数组映射中的箭头函数语法
const double = [1, 2, 3].map((num) => num * 2);
// 转译后
const double = [1, 2, 3].map(function(num) {
  return num * 2;
return num * 2;
});
```
#### 2\. 分包
#### 2分包
分包是处理所有"import"与"require"语句的过程; 找到相匹配的JS代码片段包和库; 将它们添加到适当的域中; 然后将它们打包到一个JS文件中。常用的分包器包括Browserify, Webpack与Parcel。
<ruby>分包<rt>Bundling</rt></ruby>是处理所有 `import` 与`require` 语句的过程;找到相匹配的 JavaScript 代码片段、包和库;将它们添加到适当的域中;然后将它们打包到一个大的 JavaScript 文件中。常用的分包器包括 Browserify、Webpack 与 Parcel。
#### 3\. 压缩
压缩是通过删除空白和代码注释来减少最终的文件大小。在压缩过程中我们还可以更进一步添加代码混淆混淆会更改变量名和方法名使代码变得晦涩难懂因此一旦代码交付到客户端它就不是那么容易能让人读懂。下面是一个使用Grunt的例子:
#### 3、压缩
<ruby>压缩<rt>Minifing</rt></ruby>是通过删除空白和代码注释来减少最终的文件大小。在压缩过程中,我们还可以更进一步添加代码混淆步骤,混淆会更改变量名和方法名,使代码变得晦涩难懂,因此一旦代码交付到客户端,它就不是那么容易能让人读懂。下面是一个使用 Grunt 的例子:
```
// before minifying
const double = [1, 2, 3].map(function(num) {
  return num * 2;
});
// after minifying
// 压缩前
const double = [1, 2, 3].map(function(num) {
  return num * 2;
});
// 压缩后
const double=[1,2,3].map(function(num){return num*2;});
```
#### 4\. 打包
#### 4打包
完成上面的所有步骤之后, 我们需要将这些具有兼容性,且经过分包,压缩/混淆过的文件放置到某个地方。打包正是这样一个过程,它将上述步骤所产生的结果放置到开发者指定的某个位置上,这通常是通过打包器完成的。
完成上面的所有步骤之后, 我们需要将这些具有兼容性、且经过分包、压缩/混淆过的文件放置到某个地方。<ruby>打包<rt>Packaging</rt></ruby>正是这样一个过程,它将上述步骤所产生的结果放置到开发者指定的某个位置上,这通常是通过打包器完成的。
### 前端构建工具
前端工具及构建工具可以分为以下几类:
* 包管理: NPM, Yarn
* 转移器: Babel, etc.
* 打包器: Webpack, Parcel, Browserify
* 压缩混淆: UglifyJS, Packer, Minify, etc.
* 包管理: NPMYarn
* 转译器: Babel 等
* 打包器: Webpack、Parcel、Browserify
* 压缩混淆: UglifyJS、Packer、Minify 等
JavaScript 生态系统中有各种各样的构建工具可以使用,包括下面的这些:
#### Grunt 和 Bower
Javascript生态系统中有各种各样的构建工具可以使用包括下面的这些
[Grunt][4] 是作为命令行工具引入的,它仅提供一个脚本来指定和配置相关构建任务。[Bower][5] 作为包管理器,提供了一种客户端包的管理方法而紧追其后。这两者,再加上 NPM它们经常在一起使用它们看上去似乎可以满足大多数的自动化需求但 Grunt 的问题在于它无法提供给开发者配置更复杂任务的自由,而 Bower 使开发者管理的程序包是平常的两倍因为它将前端包、后台包分开了例如Bower 组件与 Node 模块)。
#### Grunt and Bower
**Grunt 与 Bower 的未来:** Grunt 与 Bower 正在退出 JavaScript 工具生态,但是还有一些替代品。
[Grunt][4] 作为一个命令行工具被引入,它仅提供一个脚本来指定和配置相关构建任务。[Bower][5] 作为包管理器提供了一种客户端包的管理方法而紧追其后。这两者再加上NPM它们经常被使用在一起它们看上去似乎可以满足大多数的自动化需求但Grunt的问题在于它无法提供给开发者配置更复杂任务的自由而Bower使开发者管理的程序包是平常的两倍因为它将前端包包、后台包分开了 (例如Bower components vs. Node modules)。
#### Gulp 和 Browserify
**Grunt与Bower的未来:** Grunt与Bower即将退出javascript工具生态但是还有一些替代品
[Gulp][6] 是在 Grunt 发布一年半之后才发布的。但 Gulp 却让大家感到很自然、舒服。用 JavaScript 来写构建脚本与用 JSON 来写相比更自由。你可以在 Gulp 的构建脚本中编写函数、即时创建变量、在任何地方使用条件语句 —— 但就这些,并不能说让我们的感觉变得特别自然和舒适,只能说这只是其中的一个可能的原因。[Browserify][7] 和 Gulp 可以配合使用Browserify 允许 NPM 包(用于后端 Node 服务器)被直接带入到前端,就这一点已经直接让 Bower 废了。而正是这种用一个包管理器来处理前后端包的方式让人感到更自然和更好
#### Gulp and Browserify
**Gulp 的未来:** Gulp 可能会被改进以便匹配当前流行的构建工具但这完全取决于创造者的意愿。Gulp 仍在使用中,只是不再像以前那么流行了。
[Gulp][6]是在Grunt发布后的一年半才发布的。但Gulp却让大家感到很自然、舒服。用javascript来写构建脚本与用JSON来写相比更自由。你可以在Gulp的构建脚本中编写函数即时创建变量在任何地方使用条件语句--但就这些,并不能说让我们的感觉变得特别自然和舒适,只能说这只是其中的,一个可能的原因。[Browserify][7]和Gulp可以配合使用Browserify允许NPM包(用于后端Node服务器)被直接带入到前端就这一点已经直接让Bower废了。而正是这种用一个包管理器来处理前后台包的方式让人感到更自然和更好。
#### Webpack 和 NPM/Yarn 脚本
**Gulp的未来:** Gulp可能会被改进以便匹配当前流行的构建工具但这完全取决于创作者的意愿。Gulp还在使用中只是不再有以前那么流行了
[Webpack][8] 是现代前端开发工具中最热门的宠儿,它是一个开源的 JavaScript 模块打包器。Webpack 主要是为处理 JavaScript 而创造的,但如果包含相应的加载器,它也可以转换 HTML、CSS 和图片等前端资源。通过 Webpack你也可以像 Gulp 一样编写构建脚本,并通过 [NPM/Yarn][9] 来执行它们
#### Webpack and NPM/Yarn scripts
[Webpack][8]是现代前端开发工具中最热门的宠儿它是一个开源的javascript模块打包器。Webpack主要是为处理javascript而创作的但它如果包含相应的loaders它也可以转换HTML、CSS和图片等前端资源。通过Webpack你也可以像Gulp一样编写构建脚本并通过[NPM/Yarn][9]来执行这些脚本。
**Webpack的未来:** Webpack是目前Javascript工具生态系统中最热门的工具最近几乎所有的JS库都在使用React和Webpack。Webpack目前处于第四个版本不会很快消失。译者注webpack目前已经发布了第五个版本了且还在火热更新中
**Webpack 的未来:** Webpack 是目前 JavaScript 工具生态系统中最热门的工具,最近几乎所有的 JavaScript 库都在使用 React 和 Webpack。Webpack 目前处于第四个版本不会很快消失。LCTT 译注Webpack 目前已经发布了第五个版本了,且还在火热更新中)
#### Parcel
[Parcel][10]是一个web应用打包器于2018年推出因其有着不同的开发者体验而与众不同。Parcel能利用处理器多核功能提供极快的打包性能且还零配置。但Parcel还是一个新星对于一些大型应用其采用率并不高。与Webpack相比开发人员更喜欢使用Webpack因为Webpack有更广泛的支持和可定制性。
[Parcel][10] 是一个 Web 应用打包器,于 2018 年推出因其开发者体验而与众不同。Parcel 能利用处理器多核功能提供极快的打包性能,且还零配置。但 Parcel 还是一个新星,对于一些大型应用,其采用率并不高。相比之下,开发人员更喜欢使用 Webpack因为 Webpack 有更广泛的支持和可定制性。
**Parcel的未来:** Parcel非常容易使用如果你统计打包和构建时间它会比Webpack更快而且它还提供了更好的开发者体验。Parcel没有被大量采用的原因可能是它仍然比较新。在前端构建工具的生态系统中Parcel的前景会非常光明它将会存在一段时间。
**Parcel 的未来:** Parcel 非常容易使用,如果你统计打包和构建时间,它会比 Webpack 更快而且它还提供了更好的开发者体验。Parcel 没有被大量采用的原因可能是它仍然比较新。在前端构建工具的生态系统中Parcel 的前景会非常光明,它将会存在一段时间。
#### Rollup
[Rollup][11]是Javascript的一个模块分包器它可将一小段代码编译为更大更复杂的库或应用。Rollup一般建议用来构建JS库特别是那种导入和依赖的第三方库较少的那种JS库。
[Rollup][11] 是 JavaScript 的一个模块分包器它可将一小段代码编译为更大更复杂的库或应用。Rollup 一般建议用来构建 JavaScript 库,特别是那种导入和依赖的第三方库较少的那种库。
**Rollup的未来:** Rollup很酷,且正在被迅速采用。它有很多强大的功能,将在很长一段时间内作为前端工具生态系统的一个组成部分而存在。
**Rollup 的未来:** Rollup 很酷,且正在被迅速采用。它有很多强大的功能,将在很长一段时间内作为前端工具生态系统的一个组成部分而存在。
### 了解更多
Javascript前端工具的生态系统充满着变数和竞争,且只有最好的工具才能存活下来。 在不久的将来,我们的构建工具将具有更少(或没有)的配置,更方便的定制化,更好的扩展性的和更好的构建速度。
JavaScript 前端工具的生态系统充满着变数和竞争,且只有最好的工具才能存活下来。在不久的将来,我们的构建工具将具有更少(或没有)的配置,更方便的定制化,更好的扩展性的和更好的构建速度。
该用什么样的构建工具用于你的前端项目,你需要根据具体的项目需求来做出决定。至于选择什么样的工具,才是最合适自己的,大多数时候,需要我们自己作出取舍。
@ -114,11 +110,9 @@ Javascript前端工具的生态系统充满着变数和竞争且只有最好
* [Modern frontend: The tools and build process explained][14]
* [Best build tools in frontend development][15]
* * *
_这篇文章最初发表在[Shedrack Akintayo的博客][16]上,经他许可后重新发表在这里._
_这篇文章最初发表在 [Shedrack Akintayo 的博客][16] 上,经许可后重新发表。_
--------------------------------------------------------------------------------
@ -127,7 +121,7 @@ via: https://opensource.com/article/20/11/javascript-build-tools
作者:[Shedrack Akintayo][a]
选题:[lujun9972][b]
译者:[ywxgod](https://github.com/ywxgod)
校对:[校对者ID](https://github.com/校对者ID)
校对:[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出