Brunch vs. Webpack #1234

Open
javajosh opened this Issue Mar 16, 2016 · 11 comments

Projects

None yet

9 participants

@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
Member

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.

@goshakkk
Member

@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
Member
es128 commented Mar 16, 2016

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.

@goshakkk
Member

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).

@paulmillr paulmillr added the docs label May 16, 2016
@IAMtheIAM
IAMtheIAM commented Jun 3, 2016 edited

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?

@goshakkk
Member
goshakkk commented Jun 3, 2016

@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
SOSANA commented Dec 1, 2016 edited

@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
fu

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

@akhnaz
akhnaz commented Jan 13, 2017

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
fatcop commented Jan 13, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment