• Brunch and Webpack are module bundlers. As such they have an opinion about the build process but by and large they are configured rather than scripted. In Webpack’s case things get a bit blurry because configurations are often assembled in a scripted manner.
• Gulp is a task runner and as such sees itself as taking the place of npm scripts. So to bundle modules it still has to use a bundler plugin such as Browserify which often can be done simply in npm itself. Gulp has more advanced facilities than npm scripts for coordinating build tasks - but from what I’ve seen it isn’t really configured as much as it is being scripted by writing Gulp tasks. One issue is that often in cases where Gulp seems simpler it really isn’t necessary (Why I Left Gulp and Grunt for npm Scripts (2016-Jan-17)).

Modern JavaScript for Dinosaurs gives an overview of using npm scripts and Webpack (see also How JavaScript bundlers work).

Aside: Here is an example where simple shell scripts are used to build a simple react application with browserify, babel-cli, watch, and uglify, cssshrink, jest-cli, babel-jest, react-addons-test-utils, eslint, eslint-plugin-react, eslint-plugin-babel, and flow-bin.

Now I don’t know whether that is the case here but I think often people try to choose a build tool before they fully understand the build process. I’m not saying that npm scripts are the be all and end all but they are likely the best way to get acquainted with the build process and as such can be pushed quite a ways. Once the build process is better understood and one’s needs are much clearer it should be easier to pick the right tool, be it webpack (SurviveJS - webpack), parcel, rollup.js or whatever.

Why not Webpack?

My impression was that one of the primary reasons for using Brunch in Phoenix was to have support for (ES) modules right out of the box as it allows for cleaner frontend dependency management. With that in mind you are going to need a bundler of some description.

It’s my personal preference to use ECMAScript rather than CommonJS/Node.js style JavaScript which bundlers manage so that makes Babel a requirement.

When sticking to a “npm script based” approach it’s important to start out just using the CLI features, with a file based approach.

There is usually a point where some features aren’t directly accessible via the CLI and you have to use the JS API to get the desired results - it’s probably at this point that some people start reaching for grunt/gulp. However I’ve found that the JS API documentation for many npm packages (plug-ins) is often lacking. For example with babelify it became necessary to dive into the index.js to find out how it used babel-core to determine that the ignore configuration actually supported “A glob, regex, or mixed array of both” rather than just a single regex.

This is probably the point where it becomes a bit easier to accept dealing with the Webpack even through it may seem incredibly complex. Browserify’s API is rather restrictive. Other packages like browserify-directory can help but at this point it starts to feel like you are creating some sort of Frankenstein. Webpack has a well developed ecosystem, so there are plenty of loaders and there is usually little reason to also reach for grunt/gulp (supporting npm scripts are usually enough). Again with Webpack it is important that you start small (SurviveJS). But now having experienced all the bits and pieces that go into a JS module toolchain it should be a bit easier to understand what Webpack is trying to accomplish.

The transition to Webpack isn’t mandatory. Having a basic understanding of the aspects of the JS module tool chain it should be much easier to transition to any other tool like Rollup.js or parcel. I think the biggest hurdle for beginners with Brunch was that they had no concept of what it was doing (because they had never used JS modules before) so they had no basis from which to understand the configuration process.

Trying to use something as restricted as Browserify exposes a lot of the moving pieces which helps to build your conceptual model of the build process. That is why I’m a bit sceptical with “zero config” claims like the one’s I hear for parcel. These things are usually “zero config” until they’re not. But because so far you’ve done “zero config” you have no concept or idea where to start when it comes time to do “some config”.