The Phoenix philosophy for asset management is, just use npm/node - we have brunch as a default but it is easily replaceable by whatever. So I also think it’s not going to come.

I like this very much. We don’t have to reinvent the wheel every time around and cook something new up. Most node/npm tooling is far more advanced than in other language which is also why people on frameworks with asset management (like rails) constantly look for ways to integrate, for instance, webpack with it - which is a pain (or at least it was for both Rails and JS experts at my former company).

I love the flexibility and pragmatism of Phoenix here.

One the things we were very careful with when designing the integration with brunch is to make sure all the code is in the generated application. The only line of code in your Phoenix project that knows about brunch is a single line in your config/dev.exs that starts the watcher. Phoenix itself knows nothing. This means we can replace Brunch by something else in future versions without breaking any existing application.

Very! Re-creating the javascript asset pipeline would be beyond painful and not work with everything very well. Using node is the right way, regardless of how heavy node is. ^.^

EDIT: My main complaint with the node stuff is the 50-thousand asset pipelines that do not interoperate (Brunch, Webpack, Gulp, Grunt, JSPM, Bower, NPM, etc… etc.. etc.) and where certain libraries will only work with certain things (I have 4 of the above things in my big project right now because of javascript ecosystem utter-stupidity). I do not care ‘what’ is chosen, but there needs to be only one thing chosen…