
Brunch: Replace gulp, grunt and increase your dev speed - paulmillr
https://github.com/brunch/brunch-guide/blob/master/content/en/chapter01-whats-brunch.md
======
jorblume
The worst part about web dev is the amount of time spent investigating every
little new tool that comes out. It could be useful, it could not, how do you
know unless you investigate it yourself? You could easily spend 20+ hours a
week just evaluating tools. And not only that, but some of the most adopted
tool aren't performant. Grunt sucks. It really does. Angular is needlessly
confusing and overly complex for what it actually does. It also doesn't scale
and you need to get super hacky with it to perform properly. You spend more
time trying to learn new tools than you do actually coding, then find out the
tools aren't even well thought out.

Then what happens when you leave your position and someone comes in a year
later? Oooh, that sass preprocessor doesn't work? What's an angular, some kind
of measuring tool? The entire system has a "doesn't matter I'll be at the next
startup in 2 years" kind of feel to it.

I should really move into Java or C....

~~~
xixixao
The worst part about the comments under any "JS" submission is the amount of
time I have to spend to weed through all the "there are too many tools"
comments.

Brunch is older than Grunt and Gulp, how is your comment in any way relevant?
If this was a post about the advantages of Java over Go would you complain
about the amount of time you have to spend investigating various language
platforms?

The world is changing rapidly around us, whether we like it or not.

~~~
Semiapies
Yes, the endless complaining that something new-to-the-poster exists is the
most tedious aspect of HN. Nobody has time to look at anything new, but they
have plenty of time to bitch about it at length.

If people said to themselves, "Nope, don't have time to read some docs," and
went about their business without dropping coder angst-bombs, there might
actually be useful comments to read that would help someone decide whether
looking into Brunch or whatever was worth the time.

------
1235971235
Created an account for this post only.

As a novice javascript programmer, I am hugely confused by the variety of
tools being recommended on Hacker News. Choosing and setting up tooling was
harder than writing my first app in React. Not a new complaint, I know, but:

Is there anything like a best practice in modern javascript development that
someone can point me to? Or is there a site that gathers the setups used by
prominent front-end developers? Thanks for any advice.

~~~
wvenable
I'm an experienced web developer but most of my projects were started a decade
ago. I decided to use all modern tools and techniques for a very small (think
two database tables) application. It had to work on mobile and have a good UI.

And on my god, the tools, so many tools. And so much boilerplate. And so much
plumbing. I've spent only 50% of my time so far doing actual coding and the
remaining 50% configuring tools, pulling down packages, pulling down tools
which install other packages, and so on.

Now I will fully admit, the tools are very cool and the results are good but
it still feels a bit ridiculous.

