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.
As someone outside to a lot of those still, webpack and gulp seem the biggest to me, with gulp slightly larger than webpack, and JSPM is the fastest growing but does not seem as powerful as webpack or gulp.
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.
I belive this is an easy PR, do you happen to know the reasoning for having the bootstrap blob instead of the package?
Maybe we could set up the bootstrap-sass package on the installer.
I don’t know the reasoning, and I was thinking the same thing about it being an easy PR.
Even using brunch, adding in brunch-sass and node-sass as dependencies and then importing bootstrap would be a quick fix. This of course won’t please anyone who wants to use some other preprocessor, though the sass ecosystem is very nice.
Edit
It looks like all the necessary changes would take place in https://github.com/phoenixframework/phoenix/tree/master/installer/templates/static/brunch but I’d be interested to know whether @chrismccord and @josevalim are even interested in a change like this.
If I remember correctly, we don’t want to necessarily depend on bootstrap. It just happens to be what we use for the initial page (although that’s argument is half moot given the generator generates bootstrap classes too).
Yes, I love that design of Phoenix very much - as you said before no matter what you pick it won’t satisfy everyone.
Me mentioning 2.0 was not so much about backwards compatibility but more about it being a “significant” change. I.e. I don’t think it would suit phoenix to change the default asset build tool every year or so (and I don’t see phoenix headed in that direction), so I thought the next major release might be a good time to re-evalute brunch & competition.
Of course that was assuming there will be one in the next ~2 years or so, but I don’t know maybe it’ll just stay stable at 1.x for a lot longer than I imagined 
Another option would be switches/options, but that adds overhead and in Chris’s words:
(…) it’s too much to ask for generators/switches for every build tool under the sun. We’d have constant churn so our current approach of a sane default with trivial swapping with whatever you’d like is the best way to go.
I’m against webpack - e.g. you’ll need separate plugin to get css file out of it (who wants css, right? ). Soo many weird decisions imo
You have to do that with Brunch too, Brunch does not understand css by default either (phoenix just sets up the css and javascript, yes it does not understand javascript by default either, for you). ^.^
I played with gulp a bit last night. You can set up any kind of pathing you want and it can work in parallel (if you design your streams well) very well too. However its internal debugging can be a slice of hell (it seems to have no equivalent to Brunch’s LOGGY_STACKS environment variable that I could find). Has a file watcher/reloader and more, integrates with Phoenix well.
© Copyright Elixir Forum | Terms | Privacy & Cookies
