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.
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.
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.
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
Hot Module Replacement
We have this since this week.
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 would greatly appreciate any wisdom you can share on these topics.
@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)
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.
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).
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?
@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)
@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!
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.
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