- An all in one asset transformer and bundler.
- Recommends that we use its internal dev server.
- Built within / serving the React community.
- Convention based, Rails-esque; many defaults for a "normal" project.
- Run off of a large config file.
- Has its own plugin ecosystem (Similar to babel / rollup transforms. Are they sharable?).
Webpack Loaders pull every asset into JS for transformation - a JS replacement for the asset pipeline, or a configuration based alternative to gulp?
CSS Example:
require("!style!css!./style.css");
document.write(require("./content.js"));
- Unusual asset selection scheme; write special regexes to apply transforms to files
- Can do automatic code splitting, but within community it's not considered as good/efficient/smart as defining separate bundles by hand.
- Optional dev-builder plugin that uses an in memory cache to make reloads faster. Some dev perf for free.
- Raw Babel that compiles down to ES5.
- Babel is a requirement for our JS pipeline no matter what.
- Needs to use another build system tool to further transform js / manage non-js assets.
- Needs to use another module bundler to bundle assets; just compiles includes/exports to common or AMD.
- gulp has a longer history than the rest of these projects. Most common problems (sourcemaps, any special transforms) are solved.
- Gulp has excellent modularity. Tiny lego bricks of functionality. We have to build more, but each brick we build with is purpose built, and we don't fight against the "common path" of convention based projects.
Note that most bundlers want an entry file and access to the file system to bundle, so they don't fit cleanly into gulp's stream one file through transforms modus. We're likely to use gulp with any of the other bundler options, to manage further JS transforms and build processes for non-js assets, and will have to do some integration with our bundler. Not a big deal.
- One of the newest bundlers.
- Can compile es6 imports to common js, AMD, or an ES5 self executing bundle (which ends up being the smallest).
- Using ES6+ imports, it can "tree shake", i.e. only bundle the code actually being used. This results in much smaller bundles.
- The compile is faster than most.
- Has its own plugin ecosystem (Similar to babel transforms. Are they sharable?).
- Has its own babel presets and plugins in order to work in sync with Babel. It gets better results from transpiling and bundling and in one step.
- Still has some common use cases to be hardened. Sourcemaps are newly implemented.
- To work best (esp. tree shaking), every module must be in ES6.
- Similar to Babel, this is a single step in the JS pipeline. gulp is still required for further transforms.
- Big interesting difference: the ES5 file compiled with Rollup executes faster than the same file compiled with Browserify or Webpack.
- We know about this one already.
- There's less written about it (less adoption?).
- We can speed bundling by splitting the bundle.
- There's a dev server that may give us a bunch of perf for free.
Rollup seems like the modern winner. It's small and single purpose. It results in very traditional bundled self executing JS, but the number of files is up to us (we could easily split into many files for http2). It doesn't have a lot of defaults or features built in; with a blank slate we have low tool friction but higher learning / research costs.
JSPM bundle splitting and dev server may be an easy, quick win. I recommend investigating these two in parallel. Lessons learned splitting the files and understanding how the dev server works will transfer almost any solution we end up on.