I knew that was going to pop up! 
At the very least:
I’m not actually sure how serious I am but here it goes:
You get the drift … no, I don’t think it will work but you never know.
As much as I would love to, Brunch has some major design faults that I’ve run across having made 3 brunch plugins for phoenix. Let me list just a few that come immediately to mind:
;require.register("web/elm/JSPhoenix.elm", function(exports, require, module) {
});
And there are others upon others. It is a design fault in brunch. Honestly Phoenix needs to change to one of the others, sadly I’ve no clue which would really be best… Gulp seems to be the one most capable of working with everything so maybe it, but I’m unsure…
Ember uses Broccoli, not sure if it’s good or not. Laravel (PHP) uses Gulp, so maybe someone can tell us their experience with that.
gulp is… okay. It’s the successor of grunt in many ways, my last prolonged exposure to it is 1.5 years ago - and basically the same feeling I get with webpack: people I respect very much spent way too much time (imo) fiddling with it to make it work in a not super special context (CoffeeScript, React, Sass, autoprefixer) but in the end it all worked fine 
I’d be curious of everyones experiences with all the various things. The popular ones are (in no specific order):
And a few other minor ones that I barely hear about. I’m especially curious in:
I’m curious because honestly Brunch is so restricted (and unused out in the ‘wild’) that I’m thinking it should be replaced as the default handler in Phoenix, or at least for an alternate to be supplied via a new template.
We are not committed to brunch. The reason we chose brunch is because it is the tool that required the least amount of configuration and fiddling for someone who wants to write just enough javascript to complement their server side work.
Because, let’s be honest, if we are targeting advanced JS users, there is no single choice that will make the majority of them happy.
I believe both Chris and I are open to change Phoenix to something given it is stable, we can interact with it through a single configuration file (at least initially), it is fast and it supports fs watching.
That is great to hear!
webpack hit 2.0 and it seems the most popular choice, although that might be my bubble. Personally I think that this is nothing that NEEDS to change much less NOW - I think this might be something worth revisiting in ~a year and see what’s going on in JS land then and if it’s stable. Maybe with a Phoenix 2.0 some day
I mostly use webpack in other projects so rip brunch out when playing around with Phoenix.
It might sound strange, but I feel there is less magic involved in webpack, though that’s admittedly because I’ve taken the time to learn webpack and not so much brunch.
A very simple webpack config for phoenix is easy to do. Regardless, one thing I’d love to see is the removal of the bootstrap blob in phoenix.css and have it default to being an npm dependency that is required somewhere.