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.

Featurewebpack/webpackjrburke/requirejssubstack/node-browserifyjspm/jspm-clirollup/rollupbrunch/brunch
Additional chunks are loaded on demandyesyesnoSystem.importnono
AMD defineyesyesdeamdifyyesrollup-plugin-amdyes
AMD requireyesyesnoyesnoyes
AMD require loads on demandyeswith manual configurationnoyesnono
CommonJS exportsyesonly wrapping in defineyesyescommonjs-pluginyes
CommonJS requireyesonly wrapping in defineyesyescommonjs-pluginyes
CommonJS require.resolveyesnononono-
Concat in require require("./fi" + "le")yesno♦nonono-
Debugging supportSourceUrl, SourceMapsnot requiredSourceMapsSourceUrl, SourceMapsSourceUrl, SourceMapsSourceMaps
Dependencies19MB / 127 packages11MB / 118 packages1.2MB / 1 package26MB / 131 packages?MB / 3 packages-
ES2015 import/exportyes (webpack 2)nonoyesyesyes, via es6 module transpiler
Expressions in require (guided) require("./templates/" + template)yes (all files matching included)no♦nononono
Expressions in require (free) require(moduleName)with manual configurationno♦nonono-
Generate a single bundleyesyes♦yesyesyesyes
Indirect require var r = require; r("./file")yesno♦nonono-
Load each file separatenoyesnoyesnono
Mangle path namesyesnopartialyesnot required (path names are not included in the bundle)no
MinimizingTerseruglify, closure compileruglifyifyyesuglify-pluginUglifyJS-brunch
Multi pages build with common bundlewith manual configurationyeswith manual configurationwith bundle arithmeticnono
Multiple bundlesyeswith manual configurationwith manual configurationyesnoyes
Node.js built-in libs require("path")yesnoyesyesnode-resolve-plugin-
Other Node.js stuffprocess, __dir/filename, global-process, __dir/filename, globalprocess, __dir/filename, global for cjsglobal (commonjs-plugin)-
Pluginsyesyesyesyesyesyes
Preprocessingloadersloaderstransformsplugin translateplugin transformscompilers, optimizers
Replacement for browserweb_modules, .web.js, package.json field, alias configuration optionalias optionpackage.json field, alias optionpackage.json, alias optionno-
Requirable filesfile systemwebfile systemthrough pluginsfile system or through pluginsfile system
Runtime overhead243B + 20B per module + 4B per dependency14.7kB + 0B per module + (3B + X) per dependency415B + 25B per module + (6B + 2X) per dependency5.5kB for self-executing bundles, 38kB for full loader and polyfill, 0 plain modules, 293B CJS, 139B ES2015 System.register before gzipnone for ES2015 modules (other formats may have)-
Watch modeyesnot requiredwatchifynot needed in devrollup-watchyes

♦ in production mode (opposite in development mode)

X is the length of the path string

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.

6 Contributors

pksjcebebrawchrisVillanuevatashiansimon04byzyk