Moving right along, the next talk was from Jo Liss about Broccoli. Broccoli is a js build tool. The goal of broccoli is to have an architecture that allows faster build reloads. The session was broken up into three parts. First, how to write a broccoli build definition. Second, sketch out the broccoli api. Third, how broccoli integrates.

Broccoli definitions are in the brocfile.js. the broccoli plugin has support for lots of other things as well including coffeescript. When you run the build in broccoli, it outputs a new tree and then to export you just call merge trees which pulls the css and js files into one tree.

The broccoli api is a simple one. Broccoli only knows trees which can be represented by a string in the directory or an object. This object has two functions, the read function and the cleanup function. The read function returns a directory (or a tree). The tree will be called and read repeatedly to build and then at the end, cleanup will be called. The api is tiny and the goal is to keep it small and more over things into helper packages. One example of a helper package is broccoli-transform. Another is broccoli- filter which works with a 1:1 relationships. This package implements the 1:1 relationship of input to output files. It also has cache so you don’t have to recompile everything all the time.

Finally, there was a discussion on integration. Broccoli is a small library and there is a need for broccoli to provide a good api so that it can be integrated into more tools. Broccoli does integrate with the back end as well.

I’ve got a lot to read about broccoli in order to fully understand it but I felt like this session gave me a good overview and some interesting places to dive in a little further. Since, I’ve got a better understanding that broccoli is like a rake task in ruby or the asset pipeline in rails. Broccoli is important because as your application grows, the amount of time it takes to reload a build grows. If you want to easily edit files and then reload the browser, you don’t want to have to rebuild everything in order to see the changes. I haven’t used grunt (a task-runner tool) before but there seems to be a lot of information about how when editing files, there are lots of complications and dependencies that can quickly build up and make just reloading the files you’ve changed a poor solution. But with broccoli, it tracks the files you are changing and these dependencies and rebuilds only the ones that need rebuilding so your build time is faster. I think sections 4 and 5 of this link do an excellent job providing a little more background and detail on this.

Next step for me, I think, is to dive into this post a little further: http://ampersate.com/getting-started-with-broccoli-and-emberjs