How to plug in webpack 2.0 into phoenix 1.3.0-rc

[peerreynders]

@zazaian

You seem to keep coming back to the value of Webpack when all you’re doing is rendering EEx templates through Phoenix on your front-end.

That’s entirely it - and the stock front end that Phoenix spins up (short of specifying --no-html) is EEx (server side template) based - this is also the front end that the Phoenix Guides and the Book assume you have set up.

Now I may have expressed myself poorly in the earlier post. It was never my intention to imply “Webpack doesn’t work (well) with Phoenix” - quite the contrary; if you are using React or Vue.js I’d say, ditch Brunch ASAP and run, don’t walk towards Webpack because for better of for worse those communities have embraced it (just don’t expect it to be a cakewalk) otherwise you are just going to feel like a salmon swimming upstream trying to make do with something else like Brunch.

My response was to the point of Webpack potentially replacing Brunch as part of the Phoenix distribution some time in the future i.e.:

should probably be a candidate for being integrated by default in Phoenix 1.4+.

I simply don’t see that happening - I don’t know if you are familiar with this topic:

Potentially removing brunch from the Phoenix new template generator

I’m curious about peoples thoughts about this, especially of @chrismccord. In my project I have brunch and 2 other javascript build systems as well as a dozen libraries I specifically call, it is… unwieldy. I started looking at other popular javascript build systems recently (as shown by a past recent thread). Grunt was horrible, don’t touch it, Gulp is good, kind of like Brunch (it has watcher, reloaders, hot-reloaders, etc…), it is completely async (if the supporting libraries are, like br…

My takeaway from that topic:

• The Phoenix team wants to minimize the dependencies that the distribution has to the (ever changing) JavaScript ecosystem. There is just enough JavaScript to support channels and that is it. This is simply a pragmatic decision to minimize the opportunity cost of keeping up with the Joneses in JavaScript land - the Phoenix team wants to focus on Elixir and Phoenix and not get distracted by supporting everybody’s favourite JavaScript frontend and toolchain.
• Brunch was chosen because it was good enough to provide a relatively “low maintenance” solution for the stock EEx frontend which wouldn’t get in the way of the Phoenix newcomer trying to learn “just Phoenix” - i.e. get distracted with too many JavaScript-y (toolchain) things. It probably requires fewer interventions than npm scripts (personally I consider Webpack potentially “high maintenance”). This should not be construed as an endorsement by Phoenix as Brunch being the greatest asset build tool ever - far from it, as Phoenix goes through great lengths not to integrate tightly with Brunch (hence the --no-brunch option).

That is why I don’t see Webpack replacing Brunch in the Phoenix distribution.

So ultimately it is the developer’s own responsibility to chose and integrate the necessary/optimal asset build tools for their own particular use case. Phoenix’s responsibility is largely confined to not getting in the way.

Somehow that doesn’t stop the wishes/demands for the generators to set up projects with everybody’s favourite JS framework and build tools. Providing that level of support is ultimately up to the greater Phoenix community (not the Phoenix distribution - good documentation helps though) - and it’s often rendered in the form of template projects or “how to” blog post.

The template projects are great if you can just run with what is supplied - personally I prefer those nitty-gritty blog posts because they tend to give me a better starting point to build up the necessary knowledge to customize and troubleshoot my configuration.