ES6模块允许我们创建代码模块,可以作为依赖项进行导出和导入。
Browserify和Webpack也实现了相同的功能。那么,如果我使用ES6以及像babel这样的工具来转译我的代码,那么webpack和browserify就不再需要了吗?
ES6模块允许我们创建代码模块,可以作为依赖项进行导出和导入。
Browserify和Webpack也实现了相同的功能。那么,如果我使用ES6以及像babel这样的工具来转译我的代码,那么webpack和browserify就不再需要了吗?
如果您在浏览器中使用它,目前仍需要webpack或browserify。
让我们看一个例子:
以下内容
import * as name from 'name.js';
被转换为:
'use strict';
function _interopRequireWildcard(obj) { if (obj && obj.__esModule) { return obj; } else { var newObj = {}; if (obj != null) { for (var key in obj) { if (Object.prototype.hasOwnProperty.call(obj, key)) newObj[key] = obj[key]; } } newObj['default'] = obj; return newObj; } }
var _nameJs = require('name.js'); // Here, a function named "require" is still needed
var name = _interopRequireWildcard(_nameJs);
正如你所见,babel 依赖于 CommonJS 方法 require
(实际上是任何它的实现)来进行导入。由于 node.js 实现了 CommonJS,因此可以工作,但目前没有浏览器实现它。据我所知,也没有任何一个浏览器原生支持 ES 6 模块。
如此处所述-ES6模块有两个方面:
ES6模块标准分为两部分:
- 声明性语法(用于导入和导出)
- 编程式加载器API:配置模块的加载方式并有条件地加载模块
Babel仅处理第一个方面-即用于导入和导出的声明性语法,并不提供自己的加载器。
今天使用ES6模块的人通常会执行以下操作之一:
System.import
语法,SystemJS可能会大受欢迎。另一个方面是与现有模块生态系统(特别是npm上的模块)的兼容性。值得注意的是,无论采用哪种策略,都不会失去与现有生态系统的兼容性:Webpack和SystemJS都允许加载和捆绑CommonJS和AMD模块。
就资源捆绑而言,HTTP 2 中的持久连接支持已经大大降低了 javascript 文件串联的价值。尽管在完整的 javascript 捆绑文件进行丑化之后的死代码消除仍然是一种有价值的优化。目前我认为有三个要点。如果我错了,请纠正我...
如果您想要用户获得最佳性能,则 es6modules 更好。在某些情况下,它们的表现更好(较少的 http 请求,更好的缓存),而且据我所知,没有任何情况会表现更差。
browserify
与目前最常用的包管理器 npm
集成得更好。
使用 es6modules 时,您必须指定 node_modules
中模块的相对路径,而不仅仅是像 browserify
那样指定模块的名称。您可以编写一个预处理器来解决 es6modules 的这个问题,并在构建过程中执行它(如果它不是相对路径,它只会更改路径)。但这当然需要额外的工作,而 browserify 则提供了这个功能。
此外,npm 注册表中的大多数模块可能使用 commonjs 语法而不是 es6modules 语法。这意味着,如果您想直接从 npm 使用模块,则必须 fork 它以利用 es6modules 的优势。
注意:据我所知,将es6模块语法转换为其他形式(例如使用babel)不会保留es6模块语法的好处。
browserify
,有相当不错的工具可用,使开发非常便捷,以便您可以以有效的方式工作,例如watchify
,由于缓存而显着增加了构建所需的时间。