JIjiaweihli·Mar 1, 2018
I went through a Makefile phase but ultimately setting on Jakefile[1] for more approachable syntax and type-checkability via TypeScript.
[1] https://github.com/jakejs/jake
In The Makefile I use with JavaScript projectsjakejs
jake
JavaScript2012–2018
jakejs / jake
jake
JavaScript build tool, similar to Make or Rake. Built to work with Node.js.
4Distinct people
5Mentions
0Explicit recommenders
2KGitHub stars
What to know before exploring
What it is
JavaScript build tool, similar to Make or Rake. Built to work with Node.js.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year5 dated mentions
Observed mentions: 2012-03-30 18:47:45 UTC to 2018-03-01 05:23:51 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
5 sourcesIf you're interested in file-based tools, Jake [1] has excellent support for the sort of rules Fez of offers, and is quite mature.
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-pro
Read the rest
ne 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
Gulp is an interesting idea, but I'm skeptical of its long-term viability. As Wintamute said in another thread, large projects have a lot of needs, and streaming isn't enough for all (most?) of them. Gulp's creators were pretty adamant about not supporting other use cases when this came up on Twitter. [1]
Another issue with Gulp is that it's highly concurrent. Although that seems like a nice idea for speed, I suspect it will lead to a lot of hard-to-write and hard-to-debug edge cases. I've already heard reports of people getting strange behavior from their Gulpfiles [2].
At this point, I'd take a "wait and see" approach with Gulp unless you like playing with build tools or if you really need its focus on speed. If you're looking for a good build tool for that lets you "just run JavaScript," I'd check out Jake [3] instead. And of course, G
Read the rest
runt [4] is the current leader for JS builds, thanks to its immense plugin library.
If you're interested in a more in-depth review of Gulp, I have one here: [5]
[1] The Twitter thread: https://twitter.com/funkytek/status/423762923421302784
[2] Somebody runs into strange behavior from Gulp: http://www.reddit.com/r/javascript/comments/1v4tez/bottom_li...
[3] Jake: https://github.com/mde/jake
[4] Grunt: http://gruntjs.com/
[5] My Gulp review: http://www.letscodejavascript.com/v3/comments/lab/1#comment-...
I'm not a fan of the format for gruntfiles (which is not to say I think it's objectively bad, just that it doesn't appeal to me personally). I much prefer using Jake as the build tool for my JS projects:
https://github.com/mde/jake
In Automating tasks with Grunt.jsJake is already a JS Make alternative, and it's already in use by a ton of projects- http://github.com/mde/jake
In Introducing Grunt