🥳 欢送有趣味的小伙伴,一起做点有意义的事!
我发动了一个 周刊翻译打算,仓库地址,拜访地址
当初还很缺气味相投的小伙伴,纯属个人兴趣,当然对于晋升英语和前端技能也会有帮忙,要求:英语不要差的离谱、github 纯熟应用、有恒心、虚心、对本人做的事负责。
想参加的小伙伴,能够 wx 私信,也能够给仓库发 issue 留言,我博客也有具体的集体联系方式:daodaolee.cn
在过来的一年里,一系列新的开发工具拔地而起,包含但不限于 webpack、Babel、Rollup、Parcel、create-react-app 等,在前端开发配合这方面也很敌对。这些新的工具指标和性能上各有千秋,每个工具都有不同的指标和性能,但都有一个独特的指标:进步开发人员的应用体验。
其实,其实我想对他们每一个都评估一下,概述一下他们做了什么,咱们为什么须要他们,以及他们的用例。然而起初我意识到了这样的比拟总会有点不偏心。比方,Snowpack 和 Vite 大多会在后盾应用 esbuild 来实现某些工作。咱们应该更多更好地理解当下的工作状况,才能够在咱们须要它们的时候抉择最合适的。
当然,对于这些新的构建工具,曾经有了一大堆文章来介绍它们,这里我举荐几集 ShopTalk Show 网站的资源供大家学习:454-Vite、448-wmr 和 Snowpack 的作者。
为什么会产生这么多的工具?
在某种程度上,我认为这些工具的产生起因是因为 JavaScript 工具有时候很不不便——这篇对于早在 2016 年学习 JavaScript 的文章提出了一些痛点。
Snowpack、Vite 和 wmr 都是用浏览器中的原生 JavaScript Modules 写的。早在 2018 年,Firefox 60 就默认启用了 ECMAScript 2015 模块。从那时起,所有次要的浏览器引擎都反对原生 JavaScript Modules。Node.js 还在 2019 年 11 月公布了原生 JavaScript Modules。到当初,咱们也仍在摸索 JavaScript Modules 更多的个性。
这些与现有的工具有何不同?
无论咱们应用 webpack、Rollup 还是 Parcel 当做开发环境的服务,这些工具都会将咱们的整个代码库从咱们的源代码和一个 node_modules 文件夹中打包,通过构建过程运行一些代码(像 Babel、TypeScript 或 PostCSS),而后将打包后的代码放到咱们的浏览器上运行。提到的这些工作咱们都须要去做,如果代码量大的话,就算退出缓存和优化策略。
Snowpack、Vite 和 wmr 服务却不这么做。相同,它们会等到浏览器找到 import 语句并对 modules 收回 HTTP 申请。只有在收回此申请后,这些工具才会将转换 所申请的模块 和 import module tree
中的任何子节点,而后将它们提供给浏览器。。这样速度会很快,因为在推送到开发环境服务的过程中工作量缩小了。
做一个简略的总结
首先它们都反对以下开箱即用的性能(在不同水平上):
- 反对原生 JavaScript modules
- 都能够用 TypeScript 编译
- 反对 JSX
- 都有可扩展性的插件 API
- 都内置了开发环境的服务
- 反对 CSS bundle 和 CSS-in-JS 库
这些工具都能够将 TypeScript 编译成 JavaScript,即便存在类型谬误也会这样做。如果须要正确的类型查看,您须要装置 TypeScript 并在根 JavaScript 文件上运行 tsc –noEmit,或者应用编辑器插件来监督类型谬误。
上面来这些工具逐个剖析吧!
esbuild
esbuild 由 Evan Wallace(Figma 的 CTO)创立。它的次要特点是它提供的构建步骤比基于 Node 的打包器快 10 倍 -100 倍(依据它们本人的基准)。只管它没有提供相似 create-react-app 包的依赖反对,然而有越来越多的 esbuild 使用者做了这些事件,包含但不限于 create-react-app-esbuild、estrella 和 Snowpack。
esbuild 出世的工夫比拟晚。它还没有达到 1.0 版本,目前还没有齐全筹备好投入生产应用 — 但也不远了。
应用场景
esbuild 是打包器中的一个新的创始者。在 esbuild 和 node bundlers 之间的速度差别成倍增加的大型代码库中,它的特点特地显著。当 esbuild 版本到 1.0 时,它就能够在大型生产环境中大显神通,并为团队节俭大量期待构建实现的工夫。
设置
我想用命令行的形式在 esbuild 中启动一个 React 我的项目:npm 装置 esbuild、React 和 ReactDOM。我创立了一个 src/app.jsx
文件和一个 dist/index.html
文件。而后,我应用以下命令将应用程序编译成一个 dist/bundle.js
文件:
./node_modules/.bin/esbuild src/app.jsx --bundle --platform=browser --outfile=dist/bundle.js
当我在浏览器关上 index.html 时,白屏了,并且报了一个错:“Uncaught ReferenceError: process is not defined”。这就是不认真看文档会引发的问题,它在构建 React 时须要一个额定的参数:
--define:process.env.NODE_ENV=\"production\"
或者,也能够加本义符号:
--define:process.env.NODE_ENV=\\\"production\\\"
对于须要环境变量参数的库,都须要此定义参数。Vue 2.0 当然也须要,Preact 则不须要。
用法
esbuild 为开发环境服务提供了 --serve
选项。该配置绕过了文件系统并间接从内存中提供模块,确保浏览器不会拉取旧版本的模块。然而,它不包含实时 / 热从新加载。这时候咱们能够用一下 servor 这个包来保留咱们的更改:
npm install servor --save-dev
而后咱们能够应用 esbuild Javascript API 作为服务器启动,同时运行 esbuild 的 watch 模式。在我的项目的根目录创立一个名为 watch.js 的文件:
// watch.js
const esbuild = require("esbuild");
const servor = require("servor");
esbuild.build({
// 这里配置 esbuild
entryPoints: ["src/app.jsx"],
outdir: "dist",
define: {"process.env.NODE_ENV": '"production"'},
watch: true,
});
async function serve(){console.log("running server from: http://localhost:8080/");
await servor({
// 这里配置服务器
browser:true,
root: "dist",
port: 8080,
});
}
serve();
当初在命令行中运行 node watch.js。目前为止,能够看到咱们的改变,然而它不会为咱们提供热模块替换或疾速刷新(即不会保留您的客户端状态)。
如果你须要一个带有实时从新加载和一些 React 默认值的预配置版本的 esbuild,能够看下这个仓库。
反对的文件类型
esbuild 能够在 JavaScript 中导入 CSS。它会把 CSS 编译到和次要输入 JavaScript 文件同名的目录下。默认状况下,它还能够捆绑 CSS @import 语句,不过目前不反对 CSS Modules。
当初,esbuild 的插件越来越多了,比方 Vue SFC 插件和 Svelte 组件插件。
它还能够在 JavaScript 中导入图片,能够把它们转换为 URL 或将它们复制到输入文件夹中。默认状况下不启用改性能,但能够在 esbuild 配置中增加以下内容来启用任一选项:
loader: {'.png': 'dataurl'} // Converts to data url in JS bundle
loader: {'.png': 'file'} // Copies to output folder
代码拆分是一项正在减少的性能,个别会以 ESM 格局输入。还有就是,esbuild 默认内置了 tree-shaking,并且无奈敞开。
生产环境
在 esbuild 命令中应用“minify”和“bundle”配置不会创立相似于 Rollup/Terser 那种小的 bundle。这是因为 esbuild 就义了一些包的大小优化。不过这些能够忽略不计。
总结
esbuild | |
---|---|
反对多个前端框架模板配置 | ❌ |
反对热更新 / 替换开发环境服务 | ❌ |
流式引入 | ❌ |
生产环境预配置 | ❌ |
主动 PostCSS 和预处理器转换 | ❌ |
HTML 转换 | ❌ |
反对 Rollup | ❌ |
大小 | 7.34 MB |
Snowpack
Snowpack 是 Skypack 和 Pika 的创建者的构建工具。它提供了一个很棒的开发环境服务,并以“非捆绑开发”理念创立。援用文档里的一句话:“你应用打包器是因为你想,而不是因为你须要。”
默认状况下,Snowpack 的构建步骤不会将文件捆绑到单个包中,而是提供在浏览器中运行的未捆绑的 esmodules。esbuild 实际上是其中的作为依赖项,但它的想法是应用 JavaScript 模块,并且仅在须要时与 esbuild 捆绑。
Snowpack 有很棒的文档,外面也包含了它与 JavaScript 框架一起应用的指南,以及一堆模板。看起来 Snowpack 将 Svelte 视为一等公民。实际上,我是从 Rich Harris 在 2020 年 Svelte 峰会上的“将来 Web 开发”演讲中第一次据说 Snowpack。也就是说,行将推出的 SvelteKit 框架 原本是由 Snowpack 提供反对的,但起初还是改用了 Vite。
应用场景
如果您喜爱非捆绑式部署,Snowpack 是一个不错的抉择。
其次,我认为 Snowpack 是 esbuild 的一个很好的封装。如果您想尝试 esbuild,但又想要一个开发环境的服务和为前端框架预编译的模板,那么抉择 Snowpack 不会出错。
就目前的状况而言,我认为 Snowpack 不是像 create-react-app 这样的零配置工具的最佳替代品。
设置
从命令行装置:
mkdir snowpackproject
cd snowpackproject
npm init #fill with defaults
npm install snowpack
接着,在 package.json 中退出以下配置:
// package.json
"scripts": {
"start": "snowpack dev",
"build": "snowpack build"
},
再创立一个配置文件:
// Mac or Linux
touch snowpack.config.js
// Windows
new-item snowpack.config.js
将其粘贴到配置文件中:
// snowpack.config.js
module.exports = {
packageOptions: {"source": "remote",}
};
Source:近程启用流式导入。流式导入能够跳过 npm,间接进行 cdn 导入。
接下来,创立一个 index.html:
<!--index.html-->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">>
<title>Snowpack streaming imports</title>
</head>
<body>
<div id="root"></div>
<!-- Note the type="module". This is important for JavaScript module imports. -->
<script type="module" src="app.js"></script>
</body>
</html>
最初,咱们将增加一个 app.jsx 文件:
// app.jsx
import React from 'react'
import ReactDOM from 'react-dom'
const App = ()=>{return <h1>Welcome to Snowpack streaming imports!</h1>}
ReactDOM.render(<App />,document.getElementById('root')); 0
请留神,咱们没有在任何阶段 npm install React 或 ReactDOM。而后咱们启动以下 Snowpack 开发环境服务:
./node_modules/.bin/snowpack dev
咱们的程序依然能够跑!
Snowpack 不是从 node_modules 文件夹中提取 npm 包,而是从 Skypack 中提取 npm 包,这是一个托管 npm 注册表的 CDN,并且它已事后优化为在浏览器中工作。而后,Snowpack 在 ./_snowpack/pkg URL
中提供它。
用法
这和基于 Node/npm 的工作流程差异很大。实际上咱们看到的是一个新的基于 CDN/JavaScript 模块的工作流。
然而,如果咱们按原样运行咱们的应用程序并打包,Snowpack 会抛出谬误。这是因为它须要晓得在构建时应用哪个版本的 React 和 ReactDOM。这种状况下,能够通过运行以下命令来主动创立 snowpack.deps.json
,从而解决问题:
./node_modules/.bin/snowpack add react
./node_modules/.bin/snowpack add react-dom
这样不会从 npm 下载包,只会记录用于 Snowpack 构建的包的版本。
即便咱们不应用流式导入,Snowpack 开发环境服务也会将 node_modules 中的每个依赖关系捆绑成一个 JavaScript 文件,将这些文件转换为一个本地 JavaScript 模块,而后将其提供给浏览器。这意味着浏览器能够缓存这些脚本,只有在它们发生变化时才从新申请它们。开发环境服务在保留时主动刷新,但并不保留客户端的状态。所有来自节点的依赖仿佛都能开箱即用~。
在 React 中保留客户端状态须要 react-refresh,它须要一些本人的 Babel 依赖包,这还不算自身的默认配置项。这时候能够应用更弱小的 React 模板。该模板引入了 react-refresh、Prettier、Chai 和 React 测试库,总共有 80 MB 的 Node 依赖包:
npx create-snowpack-app my-react-project --template @snowpack/app-template-react
反对的文件类型
反对 JSX,但同样,默认状况下仅反对 .jsx 文件。Snowpack 会自动检测是应用 React 还是 Preact,并相应地决定应用哪个渲染函数进行 JSX 转换。然而,如果咱们想进一步定制 JSX,咱们须要通过他们的插件引入 Babel。还有一个 Snowpack 插件可用于 Vue 单文件组件,当然也可用于 Svelte 组件。此外,Snowpack 能够编译 TypeScript,但因为类型查看,咱们也须要 TypeScript 插件。
CSS 能够导入到 JavaScript 中,并在运行时放入文档 <head>
中。也反对 .module.css
为扩展名的 CSS 模块的开箱即用般体验。
导入的 JSON 文件将被转换为 JavaScript module,并将对象默认导出。Snowpack 会把图片复制到生产环境的文件夹中。依据其非捆绑式理念,Snowpack 不会将图片作为 URL 蕴含在捆绑包中。
生产环境
默认的 snowpack build
命令会将源文件构造复制到输入文件夹中。对于编译为 JavaScript 的文件(例如 TypeScript、JSX、JSON、.vue、.svelte),它会将每个独自的文件转换为 JavaScript module。
能够看进去这对生产环境不太敌对,因为如果源代码被分成很多文件,它就会导致大量的申请。
然而,Snowpack 将 esbuild 作为依赖项,咱们能够在 Snowpack 配置里增加“优化”参数来启用 esbuild,从而捆绑、压缩和编译代码:
// snowpack.config.js
module.exports = {
optimize: {
bundle: true,
minify: true,
target: 'es2018',
},
};
这样会应用 esbuild 提供的优化性能,咱们就能够取得与之前应用 esbuild 雷同的构建。
因为 esbuild 还没有达到 1.0,Snowpack 倡议应用 webpack 或 Rollup 插件进行生产构建,两者都须要配置。
总结
Snowpack 目前有功能齐全的开发环境服务、具体的文档和易于上手的模板。
Snowpack | |
---|---|
反对多个前端框架模板配置 | ✅ |
反对热更新 / 替换开发环境服务 | ✅ |
流式引入 | ✅ |
生产环境预配置 | ❌ |
主动 PostCSS 和预处理器转换 | ❌ |
HTML 转换 | ❌ |
反对 Rollup | ✅ |
大小 | 16 MB |
Vite
<img src=”https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/08d288a9ab324616a31c1f448a761d21~tplv-k3u1fbpfcp-zoom-1.image” style=”width: 20%”>
Vite 由 Evan You 开发。esbuild 专一于构建步骤,Snowpack 专一于开发环境服务,Vite 把两者都蕴含了:残缺的开发环境服务和应用 Rollup 的优化构建命令。
应用场景
如果你想找一个 create-react-app 或 Vue CLI 的竞争对手,Vite 是最靠近的一个,因为它具备欠缺的性能。闪电般疾速的开发环境服务和零配置生产构建意味着您能够在没有任何配置的状况下应用。Vite 任何大型的单页应用程序都很敌对。
如果你想要零配置的服务器端渲染框架,你最好应用 webpack 的框架,比方 Nuxt.js 和 Next.js,等 Vite 服务器端渲染局部再欠缺一下之后再应用。
设置
Vite 比 esbuild 和 Snowpack 有更多特定的默认设置。它的文档也很敌对,Vite 能够与任何前端框架一起应用,甚至提供了一个模板列表来帮忙您入门。
用法
Vite 的开发环境服务十分弱小。Vite 应用 esbuild 将我的项目的所有依赖项事后捆绑到单个原生 JavaScript 模块中,而后应用缓存的 HTTP 标头为其提供服务。这意味着在第一次编译之后不会节约更多的工夫再提供或申请导入的依赖项上。Vite 还提供清晰的谬误音讯,打印确切的代码块和行号以进行故障排除。
Vite 的 React 和 Vue 模板都引入了反对热模块替换的插件。Vue 模板插件提供了为单文件组件和 JSX 插件。React 模板引入了 react-refresh 插件。无论哪种形式,两者都会为您提供热模块替换和客户端状态保留。当然,他们也有更多依赖项,包含 Babel 包等,然而,在 Vite 中应用 JSX 时实际上不须要 Babel。默认状况下,JSX 的工作形式与 esbuild 雷同—— 它会转换为 React.createElement
。
Vite 不反对像 Snowpack 和 wmr 那样的流式导入,所以只能像平常一样 npm 装置依赖项应用。
Vite 正在做对服务器端渲染的试验性功能,抉择框架并生成间接发送到客户端的动态 HTML。Evan You 曾经有一项名为 VitePress 的工作正在进行中,它是 VuePress 的替代品,也有应用 Vite 的长处。并且 Sveltekit 也将 Vite 增加到其依赖项列表中。这样看起来,CSS 代码拆分的起因可能和 Sveltekit 转向 Vite 无关。
反对的文件类型
对于 CSS,Vite 反对捆绑 CSS 导入以及 CSS modules。咱们也能够用 npm install PostCSS
插件来创立一个 postcss.config.js
文件,Vite 会主动将这些转换利用到 CSS。
Vite 也反对 CSS 预处理器 — 只需 npm install
预处理器并将文件重命名为正确的扩展名即可(例如 .filename.scss)。
图片导入默认为公共 URL,但咱们也能够通过在 URL 字符串开端应用 ?raw
参数将它们作为字符串加载到包中。
JSON 文件能够导入并转换为导出单个对象的 esmodule。也能够提供一个命名的导入,Vite 将在 JSON 文件的根字段中查找导入并 treeshake 其余部分。
生产环境
Vite 应用 Rollup 进行预配置的生产构建,并进行了一系列优化。它专门提供了一个零配置构建,这对于大多数用例来说应该足够了。
该构建性能也携带了冀望的 Rollup 具备的性能:捆绑、压缩 和 tree shaking。除此之外也有别的货色,比方代码宰割、动静导入和异步 chunk 加载,这个很有意思,如果咱们申请一个导入另一个模块的 JavaScript 模块,将会异步构建它们。
总结
Vite 的个性使其成为以后构建工具强有力的竞争者,在真正无缝的开发体验和开箱即用上,的确做了很多工作。
Vite | |
---|---|
反对多个前端框架模板配置 | ✅ |
反对热更新 / 替换开发环境服务 | ✅ |
流式引入 | ❌ |
生产环境预配置 | ✅ |
主动 PostCSS 和预处理器转换 | ✅ |
HTML 转换 | ❌ |
反对 Rollup | ✅ |
大小 | 17.1 MB |
wmr
与 Vite 一样,wmr 是另一种比拟有特点的构建工具,它提供了开发环境服务和构建步骤。它是由 Preact 的创建者 Jason Miller 构建的,因而对于 Preact 开发人员来说,这相对是一个舒服的抉择。Jason Miller 在 JS Party 播客中作为嘉宾呈现时解释了 wmr 背地的思考。
您可能想晓得 wmr 的全称是什么?可能是“Web Modules Runtime”,也可能是“Wet Module Replacement”,谁晓得呢(相似于 npm)。
wmr 很小,只有 2.6 MB,并且不带有任何的 npm 依赖项。尽管如此,它还是蕴含了很多十分棒的性能,包含热模块替换开发环境服务和优化的生产构建。
应用场景
如果我想尽快应用 Preact 创立一个我的项目,我会应用 wmr。无需配置,下载只需几秒钟。感觉就像应用增压的动态文件服务器。借助 TypeScript、优化构建步骤和动态 HTML 渲染,wmr 提供了交付中小型应用程序所需的所有性能。
如果您不应用 Preact、React 或 vanilla JavaScript,wmr 可能不适宜您。Preact 团队尚未为其余框架提供模板,文档也没有咱们看过的其余工具具体。
设置
如果你应用 preact,除了疾速装置 npm 之外,别的配置都不须要。在 wmr 下应用 React 的话须要两步,首先将 htm/preact
名称改为 htm/react
,并在 package.json 中配置 es-react
:
"alias": {
"htm/preact": "htm/react",
"react": "es-react"
},
而后将导入增加到组件中:
// ReactDOM only needed on root render
import {React, ReactDOM,} from 'es-react';
这样咱们实际上并没有应用一般 React 包,而是从 es-react 中引入了 React。这是因为 wmr 依赖于与原生 JavaScript 模块兼容的包。默认状况下,React 不应用原生 modules,而是用 UMD 模块。es-react 是一个取自 React 且提供与 Web 平台兼容的包。
还有一种办法,能够应用 Skypack 导入,它会在浏览器里预加载:
import React from 'https://cdn.skypack.dev/react';
import ReactDOM from 'https://cdn.skypack.dev/react-dom';
wmr 有很多插件 API,比方一个反对用于构建步骤的 Rollup 插件 API。文档上也带有一些 wmr 示例,比方一个压缩 HTML 的插件、基于文件系统的路由插件。
wmr 反对不同的框架,然而没有任何预构建的模板。
用法
在命令行中运行上面的命令即可:
npm init wmr your-project-name
或者,能够手动构建:
npm init -y
npm install wmr
mkdir public
touch public/index.html
touch public/index.js
而后在 index.html 中增加一个脚本导入(再次确保应用 type=”module”):
<script type="module" src="./index.js"></script>
当初您能够将 hello world 写入您的 index.js 文件:
import {render} from 'preact';
render(<h1>Hello World!</h1>, document.body);
最初,启动服务:
node_modules/.bin/wmr
当初咱们有了一个残缺的热模块替换开发环境服务,它会立刻响应咱们源代码的任何更改。
wmr 在转换 JSX 时应用了一个叫做 htm 的工具,假如咱们正在 wmr 中应用 Preact 编写一个计数器并犯了一个谬误:
import {render} from 'preact';
import {useState} from 'preact/hooks';
function App() {const [count,setCount] = useState(0)
return <>
<button onClick={()=>{setCount(cout+5)}}>Click to add 5 to count</button> // HIGHLIGHT
<p>count: {count}</p>
</>
}
render(<App />, document.body);
count
在 onClick
处理函数中拼写错误,因而会报错。通常,咱们将不得不依附咱们的工具和源映射来收集无关谬误所在位置的信息,但 wmr 采取了不同的解决方案。如果应用 htm,会可能靠近原生 JSX 写法,所以编写 React 或 Preact 代码的中央通常是这样的:
<MyComponent>I am JSX. I am not actually valid Javascript</MyComponent>
htm 看起来更像这样:
html`<${MyComponent}>I am about as close as it gets to JSX as you can get while being able to run in the browser</MyComponent>`
当初,如果咱们 F12 关上控制台的“Sources”面板,咱们应该会看到上面那这张图:
通过这种形式,咱们能够正确考察浏览器中的谬误所在,而无需应用源映射。
wmr 默认反对流式导入,因而裸导入(不带绝对 / 绝对路径的 import) 将从 npm 注册表中拉取。这个过程有点简单,该过程会查看 npm 包中的所有源代码,删除所有测试和元数据,并将其转换为单个原生 JavaScript import。与 Snowpack 相似,能够在不应用 npm 装置任何货色的状况下构建简单的应用程序。事实上,wmr 是第一个反对这个想法的工具。
反对的文件类型
wmr 反对能够在 JavaScript 中导入 CSS 文件,也反对 CSS module。
对 Vue 单文件组件或 Svelte 组件没有任何内置反对。然而,wmr 的构建步骤能够和 Rollup 插件配合应用,并且开发环境服务能够配置 Polka/ Express 中间件,因而能够应用这些将 import 转换为 Vue 和 Svelte 组件。
如果没有插件的话,咱们无奈将图片作为 wmr 中的 URL 导入 JavaScript。因而,如果咱们有一张小狗的图片,咱们可能会将它蕴含在 Preact 组件中,如下所示:
function Dog() {return <img src={new URL('./dog.jpg', import.meta.url)} alt="dog hanging out"></img>
}
一旦构建开始,图片就会被复制并从能够从文件内夹拜访。开发环境服务中的图片有热模块替换,所以图片的变动会立刻反映在浏览器中。
对于文件反对的另一个注意事项:能够导入 JSON,并会将其转换为 JavaScript 对象。然而在理论构建应用程序时,咱们须要 Rollup JSON 插件。
生产环境
wmr 有残缺的生产构建步骤,包含捆绑、压缩和 tree shaking,没有任何额定的依赖。
还有一种配置 wmr 的办法是将应用程序出现为动态 HTML 并应用 preact-iso 在浏览器上水合(hydrates)。这意味着 wmr 能够用作 Preact 的元框架,相似于 Next.js。
总结
wmr | |
---|---|
反对多个前端框架模板配置 | ✅ |
反对热更新 / 替换开发环境服务 | ✅ |
流式引入 | ✅ |
生产环境预配置 | ✅ |
主动 PostCSS 和预处理器转换 | ✅ |
HTML 转换 | ❌ |
反对 Rollup | ✅ |
大小 | 17.1 MB |
性能比照
简介
工具 | 特点 |
---|---|
esbuild | 大型代码库,还没筹备好生产。 |
Snowpack | 不须要捆绑的小型应用程序,也实用于在服务器渲染的应用程序。 |
Vite | 能够生成单页应用程序,代替了 Vue CLI/Create-React-App,Vue 玩家的高兴水。 |
wmr | 实用于中小型应用程序,可用于单页或服务器渲染的应用程序,Preact 玩家的高兴水。 |
应用
esbuild | Snowpack | Vite | wmr | |
---|---|---|---|---|
反对多个前端框架模板 | ❌ | ✅ | ✅ | ❌ |
装置默认磁盘占用大小 | 7.34 MB | 16 MB | 17.1 MB | 2.57 MB |
零配置构建打包 | ❌ | ❌ | ✅ | ✅ |
零配置热更新开发环境服务 | ❌ | ✅ | ✅ | ✅ |
Node 包的环境变量解决 | ❌ | ✅ | ✅ | ✅ |
开发环境服务
esbuild | Snowpack | Vite | wmr | |
---|---|---|---|---|
热更新 | ❌ | ✅ | ✅ | ✅ |
CSS 热替换 | ❌ | ✅ | ✅ | ✅ |
npm 依赖预捆绑 | ❌ | ✅ | ✅ | ❌ |
浏览器报错提醒 | ❌ | ✅ | ✅ | ❌ |
HTM 转换 | ❌ | ❌ | ❌ | ✅ |
生产构建
esbuild | Snowpack | Vite | wmr | |
---|---|---|---|---|
依赖 Go | ✅ | ✅在构建应用 esbuild 时 | ❌ | ❌ |
预配置构建 | ❌ | ❌ | ✅ | ✅ |
异步 chunk 加载 | ❌ | ❌ | ✅ | ✅ |
反对 Rollup 插件 | ❌ | ✅ | ✅ | ✅ |
其它个性
esbuild | Snowpack | Vite | wmr | |
---|---|---|---|---|
流式输出 | ❌ | ✅ | ❌ | ✅ |
服务端渲染 | ❌ | ❌ | ✅ (试验) | ✅ |
CSS Modules | ❌ | ✅ | ✅ | ✅ |
主动 PostCSS 和预处理器转换 | ❌ | ❌ | ✅ | ❌ |
相干链接
Comparing the New Generation of Build Tools
翻译打算原文