Core concept

Incremental builds.

During development, rebuilding everything after every edit is wasteful. Nift keeps track of what each generated file depends on so it can rebuild the outputs affected by your change instead of treating the whole project as dirty.

The everyday loop

# edit content/templates/assets...
nift build

# edit again...
nift build

With no tracked names supplied, nift build dispatches to the updated-build path. That makes the normal development command intentionally boring: edit something, build what changed, refresh.

A shared partial can affect many pages

templates/partials/header.html
            │
            ├── index
            ├── about
            ├── docs/getting-started
            └── docs/configuration

If those pages all include the header, Nift has enough dependency information to know they are affected when the header changes. A completely unrelated page does not need to be rebuilt just because it exists in the same project.

A content edit can stay local

content/about.html changed
        ↓
public/about.html rebuilt

content/contact.html unchanged
        ↓
public/contact.html left alone

That difference becomes increasingly valuable as a site grows from a handful of pages into hundreds, thousands or more.

Why it feels good during development

Build updated vs build all

# Normal development
nift build
# equivalent updated-build command
nift build-updated

# Deliberately rebuild every tracked output
nift build-all

build-all remains useful when you explicitly want a clean full pass—for example before measuring full-build performance or when you simply want every output regenerated. But it should not have to be your default response to every edit.

Continuous updated builds

nift build-auto

# choose the polling sleep interval in seconds
nift build-auto 0.5

This lets Nift keep checking for changes and rebuild updated outputs while you work.