I was using `grunt` and `gulp` to build Node.js and AngularJS projects but I have to tell even boot 1.0 felt like a great step forward compared to them, despite of the abysmal startup times.
It allowed us to just jump into Clojure development from one day to the other while understanding what is the build system doing. I can't tell the same about the prepackaged grunt and gulp files which come with certain key-turn projects.
I've worked extensively with both grunt and gulp for the past couple of years (I've even written gulp plugins![1][2]), and I'm still shocked at how bad the tooling is compared to ruby (rails asset pipeline / sprockets) and clojure (leiningen, chestnut, etc.).
For example, here is a simple gulpfile for a livereload environment that compiles sass and coffeescript [3]. It's over 500 lines long, and it requires extensive knowledge of at least 20 plugins. And half of those plugins are there to address the shortcomings of other plugins, or of gulp itself [4].
But really the worst part is that every time some dependency of a dependency pushes a point release, it breaks the entire build. My team has resorted to passing around a stable `node_modules` dropbox folder. I'm literally terrified to run npm update!
Anyway boot looks cool, I can't wait to try it out :)
Have you taken a look at broccoli[1]? We ran across it after going the Fileset route, but were refreshed to see that it also does a kind of Fileset thing (they call them "trees")[2]. I don't know much more about it other than that it's what's underneath ember-cli, and the Ember people do a lot of good work in tools realm. Anyway, it could be a way for you to realize some of the niceties of the boot approach over in JS-land.
"Build workflows necessarily involve the filesystem because it's not practical to send file contents around in memory as function arguments, and because we want to be able to leverage existing JVM tooling that generally operates on things in the class path and not on in-memory data structures."
so like unix pipes? What exactly is impractical about passing big values as function arguments? Isn't that how gulp works?
Well, there are two things there: the unbounded potential size of files and the ability to coexist in the current JVM ecosystem without rewriting every bit of code that looks for things on the class path.
I think that generally the files you're dealing with will fit in memory, but you still wouldn't probably want to have everything in memory all the time, you'd need to stream them (consider an uberjar that's 10M as a JAR, but might contain contents that are 10x that size uncompressed).
This brings us to the second point. No existing JVM tools are prepared to accept files via pipes. Tooling on the JVM looks for things on the class path and in JAR files. We definitely don't want to have to rewrite every tool to use some in-memory pipe system.
The fileset and pod abstractions provided by boot work together to give you the best of both worlds--an immutable representation of the filesystem and class path combined with full interop with the existing JVM ecosystem.
Another issue with Unix pipes is that they are not awesome for tree-like things. In bash you pipe lines of text from one program to another, but tree processing is very difficult. Consider xml processing by pipes, or my jsawk library for processing JSON in the shell. These suffer from memory issues because it's hard to stream trees (if you have a 2G JSON file that is a single object jsawk can't even read it in).
Actually I should mention that perhaps the wording in the passage you quoted is misleading. We don't send the actual file contents around in memory as function arguments, but the fileset object itself _is_ passed in memory as an argument, and this fileset object contains the metadata you need to perform your work. When you need the contents of the file there are protocol methods for obtaining the underling file contents, and the actual underlying files are completely anonymous temp files of no special significance (their specific locations in the filesystem are irrelevant to the build process).
Interesting that a fileset concept has emerged. I would draw parallels with Ant, but this project seems to have already zoomed past ant for ease of use. Can boot be used to build pure java projects as well?
I don't see why not. There is a javac task included with the built-in tasks that ship with boot itself, but boot is designed for ease of extension so you can write tasks to implement your particular workflow. You can even write tasks that use Ant or Maven in a pod (pods are a sort of first-class implementation of isolated classloaders in which work can be done). We even have a jRuby task now that can be used as a component of a Ruby build pipeline, so yes, I think boot would be a great way to build Java projects!
It allowed us to just jump into Clojure development from one day to the other while understanding what is the build system doing. I can't tell the same about the prepackaged grunt and gulp files which come with certain key-turn projects.