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 | Terser | 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 | loaders | transforms | plugin translate | plugin transforms | compilers, optimizers |
Replacement for browser | web_modules , .web.js , package.json field, alias configuration 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 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.