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