Any thoughts on switching to webpack with hot-reload about flux

[justin808]

As part of the PR, I'd like to update the dispatcher to the newer ES6 version.

[zpao]

I think #54 is going to update to the latest dispatcher code. I think we should use npm and not force anything ES6 just because we can.

I don't feel strongly about webpack (sure it has some upsides) so I'll let @fisherwebdev chime in.

[fisherwebdev]

Specifically what do we gain by switching to Webpack? That is, how does switching to Webpack clarify the examples or make them easier to get up and running? If you can make the case that people will gain a better understanding of Flux, and be up and running faster and easier, then I think it makes sense to switch. If not, then I think this seems like a situation where you could fork the repo, and we could point interested Webpack enthusiasts to your fork.

[justin808]

@petehunt turned me on to webpack. I cannot comment on the alternative, as I've mostly used WebPack. I really enjoy how WebPack updates the client side JavaScript code nearly instantly, and these updates include the rendering, and often the models. Sometimes I do refresh the browser, but more often, I don't. The configuration is also very easy for a newbie. In this repo, https://github.com/justin808/react-webpack-rails-tutorial, inside of the webpack directory, the webpack dev server handles the code there. I wrote this up here: http://www.railsonmaui.com/blog/2014/10/02/integrating-webpack-and-the-es6-transpiler-into-an-existing-rails-project/.

[pikeas]

@fisherwebdev Hot reload (whether via webpack, browsersync.io, or other library) makes exploratory development -- AKA, exactly what an interested React/Flux beginner will want to do -- significantly easier.

[sterpe]

@pikeas given the issues cited here (for example) http://mattdesl.svbtle.com/browserify-vs-webpack

Why would webpack be any easier than currently using browserify? It certainly seems less scalable.

Looking at the documentation for webpack the configuration is almost more complex than require.js-- which feels like a step back, but the killer issue is that the overloading of require calls with loader directives makes webpack modules unrunnable in node:

require('json!./foo.json')

That's hard to see as a win.

[pikeas]

@sterpe Your points are fair. Although I personally prefer webpack, I'm advocating for hot reloading in some capacity, regardless of implementation details.

Regarding require('json!./foo.json'), loaders can be specified in the webpack config file, so that require stays clean: http://webpack.github.io/docs/loaders.html#loaders-by-config

[sterpe]

Sure but there we get into that configuration complexity to do something that browserify does with none or very little. Just seems weird to me.

Really do we need to hot load these demos? Honestly how much time do people spend playing with them before they put them away and start building something real?

[fisherwebdev]

I'd rather not have the Browserify vs. Webpack debate here. If you're inclined, there are plenty of other places on the web to have that debate, such as https://gist.github.com/substack/68f8d502be42d5cd4942.

I think a new Flux example might be worth developing -- perhaps that one could use Webpack, just to show another way of doing it. The subject of a new example has come up a couple of times, most recently in #134, so I think we could see a Webpack example soon.