Brunch vs. Webpack

[javajosh]

Description

This is not a bug, it's more of a rant from someone who has spent the last few days getting Webpack to work, and only through this experience that I have come to appreciate what Brunch is, and how good it is in comparison.

Re webpack, the configuration format alone is truly awful. Webpack is enormous, and it's got different ways of doing the same thing, strange string delimiters (and faux URL parameters), strange requirements about './' in front of filenames. Not only that, but Webpack's apparent strength, the size of it's community, is actually a substantial weakness as examples tutorials and even core docs are out-of-date. Even the main tutorial linked from the Webpack site is dangerously, frustratingly out-of-date in a few key areas. E.g. it doesn't give the right instructions to install babel. Trial-and-error, making one small change, several combinations of changes, examining the build output, rinse, repeat, now repeat in combination with some other configuration change...the essence of useless tedium.

My overall impression of Webpack is of a giant, opaque mess held together by duct tape and bubble-gum. Getting source maps to work with sass was the stuff of nightmares.

And did I mention that it's slow? It's hard to appreciate the truly epic slowness until you've really experienced it, and tried (in vain) to make it go away. Don't get me started on Webpack's twisted approach to improving performance! The 'devtool' settings alone are ridiculous.

The Silver Lining

That said, the silver lining is that, although Brunch has it's warts, and it's docs aren't perfect either, and there are plenty of out-of-date tutorials out there (please, someone go and be "tutorial police" because honestly a bad tutorial is almost always far worse than no tutorial, mainly because it better not to be led than to be led astray), is a far better piece of software in basically every respect. I truly don't understand why Webpack (let alone gulp or grunt) have bigger communities. I fear that it's just that they don't know about Brunch, or suffer from "JavaScript fatigue" and don't want to try something new.

But I'm telling you, I'm going to use Webpack reconfiguration as a threat ("if you don't get that code on time you're going to have to add image processing with file globs to our webpack build!") as punishment for my devs when they do something wrong.

Why isn't Brunch more popular?

So, I haven't been using Brunch for that long (a couple months) and don't know the community, but I really wonder why the community is so small. Could it be the name? JavaScript fatigue? Brunch suffers from bad tutorials as well (although not nearly as badly as Webpack), could that be it? Well, it's a fine thing and I hope it gets more popular soon.

[adrianmcli]

Well Brunch didn't have NPM support until relatively recently. I think that's probably the number one thing holding it back since Webpack was sold to a lot of people as a way to use NPM packages for the front end.

For React users, Webpack also had Hot Module Replacement which was a huge boon and pushed a lot of new React users onto Webpack instead of considering anything else.

Brunch is also still having issues with some NPM packages. Bringing in static files from node module folders is not as straight-forward as I have written about elsewhere. NPM support is absolutely crucial IMO and I think that's the biggest thing holding it back.

[paulmillr]

The reason for small popularity is lack of marketing. Brunch is not getting mentioned by "big folks" even though it's been around since 2011 (Grunt appeared in Apr 2012).

We have been successfully using Brunch since that time in all sorts of production-grade applications.

Hot Module Replacement

We have this since this week.

[javajosh]

There are two features of Webpack that trouble me.I realize that it opens up a huge can of worms for Brunch. These are:
a) multiple entry-points, and
b) intelligent bundling.

The former is useful for site that are organized as a small collection of related SPAs (like mine, at my day job). Regarding the latter, Webpack's "CommonsChunkPlugin" is quite remarkable in it's ability to automatically extract common dependencies.

I question whether these features are actually needed. I'd almost rather have independent Brunch builds for each SPA, and avoid that plugin because I think it's bad practice to have so many dependencies that you require that kind of automation. But in truth, I recognize that I'm only so far along my journey into JavaScript front-end engineering, and so my ability to foresee the future is rather limited! In particular, I'm concerned about the complexity of maintaining several build files, even if they are as nice as brunch's.

I would greatly appreciate any wisdom you can share on these topics.

[goshacmd]

@paulmillr to be completely fair, we're not at Hot Module Replacement just yet. What we do have is a (somewhat hacky?) way to make hot React reload nevertheless work #1097 (comment)

[es128]

Regarding multiple entry-points - Brunch doesn't deal with entry-points at all, so the same concept can still be accomplished with the joinTo config. Webpack demands buying into the webpack-flavored commonjs module style, whereas with Brunch you explicitly define which files you want bundled together and your app structure is up to you. Arguably what webpack is doing is more sophisticated, but there is some more flexibility allowed from Brunch's approach.

[goshacmd]

Just as an update, brunch is also doing entry points now (with some limitations, including several entry points not being able to write to the same file if code splitting).

[IAMtheIAM]

