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.

♦ in production mode (opposite in development mode)

X is the length of the path string

Module System Support

Tool	Additional chunks on demand	AMD define	AMD require	AMD require on demand	CommonJS exports	CommonJS require	CommonJS require.resolve	ES2015 import/export
webpack/webpack	yes	yes	yes	yes	yes	yes	yes	yes (webpack 2)
jrburke/requirejs	yes	yes	yes	manual config	define wrap only	define wrap only	no	no
substack/node-browserify	no	deamdify	no	no	yes	yes	no	no
jspm/jspm-cli	System.import	yes	yes	yes	yes	yes	no	yes
rollup/rollup	no	rollup-plugin-amd	no	no	commonjs-plugin	commonjs-plugin	no	yes
brunch/brunch	no	yes	yes	no	yes	yes	-	yes, via es6 module transpiler

Require & Path Handling

Tool	Concat in require	Expressions (guided)	Expressions (free)	Indirect require	Mangle paths	Node.js built-ins	Other Node.js stuff	Browser replacement	Requirable files
webpack/webpack	yes	yes (all files matching included)	manual config	yes	yes	yes	process, __dir/filename, global	web_modules, .web.js, package.json field, alias config option	243B + 20B per module + 4B per dependency
jrburke/requirejs	no♦	no♦	no♦	no♦	no	no	-	alias options	web
substack/node-browserify	no	no	no	no	partial	yes	process, __dir/filename, global	package.json field, alias option	file system
jspm/jspm-cli	no	no	no	no	yes	yes	process, __dir/filename, global for cjs	package.json, alias option	through plugins
rollup/rollup	no	no	no	no	not required	node-resolve-plugin	global (commonjs-plugin)	no	file system or through plugins
brunch/brunch	-	no	-	-	no	-	-	-	file system

Build & Output

Tool	Generate single bundle	Multi pages build	Multiple bundles	Load each file separate	Minimizing	Preprocessing	Plugins
webpack/webpack	yes	manual config	yes	no	Terser	loaders	yes
jrburke/requirejs	yes♦	yes	manual config	yes	uglify, closure compiler	loaders	yes
substack/node-browserify	yes	manual config	manual config	no	uglifyify	transforms	yes
jspm/jspm-cli	yes	bundle arithmetic	yes	yes	yes	plugin translate	yes
rollup/rollup	yes	no	no	no	uglify-plugin	plugin transforms	yes
brunch/brunch	yes	no	yes	no	UglifyJS-brunch	compilers, optimizers	yes

Developer Experience

Tool	Debugging support	Watch mode	Dependencies	Runtime overhead
webpack/webpack	SourceUrl, SourceMaps	yes	19MB / 127 packages	yes
jrburke/requirejs	not required	not required	11MB / 118 packages	14.7kB + 0B per module + (3B + X) per dependency
substack/node-browserify	SourceMaps	watchify	1.2MB / 1 package	415B + 25B per module + (6B + 2X) per dependency
jspm/jspm-cli	SourceUrl, SourceMaps	not needed in dev	26MB / 131 packages	5.5kB self-exec bundles, 38kB full loader+polyfill, 0 plain modules, 293B CJS, 139B ES2015 System.register before gzip
rollup/rollup	SourceUrl, SourceMaps	rollup-watch	?MB / 3 packages	none for ES2015 modules (other formats may have)
brunch/brunch	SourceMaps	yes	-	-

Bundling vs. Loading

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 its advantages and disadvantages. 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.