My 10c here. For context I am a front end developer, there are around 50 other FE devs at my company, and we work on several farly complex application platforms. I work on top of a C# codebase, but I don’t think the the backend is particularly relevant to this discussion - we face the same set of issues that having an Elixir/Phoenix based codebase would have as regards frontend.

I guess every non-junior dev at our company, and almost every non-junior FE dev I know has seen the “just use use NPM scripts” article referenced in the first post. And everyone reads it, thinks “isn’t that a great idea! Why am I using webpack/gulp/etc” and implements it in a few small projects, and it works great. Then you try to use it on a non-trivial project, and you start to hit issues. The NPM scripts approcach does not scale, it is fragile, and it gets complex really quickly. It seems a really simple solution, because it is. In the same way as [eg] awk or sed or ed are.

All of the current solutions are substandard in some way - WebPack get complex fast, Brunch just builds stuff, Gulp is Gulp (hello enormous config files). But Brunch is simple enough to do any common task with almost zero config - if I want to add, say, Scss support, it is a single line - no other FE build system can currently provide that. Webpack is arguably better for anything moderately complex (eg I need to unit test everything, so I’ve got to go there), but then the setup is still horribly complex. NPM is too low level; it gets more and more complex until the point that you build a build system. If you have 60 lines of NPM script, there’s gonna be an issue giving that to someone else. As an example - how do glue all of these ES6 modules together? I personally know how to do it, but then, if I write an NPM script that lints, transpiles then concatenates, it’s going to be utter gibberish. If I do that with a taskrunner or build tool, it will not be.

I think I’ve been spoilt a bit by Elixir (and Rust, and Go to some extent), where I have a language with a build system and test framework and built in documentation, and it all works somewhat seamlessly; there are simple answers that provide solutions that work in the majority of cases. There is one way to do things, and it works, out-of-the-box.

With JS, it’s a massive mess. You need some kind of build system that is simple, allows for flexibility, and isn’t complex to introduce that flexibility. It’s needs to be high-level. NPM scripts are simple (in the same way bash scripts are simple), and they allow flexibility if you type out the magic utterances, but adding/modifying functionality is painful and means modifying things at root level; it is in no way high level.

Brunch is pretty good - it’s pretty fast, it’s very easy to understand, it’s had a very long time for issues to be known and understood. Critically, it’s really easy to replace; it’s not like the asset pipeline, it’s not baked in. A canonical set of articles on how to replace with NPM Scripts/Webpack/Gulp/taskrunner-du-jour would possibly be the most useful thing that could exist re this issue.

Ok, so it seems like the brunch project is dead at this point?

Many of their libraries (at least the ones we’re using) are not maintained at all, with few or no releases over the last half year, and it’s especially evident in the last 3 months.

E.g., on our production app, we’re using sass. To get that working we’ve had to pull the master branch to get it to compile. This is an issue everybody will experience if they use recent nodejs version, but there has been no release for a year.

I feel that a simple build tool with NPM scripts would be far the best solution for Phoenix. But at least switching to a well-maintained library like webpack would be much better. Brunch has been a painful experience for us, and I don’t think Phoenix should default new users to it.

The goal is an out of the box experience that Just Works without fanfare. With a basic brunch or web pack config, a user does not have to know about browserify, how to configure it, how to bundle, etc. So even if this can all be achieveved by stringing fewer deps together, end-users still have to know how those deps work individually and configure to their liking. This may work well for power users but newcomers, especially those not enthralled in js day to day, just want to compile and bundle js/es20xx/sass without pain.