Thanks for this shameless plug! Webpack happens to be next on my list of frontend builders to try (hoping that it's less bug-ridden than Browserify and less hassle than Grunt or Gulp). If it works like it says on the tin, I'll probably be an early adopter of your hot loader.
Webpack is totally awesome. It's not as documented as I wish it was but @sokra (Tobias) is an insanely clever person. A few months ago I dismissed it in favor of Browserify, but after really getting to know Webpack, Browserify is nowhere close.
* Webpack isn't religious and plays well with CommonJS, AMD, whatever. We almost didn't have to change the code when ported from RequireJS.
* Browserify's "all in one bundle" approach is precisely what we wanted to get away from, because our codebase grew like crazy. Webpack supports [code splitting][1] which allowed us to cut initial JS by half.
* As Pete Hunt said on some thread I can't find now, Browserify doesn't bring anything really new to the table. Webpack, on the other hand, brings "loaders" (first-class support for applying cacheable transformations as a build step for module). While they are not documented very well[2], they allow insane extensibility. They can be used for anything, from declarative code splitting with require() returning a promise[3], to compiling LESS[4], to bundling CSS as a JS dependency[5], to running JSHint[6].
* Hot Module Replacement gives each module an API to declare how it reacts to its dependencies being updated[7]. Loaders can use this API too, e.g. `style-loader` uses HMR to replace stylesheet without reloading the page[8], so you don't need to write extra code.
The biggest downside right now is the documentation being too technical. In the long run though, I believe Webpack will get more popular once its docs are improved, because it's just crazy powerful and extensible.
