[danabramov]

Shameless plug: though unrelated to the article, for the past few days I've been working on live reload for React components.

As you edit JSX files, after a small delay, components re-render in browser, using React's diff algorithm to reconcile DOM. This means their state is not destroyed. For example, you can live-edit a modal window without having to refresh and open it again. You can change event handlers and debug a complex component on the fly.

There are no browser plugins involved, it's all just JS. This is implemented on top of Webpack, if you want to give it a try, check it out! (I assume familiarity with Webpack, but I plan to write an explanatory blogpost later.)

I'm very excited about this because I think it's the future of front-end development. It is possible thanks to React's separation of side-effects and Webpack's powerful plugin system (loaders are essentially macros).

Project on Github: https://github.com/gaearon/react-hot-loader (contains an example you can run)

Demo video: http://vimeo.com/m/100010922

[skrebbel]

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.

[danabramov]

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.

[skrebbel]

Interesting. Why did you move over from Browserify? From a first glance, the featureset seems comparable, and Browserify sure has more hype behind it.

[danabramov]

A lot of reasons actually.

* 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.

[1]: https://github.com/webpack/docs/wiki/code-splitting

[2]: https://github.com/webpack/webpack/issues/360

[3]: https://github.com/gaearon/promise-loader

[4]: https://github.com/webpack/less-loader

[5]: https://www.npmjs.org/package/style-loader

[6]: https://github.com/webpack/jshint-loader

[7]: http://webpack.github.io/docs/hot-module-replacement-with-we...

[8]: https://github.com/webpack/docs/wiki/hot-module-replacement

[skrebbel]

Great, thanks for the braindump!

[danabramov]

Update: if you're interested, I blogged about how this works and how to integrate live reload in your project: http://gaearon.github.io/react-hot-loader/