From f03087356ca2c189fd41e44f867ccd7c51af1f32 Mon Sep 17 00:00:00 2001 From: wyin Date: Sun, 23 May 2021 01:01:47 +0800 Subject: [PATCH] =?UTF-8?q?=E7=BF=BB=E8=AF=91=E4=B8=AD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ... predictions for JavaScript build tools.md | 57 +++++++++---------- 1 file changed, 28 insertions(+), 29 deletions(-) diff --git a/sources/tech/20201123 6 predictions for JavaScript build tools.md b/sources/tech/20201123 6 predictions for JavaScript build tools.md index 2a9b746b50..feae75f16b 100644 --- a/sources/tech/20201123 6 predictions for JavaScript build tools.md +++ b/sources/tech/20201123 6 predictions for JavaScript build tools.md @@ -7,23 +7,22 @@ [#]: via: (https://opensource.com/article/20/11/javascript-build-tools) [#]: author: (Shedrack Akintayo https://opensource.com/users/shedrack-akintayo) -6 predictions for JavaScript build tools +Javascript构建工具的6个预测 ====== -The JavaScript frontend tooling ecosystem is dynamic and competitive, -and only the best survive. +Javascript前端工具的生态系统充满着变数和竞争，且只有最好的工具才会存活下来。 ![Magnifying glass on code][1] -Code used in production is different from development code. In production, you need to build packages that run fast, manage dependencies, automate tasks, load external modules, and more. [JavaScript][2] tools that make it possible to turn development code into production code are called _build tools._ +生产中的代码与开发中的有所不同. 在生产中，我们需要构建一些能运行得够快，能管理各种依赖关系，能自动执行任务，能加载外部模块等功能的包。而那些将开发中的代码转为生产代码的[javascript][2]工具我们就称之为 _构建工具。_ -The reason frontend code is "built" can be explained by looking into the various build steps and their importance. +我们可以通过各个构建步骤以及其重要性来解释前端代码需要被“构建”的原因。 -### Steps in building frontend code +### 前端代码构建步骤 -There are four steps involved in building frontend code: +前端代码的构建涉及下面的四个步骤: -#### 1\. Transpiling +#### 1\. 转译 -Transpiling lets developers take advantage of the newest, hottest updates to languages and extensions and maintain browser compatibility. Here is an example using [Babel][3]: +通过转译，开发者可以使用到语言最新，最热门的更新和扩展，以及浏览器兼容性的维护等。 这是使用[Babel][3]的一个例子: ``` @@ -35,13 +34,13 @@ const double = [1, 2, 3].map(function(num) { }); ``` -#### 2\. Bundling +#### 2\. 分包 -Bundling is the process of taking all the "import" or "require" statements; finding the matching JavaScript snippets, packages, and libraries; adding them to the appropriate scope; and packaging it all into one big JavaScript file. Commonly used bundlers include Browserify, Webpack, and Parcel. +分包是处理所有"import"与"require"语句的过程; 找到相匹配的JS代码片段，包和库; 将它们添加到适当的域中; 然后将它们打包到一个JS文件中. 常用的分包器包括 Browserify, Webpack, and Parcel. -#### 3\. Minifing +#### 3\. 压缩 -Minifying reduces the final file size by removing white space and code comments. You can take this a step further by adding an obfuscate step, which changes variable names and method names, obscuring the code, so it is less human-readable once it's delivered to the client. Here is an example using Grunt: +压缩是通过删除空白和代码注释来减少最终的文件大小。在压缩过程中，我们还可以更进一步添加代码混淆，混淆会更改变量名和方法名，使代码变得晦涩难懂，因此一旦代码交付到客户端，它就不是那么容易能让人读懂。下面是一个使用Grunt的例子: ``` @@ -55,44 +54,44 @@ const double = [1, 2, 3].map(function(num) { }); ``` -#### 4\. Packaging +#### 4\. 打包 -After all the steps above are finished, the compatible, bundled, minified/obfuscated file must be put somewhere. Packaging is the process of putting the results of the above steps somewhere specified by the developer. This is usually done by the bundler. +完成上面的所有步骤之后, 我们需要将这些具有兼容性，且经过分包，压缩/混淆过的文件放置到某个地方。打包正是这样一个过程，它将上述步骤所产生的结果放置到开发者指定的某个位置上。这通常是通过分包器完成的. -### Frontend build tools +### 前端构建工具 -Frontend tooling and build tools can be split into the following categories: +前端工具及构建工具可以分为以下几类: - * Package managers: NPM, Yarn - * Transpilers: Babel, etc. - * Bundlers: Webpack, Parcel, Browserify - * Minifiers: UglifyJS, Packer, Minify, etc. + * 包管理: NPM, Yarn + * 转移器: Babel, etc. + * 打包器: Webpack, Parcel, Browserify + * 压缩混淆: UglifyJS, Packer, Minify, etc. -There are a variety of build tools you can use in the JavaScript ecosystem, including the following. +Javascript生态系统中有各种各样的构建工具可以使用，包括下面的这些： #### Grunt and Bower -[Grunt][4] was introduced as a command-line tool that provided just one script to specify and configure tasks. [Bower][5] followed shortly after as a way to manage client-side packages. The two, along with NPM, seemed to fulfill the majority of automation needs and were used regularly together. The problem with Grunt was that it didn't provide developers the freedom to configure more complex task chains, while Bower made developers manage twice as many packages as usual because it separates frontend and backend packages (i.e., Bower components vs. Node modules). +[Grunt][4] 作为一个命令行工具被引入，它仅提供一个脚本来指定和配置相关构建任务。[Bower][5] 作为包管理器，提供一种客户端包的管理方法而紧追其后。这两者，再加上NPM，它们经常被使用在一起，它们似乎可以满足大多数的自动化需求。Grunt的问题在于它无法提供给开发者配置更复杂任务的自由，而Bower使开发者管理的程序包是平常的两倍，因为它将前端包后后台包分开了 (例如，Bower components vs. Node modules)。 -**The future of Grunt and Bower:** Grunt and Bower are on their way out of the JavaScript tooling ecosystem, but there are several replacements. +**Grunt与Bower的未来:** Grunt与Bower即将退出javascript工具生态，但是还有一些替代品。 #### Gulp and Browserify -[Gulp][6] was released a year and a half after Grunt. It felt natural. Writing a build script in JavaScript compared to JSON gave freedom. You could write functions, create variables on the fly, use conditionals anywhere—not that this would make for a particularly good-looking build script, but it was possible. [Browserify][7] and Gulp can be used in tandem. Browserify allows NPM packages (which are for backend Node servers) to be brought into the frontend, making Bower obsolete. It also looks and feels better, with one package manager for the frontend and backend. +[Gulp][6]是在Grunt发布后的一年半才发布的。然而Gulp让大家感觉很自然、舒服。用javascript来写构建脚本与用JSON来写相比更自由。你可以Gulp的构建脚本中编写函数，即时创建变量，在任何地方使用条件语句--但就这些，并不能说让我们的脚本变得特别自然和强大，只能说有这个可能。[Browserify][7]和Gulp可以配合使用。Browserify允许NPM包(用于后端Node服务器)被直接带入到前端，这直接让Bower废了。而这种用一个包管理器来处理前端后后台包的方式让人感到更好和更自然。 -**The future of Gulp:** Gulp can be improved to match the current popular build tools, but this is entirely up to the creators. It is still in use but not as popular as it was before. +**Gulp的未来:** Gulp可能会被改进，以匹配当前流行的构建工具，但这完全取决于创作者的意愿。Gulp还在使用中，只是没有以前那么流行了。 #### Webpack and NPM/Yarn scripts -[Webpack][8] is the hottest kid on the block in modern frontend development tooling. Webpack is an open-source JavaScript module bundler. It is made primarily for JavaScript, but it can transform frontend assets like HTML, CSS, and images if the corresponding loaders are included. With Webpack, you can also write scripts like Gulp and execute them with [NPM/Yarn][9]. +[Webpack][8]是现代前端开发工具中最热门的宠儿。Webpack是一个开源的javascript模块打包器. 它主要是为处理javascript而创作的，但如果包含相应的loaders，它也可以转换HTML、CSS和图片等前端资源。通过Webpack，你也可以像Gulp一样编写构建脚本，并通过[NPM/Yarn][9]来执行这些脚本. -**The future of Webpack:** Webpack is currently the hottest thing in the JavaScript tooling ecosystem, and all the JS cool kids are using React and Webpack these days. It is currently in version 4 and not going anywhere anytime soon. +**Webpack的未来:** Webpack是目前Javascript工具生态系统中最热门的工具，最近几乎所有的JS库都在使用React和Webpack. Webpack目前处于第四个版本，不会很快消失。（译者注：webpack目前已经发布了第五个版本了，且还在火热更新中） #### Parcel -[Parcel][10] is a web application bundler that launched in 2018 and is differentiated by its developer experience. It offers blazing-fast performance utilizing multicore processing and requires zero configuration. Parcel is also a new kid on the block, but adoption hasn't been fast, especially for large applications. Developers prefer to use Webpack over Parcel because of the former's extensive support and customizability. +[Parcel][10]是一个web应用打包器，于2018年推出，因其开发者不同的体验而与众不同。Parcel能利用多核功能提供极快的性能，且还零配置。Parcel还是一个新星，其采用率并不高，特别是对于一些大型应用。与Webpack相比，开发人员更喜欢使用Webpack，因为Webpack有更广泛的支持和可定制性。 **The future of Parcel:** Parcel is very easy to use, it is faster than Webpack if you measure bundle and build time, and it also offers a better developer experience. The reason Parcel hasn't been adopted much might be because it's still relatively new. Parcel has a very bright future in the frontend build tools ecosystem, and it will be around for a while.