~~~
simplify
I feel your pain; try this starter project I created in response
[https://github.com/mindeavor/node-
catapult](https://github.com/mindeavor/node-catapult) . It only has three
dependencies, yet it gives you a starting point to "npm install" in any
direction you need (in the front end too, since browserify lets you require
npm modules).

------
bryanlarsen
You definitely need a comparison with webpack. As far as I can tell from a
quick scan, webpack has all of the capabilities that brunch does. More
importantly, it's much more popular, so the plugins and help you need are
likely to be available.

~~~
graffitici
I agree that Webpack is a serious competitor, and it's rather odd to not even
mention it [1]. But I don't think Webpack does incremental compilation, since
it usually takes quite a long time for me to compile my modestly-sized
assets..

[1] [https://github.com/brunch/brunch-
guide/search?utf8=%E2%9C%93...](https://github.com/brunch/brunch-
guide/search?utf8=%E2%9C%93&q=webpack)

~~~
bryanlarsen
It does incremental compilation when run in dev server mode.

------
evmar
It looks like this document is a work in progress. Were you looking for
feedback on the document?

I have used build systems like this (and webpack) so I think I am the sort of
person you're looking to win over.

The heavy use of bolding makes this read like a pyramid scam and made it hard
for me to take it seriously.

In all documentation, my main feedback is: the more words you use, the less
you're respecting your reader. Your goal should be to wordsmith your text down
to convey the maximal information in the least space.

You spend a lot of words talking about things about your product rather than
talking about your product itself. I was also flabbergasted to discover that
popular build systems are not incremental but it'd be more useful to just
highlight the distinction and move on. I think it's ok to include a bit of
that in your blurb, but even in chapter three you're saying stuff like "We’ve
been preaching JS modules for six years" (again with the superfluous bold)
which is irrelevant to someone looking to understand what your system does.

For another example, you're asking your users to read three paragraphs of
"should I use a skeleton" discussion before ever even giving them any insight
into whether your system will work for them. I think you could shave that
section down to a sentence or two: (1) to get started, I recommend [X]; (2)
more experienced users will prefer a skeleton via the [Y] command [link here
to the full documentation].

Writing useful documentation is really hard. Good luck.

~~~
paulmillr
Thanks for feedback! We'll adjust some wording. We are always looking for ways
to improve the docs / product.

------
tdumitrescu
I've used brunch for a few years now and found it to be quite performant for
my personal projects. Once it's set up it just works smoothly. Getting it set
up though with the various plugins you need for your own build process can be
a bit of a headache sometimes, and I've felt hedged in at certain points by
its largely declarative config. I do think the benefits of its building and
caching system are worth it for the standard frontend workflow needs and wish
it had more mindshare/general community love.

~~~
_broody
Totally agree with you here. Brunch is fantastic for its minimal config
requirements and super-fast performance. Oddly enough, in the JS world I've
found it best to ignore all the hype around the latest and newest framework,
and just go with something that has a small and loyal following and stick with
it.

I mean, look at all the people who moved to working with Angular because it
was "made by Google, so you could trust it to stick around". Now those people
are using React, and soon they'll move to Angular 2. I've found that hyped
technologies almost never have a fraction of the robustness and staying power
that they claim to...

~~~
pluma
At the time I'd been as long with AngularJS as I have been with React now, I
despised AngularJS and wanted to violently murder past-me who decided to use
it.

With React I'm still as confident in my choice as I was a week into using it.
In fact, the more I get to know it, the more confident I grow. With AngularJS,
it was quite the opposite.

If anything I'd say that AngularJS being promoted by Google only made me more
cautious about technologies promoted by Google. Google doesn't actually
dogfood AngularJS. I know, they have some tool somewhere that uses it and
apparently there are people using that tool, but it's not nearly as customer-
facing as the code in which Facebook and Instagram use React.

But I didn't chose React because of the hype. In fact, AngularJS was still
being hyped when I decided to try React. I tried React because someone
recommend it to me and told me to give it five minutes of suspended judgement.
If I had gone by my first impression, JSX and Facebook both would have scared
me off.

~~~
agrippanux
I wrote Angular for 18 months and this is 100% the process I went through and
the decisions I came to.

------
jonahx
Also relevant, How to use npm as a build tool:

[http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-
tool...](http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/)

~~~
JohnSz
I'm rather impressed, especially after using npm for some 4 years without
considering this. Thanks.

------
untog
Show me the code!

There is a _lot_ of documentation here - which isn't a bad thing - but when
I'm assessing new tools like this I want to see the code I'll be using with
them. My reasons for disliking Grunt can be summed up just be looking at how
confusing/verbose the average Gruntfile is. An example of how I declare my
Brunch build would be invaluable.

~~~
Ygg2
Do these help?

[https://github.com/paulmillr/brunch-with-
chaplin/blob/master...](https://github.com/paulmillr/brunch-with-
chaplin/blob/master/brunch-config.coffee)
[https://gist.github.com/paulmillr/eb3ae139aadbbb87ab9b#file-...](https://gist.github.com/paulmillr/eb3ae139aadbbb87ab9b#file-
gulp-js)
[https://gist.github.com/paulmillr/eb3ae139aadbbb87ab9b#file-...](https://gist.github.com/paulmillr/eb3ae139aadbbb87ab9b#file-
grunt-js)

------
ajsharma
I do appreciate when tools/libraries take the time to explain the problem and
how they differ from their competition. Especially in cases like this, where
it's an underlying architecture difference.

The various Rake servers (Puma, Unicorn, etc.) have also done a great job of
this.

~~~
JonnieCache
_> The various Rake servers (Puma, Unicorn, etc.)_

nitpick: they're Rack servers. Rake is the ruby make.

------
latchkey
I like the configuration over code approach, but I feel like brunch swings too
much into the direction of configuration without being able to code. There
needs to be a middle ground because there will always be a need for
specialized tasks without having to rely on creating plugins.

I stuck with gulp, but got rid of the repetitive nature of declaring the same
task code over and over again by creating a centralized set of functions which
generate the tasks for me from configuration and a simple API to execute those
functions.

This had some other positive side effects, such as making my package.json and
gulpfile much smaller. I can also create fixes / features to tasks and all my
projects benefit immediately. The main downside to this centralization is that
if you need a specific version of a dependency, you have to fork my project
and update separately. That said, brunch effectively has this same issue.

A lot of the OP's complaints such as slow build times and incremental builds
can be solved with a proper pipeline in gulp, but it is harder than it should
be to do and really hard to do if you are copying a bunch of random tasks from
projects strewn all over the web. wtf is plumber? =)

Anyway, I published my little project if you're interested in using it. I use
it on a daily basis so it will be actively maintained for a long time to come.
I welcome PR's for additional tasks that you think others could use.

[https://github.com/lookfirst/gulp-helpers](https://github.com/lookfirst/gulp-
helpers)

[https://www.npmjs.com/package/gulp-
helpers](https://www.npmjs.com/package/gulp-helpers)

------
jypepin
We use grunt at work, and it starts to pain us. Now that our assets pipeline
got pretty big, our whole grunt built takes ~30 sec (+10s just for sass and
browserify, each).

I do feel like most of the slowness is the actual compile time though, not
because of grunt or whatever runs the compilation.

I'll try to implement brunch and see how it can outperform grunt on this.
Hopefully it will make it better!

~~~
ben336
If you're doing the whole thing every time, that would be your biggest
problem, regardless of tools. It sounds like Brunch does incremental builds
out of the box, which would definitely help you, but you can setup Grunt or
gulp to do the same thing. It just takes a little work.

We do that with gulp, and after the initial file runs (~8-10 seconds), updates
are instant every time.

------
mikewhy
have always been a huge fan of brunch but lately wanted to take advantage of
Gulp and Browserify ([https://github.com/mikew/browserify-
brunch](https://github.com/mikew/browserify-brunch) doesn't really cut it) so
I wrote parched[1] and parched-tasks-webapp[2]

[1]
[https://github.com/raisedmedia/parched](https://github.com/raisedmedia/parched)

[2] [https://github.com/raisedmedia/parched-tasks-
webapp](https://github.com/raisedmedia/parched-tasks-webapp)

~~~
cozuya
I haven't seen anything that matches what gulp can do to make both browserify
and babel have working sourcemaps.

~~~
mikewhy
It's a great combo. For a while though, Brunch did very similar things,
sourcemaps et al, with very little configuration (which is still very clever
when you need it).

With parched, the idea is very similar:

    
    
       npm install parched parched-tasks-webapp parched-babel
    

And you're good to go.

------
digitalzombie
Huh, I always thought Brunch was more of a Yeoman competitor than Grunt or
Gulp.

------
SippinLean
The odd bold emphasis on phrases, especially those deserving citation, makes
this feel and read like a spam site.