Today is the first time I heard about Brunch. I just started using webpack a month ago and it's awesome. However, very difficult to configure and setup at first, even using repos. But once it's setup, its the bomb, primarily because of HOT MODULE REPLACEMENT aka "live reload" for HTML, JS, and SCSS/CSS/LESS.

What would bring Brunch into the frontline of the front end developer community is adding this feature, hot module replacement.

Without HMR, it will be very difficult to convince people already accustomed to it, to stop using it. How likely can this Brunch project gain hot module replacement?

Also, another big advantage of webpack is that is allows "lazy-loading" of all component files JS and CSS asynchronously, both in dev and in production. Does Brunch bring in lazy loading?

[goshacmd]

@IAMtheIAM brunch does in fact provide live reloading — for stylesheets since long ago, for js — since recently http://brunch.io/docs/using-modules#hot-module-replacement http://brunch.io/docs/why-brunch#brunch-vs-webpack

Lazy loading is not supported, and I'm not sure if it will. A feature like this would complicate brunch code base and probably make it slower, and that's the trade off to be made. (#1341)

[SOSANA]

@javajosh why has this been hidden from the community? I happen to stumble upon this after a friend of mine as been convincing me to jump ship to elixir/phoenix(hidden in docs) from node/mern. I think 2017 will be brunch's year :)

after finding brunch, my thoughts to grunt, browserify, gulp, broccoli, and especially webpack

Thanks Brunch team!
p.s - going to go on evangelist tirade for brunch support!

[akhnaz]

I start with browserify and gulp, then webpack and now discover brunch. It is awesome to use it out of the box with the skeleton. But, to configure it to what u like as the structure is not easy.

[fatcop]

I was fighting with Webpack trying to get a React webapp going and went with Brunch. So much easier.
But yeah, I found a while back there is some project structure you need to adhere to as I found out in this issue: #1519

[piglovesyou]

Is there css-loader implementation in Brunch? That's one of big achievements in Webpack, in which we can modulize css for components and minify css selectors in production.

[denysdovhan]

@piglovesyou there was a css-brunch plugin, but now it's deprecated. Brunch handles css stylesheets out of the box.

Try postcss-brunch for css-modules.

[piglovesyou]

@denysdovhan Thanks, I should have taken a look carefully at it. Great!

[towry]

If it not support lazy loading I will not use it. Tools should be used to solve many problems in real project, I think brunch should have a philosophy behind it and keep improving it to solve the real problems, do not compare it with other tools and tell people how brunch is different from Webpack etc. People will use it if it meet their needs and have some special merit. (my random thoughts)

[shvaikalesh]

We will have import() in 3.0.

[akvadrako]

I am deciding between brunch and webpack for a new project. I've used webpack a few times before, but it wasn't as flexible, simple or fast as I'd like. I see one major plus for brunch stated to be it's speed, but I can't find any benchmarks.

Why don't you highlight some benchmarks about how much faster brunch is?

[natewallis]

I am coming at this from both angles.

I am working on a PHP project and using webpack to ease the compilation of my assets and I have recently started dabbling with a phoenix based app which introduced me to brunch.

Before I started configuring webpack, I had read a few pages which had warnings along the lines of "brace yourself" in regards to the quality of the webpack documentation. I thought, "it can't be that bad"! They were right :)

It took a while, but I finally configured webpack for my project and it has definitely eased my development headaches of resolving dependencies for boostrap and other libraries I am using. But one thing I have noticed is that is can be slow to rebuild, but not always. It depends on which file you edit (I am running in watch mode). If its a minor change to a js file, then it can be done in half a second. If its a change to a SASS file to the top of your SASS tree, then it could be 5 seconds. This might be a configuration issue on my behalf as a beginner... but I guess there is no way of telling.

Rememer... "brace yourself" for the webpack docs. It took me a while to figure out which official webpack documentation page I should be looking at. Google search returns a few different pages and don't get distracted by what you think will be a helpful tutorial... My recommendation would be to start here:

https://webpack.js.org/guides/getting-started/

With that said, my time spent developing with Phoenix and Elixir has been the most fun I have had in a long time and I plan on spending most of my free time there for now. I was looking at swapping our brunch for webpack in my phoenix application, but I think I will hold off on that for now and just enjoy playing with phoenix.

[akhnaz]

@akvadrako

I see one major plus for brunch stated to be it's speed, but I can't find any benchmarks.

For my project, the same code base, brunch initial build take around 5s, and subsequent build take 400ms (0.4s). Webpack initial build take around 30s, and subsequent build take 2s. I am using babel with react.

I lost that speed now because currently i need to use webpack due to problem with postcss brunch and react-toolbox. Hopefully, when v3 is out, i will try to configure to brunch again.

[adyontech]

Is lazy-loading and web-workers concept can be handled with brunch + Please tell me why bundle size is smaller for brunch (coz I have heard it is 20-40% times smaller) ?
@javajosh @es128