I haven't dug deeply into Fez yet, but here's a few things Fez seems to offer that Jake doesn't:
1- Automatic concurrency. Like Gulp, Fez's subtasks run in parallel. It looks like Fez launches them in subprocesses in order to prevent conflicts, which is a good idea. I'm skeptical of parallelism in builds, though, because race conditions lead to nasty, hard-to-detect-and-fix bugs. I don't think the theoretical speed boost is worth the potential of defects getting into released code.
2- Automatic pipelining. Also like Gulp, Fez can pipe the output of one operation to the input of another. This is useful because you can avoid dealing with temporary files. Unlike Gulp, Fez has an extremely simple and non-error-prone way of constructing those pipelines. I like it.
The major advantage of Fez (and Jake) over Grunt and Gulp is that they use file timestamps to tell if a task needs to run. This can lead to major speed benefits. I recently modified my Jakefile to use this sort of dirty checking on my Sass compiler. I don't change my CSS that often, but the css task was doing an expensive "shell to Ruby" command on every build no matter what. Adding dirty checking shaved my typical build time down from 6.5s to 3.5s.
Overall, Fez looks like a really nice tool. It has a strong ideology (rule-based transformation of files) tempered by a nice dose of practicality. For example, although Fez wants every task to define a file-transformation rule, it also supports "imperative mode" for tasks that don't fit that model. It's very promising, and I'm looking forward to learning more.
[1] Jake: https://github.com/mde/jake
make, configure, automake, autoconf, MSBuild, Apache Ant, rake, gradle, jake, grunt, gulp, fez
Sorry, I'm sure your system is nice and organized. But now you've introduced one more build dependency that will make projects based on Fez just a little more difficult to on-board.
Fact is, people want different things from their tools. Each of the ones you mentioned has its own strengths and weaknesses. They tend to be better than their predecessors in some way, for some specific need. And this is how progress is made... via a thriving marketplace of [ build tools, languages, frameworks, libraries ]. I wouldn't have it any other way.
Also, I would prefer developers spend more time making general applications and less time making tools for other developers. I'm not saying people shouldn't make great dev tools, I'm saying more people should make great applications, and less people should make great dev tools.
1- Fez is more pragmatic. It has a strong ideology, but it also tempers that with escape hatches for when your needs don't fit that ideology.
2- Fez's pipelining is really simple and elegant. Gulp's pipelining is verbose and it's easy to forget to return the stream, which leads to race conditions.
3- Fez has dirty-checking so it won't run tasks on files that are up-to-date.
4- Task functions look much simpler to write (and thus, less error-prone).
I haven't tried Fez yet (and I have tried Gulp [1]), but I like what I see.
[1] My review of Gulp (wait for the comments to load): http://www.letscodejavascript.com/v3/comments/lab/1#comment-...
classes/**/*.class -> src/**/*.java:
javac [WHAT TO USE IF NOT A 'Maigc var'?]
1. Will fez support different dir for target and recipes? (like above example I gave) ?
2. What about targets that do not have a file dependency (e.g. .PHONY in make)? How does fez deal with it?
What I am trying to avoid is a big learning curve (or have a user need to read a book) :-)
Thank you and success in your project!
*.less → %f.css
*.css → %f.min.css
*.min.css → dist.min.css
If you are looking for a build tool, I strongly recommend you first consider a bash script.
Or if you are still looking for a build tool, like you collect them or something, I made my own too (lol): https://github.com/ithkuil/bild
Mine uses yaml files like this:
- coffee:
files: src/*.coffee
out: lib
- uglify:
files: public/js/*.js
out: public/js/min.jsI'm not a fan of Require-type systems because they introduce additional runtime behavior. With the proper dependency graph tools available at compile time, we could remove the need for AMD completely. This will reduce client overhead and boilerplate. (Granted, AMD boilerplate will be converted into a dependency graph spec. But it would be there regardless, and I am of the opinion that this is a superior form.)
Exciting times ahead...
See how Bud approaches building and watching changes; https://gist.github.com/azer/7819664
Second, one of the main features from my similar project (npm install webapp-builder) is appending a socket.io connection to generated HTML to force a browser refresh when files have finished building. I view webapp-builder as too monolithic, so I'm curious how difficult it would be to implement a similar feature in Fez?
2) You can do pretty much whatever sort of transformation you want in an operation. In fact, if you want I can take a look at your code and implement that socket.io appending feature with Fez myself just to show how it can be done.
"Brunch recompiles and concats all your stuff automatically on any change, headlessly. No more need in compicated Makefiles and watchers."
Perhaps I'm wrong, but Brunch just seems like a variant on Grunt with a lot more out of the box for building front-end web applications.
Still, it does look cool. Thanks for the link!
1. Did
2. Made
3. Built