5 ms·

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 sm

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 https://github.com/gaearon/react-hot-loader (contains an example you can run) Demo video: http://vimeo.com/m/100010922 http://vimeo.com/m/100010922

skrebbel 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 https://github.com/webpack/docs/wiki/code-splitting [2]: https://github.com/webpack/webpack/issues/360 https://github.com/webpack/webpack/issues/360 [3]: https://github.com/gaearon/promise-loader https://github.com/gaearon/promise-loader [4]: https://github.com/webpack/less-loader https://github.com/webpack/less-loader [5]: https://www.npmjs.org/package/style-loader https://www.npmjs.org/package/style-loader [6]: https://github.com/webpack/jshint-loader https://github.com/webpack/jshint-loader [7]: http://webpack.github.io/docs/hot-module-replacement-with-webpack.html http://webpack.github.io/docs/hot-module-replacement-with-we... [8]: https://github.com/webpack/docs/wiki/hot-module-replacement https://github.com/webpack/docs/wiki/hot-module-replacement
      - skrebbel 12y ago
        Great, thanks for the braindump!
        danabramov 12y ago
        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/ http://gaearon.github.io/react-hot-loader/

skrebbel 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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 https://github.com/webpack/docs/wiki/code-splitting [2]: https://github.com/webpack/webpack/issues/360 https://github.com/webpack/webpack/issues/360 [3]: https://github.com/gaearon/promise-loader https://github.com/gaearon/promise-loader [4]: https://github.com/webpack/less-loader https://github.com/webpack/less-loader [5]: https://www.npmjs.org/package/style-loader https://www.npmjs.org/package/style-loader [6]: https://github.com/webpack/jshint-loader https://github.com/webpack/jshint-loader [7]: http://webpack.github.io/docs/hot-module-replacement-with-webpack.html http://webpack.github.io/docs/hot-module-replacement-with-we... [8]: https://github.com/webpack/docs/wiki/hot-module-replacement https://github.com/webpack/docs/wiki/hot-module-replacement
    - skrebbel 12y ago
      Great, thanks for the braindump!
      - danabramov 12y ago
        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/ http://gaearon.github.io/react-hot-loader/