Up: Nanoc
Nanoc is over thirteen years old at the time of writing, which is a long time in the world of software. Over this extended period of time, I have gained a good deal of insight of what works, and — more importantly — what does not work so well when building a static-site generator.
The purpose of the analysis in these notes is not just to make Nanoc better, but to serve as reference for future work on static-site generators, either by me or others. Note that these notes do not create commitment from me (or anyone else) to solve the problems listed.
In no particular order:
- Nanoc needs --json so that the CLI can be used programmatically
- Nanoc’s use of Ruby is not an appealing choice these days
- A globally available filesystem prevents access tracing
- Nanoc sites take too long to load
- Nanoc’s in-memory approach limits scalability
- The web tooling in the Node ecosystem is closed
- Nanoc’s preprocessor hinders optimization
- Nanoc’s live recompilation is inefficient
- Nanoc’s lack of parallelism slows down compilation
- Too easy in Nanoc to get undefined behavior
- It is hard in Nanoc to use reusable view components
- Embedded plaintext metadata formats
- Nanoc needs file paths to be known before compilation starts
- Nanoc’s terminology is inconsistent with the industry
- Checking and deployment does not belong in Nanoc
- Creating synthetic pages in Nanoc is awkward
See also: Nanoc 5.