字典我要纠错

Comparison

webpack is not the only module bundler out there. If you are choosing between using webpack or any of the bundlers below, here is a feature-by-feature comparison on how webpack fares against the current competition.

Feature	webpack/webpack	jrburke/requirejs	substack/node-browserify	jspm/jspm-cli	rollup/rollup	brunch/brunch
Additional chunks are loaded on demand	yes	yes	no	System.import	no	no
AMD `define`	yes	yes	deamdify	yes	rollup-plugin-amd	yes
AMD `require`	yes	yes	no	yes	no	yes
AMD `require` loads on demand	yes	with manual configuration	no	yes	no	no
CommonJS `exports`	yes	only wrapping in `define`	yes	yes	commonjs-plugin	yes
CommonJS `require`	yes	only wrapping in `define`	yes	yes	commonjs-plugin	yes
CommonJS `require.resolve`	yes	no	no	no	no
Concat in require `require("./fi" + "le")`	yes	no♦	no	no	no
Debugging support	SourceUrl, SourceMaps	not required	SourceMaps	SourceUrl, SourceMaps	SourceUrl, SourceMaps	SourceMaps
Dependencies	19MB / 127 packages	11MB / 118 packages	1.2MB / 1 package	26MB / 131 packages	?MB / 3 packages
ES2015 `import`/`export`	yes (webpack 2)	no	no	yes	yes	yes, via es6 module transpiler
Expressions in require (guided) `require("./templates/" + template)`	yes (all files matching included)	no♦	no	no	no	no
Expressions in require (free) `require(moduleName)`	with manual configuration	no♦	no	no	no
Generate a single bundle	yes	yes♦	yes	yes	yes	yes
Indirect require `var r = require; r("./file")`	yes	no♦	no	no	no
Load each file separate	no	yes	no	yes	no	no
Mangle path names	yes	no	partial	yes	not required (path names are not included in the bundle)	no
Minimizing	uglify	uglify, closure compiler	uglifyify	yes	uglify-plugin	UglifyJS-brunch
Multi pages build with common bundle	with manual configuration	yes	with manual configuration	with bundle arithmetic	no	no
Multiple bundles	yes	with manual configuration	with manual configuration	yes	no	yes
Node.js built-in libs `require("path")`	yes	no	yes	yes	node-resolve-plugin
Other Node.js stuff	process, __dir/filename, global	-	process, __dir/filename, global	process, __dir/filename, global for cjs	global (commonjs-plugin)
Plugins	yes	yes	yes	yes	yes	yes
Preprocessing	loaders, transforms	loaders	transforms	plugin translate	plugin transforms	compilers, optimizers
Replacement for browser	`web_modules`, `.web.js`, package.json field, alias config option	alias option	package.json field, alias option	package.json, alias option	no
Requirable files	file system	web	file system	through plugins	file system or through plugins	file system
Runtime overhead	243B + 20B per module + 4B per dependency	14.7kB + 0B per module + (3B + X) per dependency	415B + 25B per module + (6B + 2X) per dependency	5.5kB for self-executing bundles, 38kB for full loader and polyfill, 0 plain modules, 293B CJS, 139B ES2015 System.register before gzip	none for ES2015 modules (other formats may have)
Watch mode	yes	not required	watchify	not needed in dev	rollup-watch	yes

♦ in production mode (opposite in development mode)

X is the length of the path string

It's important to note some key differences between loading and bundling modules. A tool like SystemJS, which can be found under the hood of JSPM, is used to load and transpile modules at runtime in the browser. This differs significantly from webpack, where modules are transpiled (through "loaders") and bundled before hitting the browser.

Each method has it's pros and cons. Loading and transpiling modules at runtime can add a lot of overhead for larger sites and applications comprised of many modules. For this reason, SystemJS makes more sense for smaller projects where fewer modules are required. However, this may change a bit as HTTP/2 will improve the speed at which files can be transferred from server to client. Note that HTTP/2 doesn't change anything about transpiling modules, which will always take longer when done client-side.

Comparison

Comparison

Bundling vs. Loading

Further Reading