HN2new | past | comments | ask | show | jobs | submitlogin

Having used literally ever alternative, Broccoli has been a joy to use so far, can wait to port all my projects to it.

It manages complexity really well. I have thrown many known failure scenarios at it, and it handled them all without a hitch.



I was about to move over to Gulp. Can you let me know why you prefer Broccoli over Gulp?


I also wonder how it compares to Gulp (mainly in terms of performance in practice). I've just started to use Gulp, migrating away from Sprockets and so far it has been a joy.


fast builds isn't the entire broccoli offering, I would trade slow builds for accurate consistent and durable builds, amazingly with broccoli I get both.

I actually do not believe grunt/gulp vs broccoli makes terribly much sense to compare as broccoli aims to be a accurate/stable/fast build pipeline, it does not aim to replace your task runner. It's primary goal is to be the best possible build pipeline, and should be programmatically accessible to your existing task runner.

Anyways, since I didn't really compare grunt/gulp with broccoli, let me explain what you get:

* primitives make sense, was able to get a fairly non-trivial or ordinary pipeline setup really quickly

* builds so fast, you don't notice them.

* accurately handles changes (deletions and git branch changes tend to often cause similar tools issues)

* doesn't lose changes that occur while building

* true pipeline. eg. describe the transforms, and the system handles the rest. No needing to construct make-shift pipelines yourself

* immediately usable as server (error reporting, locking)

* development builds.

* minified source mapped production builds.

* the Broccolifile API is well suited for constructing custom piplines

And finally:

the above you essentially get for free, if you need customizations the Broccoli file provides are an API well suited for the task.


As the author mentions, the real insight seems to be to switch from the file-based unit to the tree-based unit. This means asset building can be made more intelligent.

Now, I wonder if the same approach can be taken in gulp using vinyl-fs? Otherwise, I wonder if it might be worth plugging this tool as a specialized asset pipeline into existing grunt/gulp files.


I have been working on replacing the whole production build pipeline as well. And since Grunt isn't a thing you can ignore these days I created a simple grunt wrapper that collapses the entire 200+ lines of config down to two config options: https://github.com/Munter/grunt-reduce


I would be an advocate of this.

But.. competition is healthy, I am glad we are getting some great solutions in the space.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: