2,647
pages tracked
The complete static distribution, not a homepage-only demonstration.
A feasibility study · September 2026
What happens when an agent rewrites Omarchy’s Astro site with Nift?
We rebuilt a 2,647-page production-shaped website around Nift templates, retained React only for the elaborate animated showcases, and measured the result. The experiment was fast, messy, revealing—and considerably more successful than the first prototype.
Read this first. This was a quick agentic feasibility experiment, not a proposed production migration. The final page closely reproduced the original, but a production rewrite would require deliberate content modelling, accessibility and cross-browser QA, visual regression testing, and further source refactoring.
At a glance
A much smaller build surface
0.490s
complete Nift build
Median including the deliberately limited React animation bundle.
50.6 MiB
peak build memory
Versus approximately 1,019 MiB for the original Astro build.
19 MiB
installed Node modules
Versus 676 MiB in the original Astro checkout.
Measured results
Same site shape, radically different build profile
Five warmed runs were collected in the same container. Medians are shown. Peak RSS is the maximum resident memory reported for the build process tree.
| Workflow | Median | Peak RSS | What it represents |
|---|---|---|---|
| Nift no-op check | 0.136s | 8.3 MiB | Dependency/status pass; no output required rebuilding. |
| Nift one-page edit | 0.154s | 8.3 MiB | The common content, template, data, or path iteration loop. |
| Nift forced full render | 0.245s | 17.0 MiB | All 2,647 tracked pages rendered; island bundle unchanged. |
| Nift + React island | 0.490s | 50.6 MiB | Benchmark checkpoint: island bundle plus a forced render of every page. |
| Original Astro | 5.007s | 1,018.6 MiB | Original production build on the same benchmark machine. |
10.2×
faster complete production build
Astro’s 5.007s median versus 0.490s for the Nift render plus React-island bundle.
lower peak memory
About 1,019 MiB for Astro versus 50.6 MiB for the complete Nift production build.
32.5×
faster typical development build
A one-page Nift iteration took 0.154s versus 5.007s for Astro’s measured build command.
lower peak memory during that iteration
The Nift edit used about 8.3 MiB versus approximately 1,019 MiB for the measured Astro build.
The development comparison reflects the commands each workflow normally needs after a content/template edit: Nift incrementally rebuilt the affected page, whereas the measured Astro build regenerated the project. It is intentionally labelled separately from the forced full-render comparison.
The output validator is reported separately because the original Astro timing did not include an equivalent post-build crawler. Adding Nift’s independent 9,531-reference audit brought its full checkpoint to 1.402s. Absolute timings are hardware-specific.
Independent machine observation
The checked build remained extremely fast on a NUC
On a roughly 20-core Intel NUC12, the final project—with 10,503 @pathto calls—reported 0.085s for a no-op build and 0.150s for rebuilding all 2,647 pages.
This is not a direct Astro comparison because Astro was not rerun on that machine. It is useful evidence that thousands of explicit path contracts did not erase Nift’s speed advantage.
$ nift build
✓ 2647 tracked files are up to date
time taken: 0.085204 seconds
$ nift build --all
📦 2647 files built successfully
time taken: 0.149989 secondsDeveloper experience
The meaningful difference was iteration, not syntax
Both codebases can produce an excellent website. The contrast is where complexity lives and how much machinery must wake up after an edit.
Ordinary iteration
Nift rewrite
The same nift build command is used in development and production. It checks the graph and renders only affected pages; most edits do not wake Node or rebuild the island.
Original Astro
The framework build owns page generation, component compilation, integrations, and client assets together.
Architecture
Nift rewrite
HTML templates and JSON own static structure. Ordinary JavaScript owns small interactions. React is constrained to animation lifecycle and coordinated showcase state.
Original Astro
Astro components organise the site and integrate React components through the framework’s island model.
Dependency surface
Nift rewrite
One small native executable plus 30 Node lockfile entries for the optional React island bundle.
Original Astro
A familiar JavaScript toolchain with 794 lockfile entries and a much larger installed dependency tree.
Path safety
Nift rewrite
@pathto turns page and asset relationships into checked build requirements, supplemented by a final-output audit.
Original Astro
Asset and route correctness comes from framework conventions, module imports, integrations, and whatever additional link checking the project configures.
Source maturity
Nift rewrite
A successful but crude prototype. Its repeated theme UI and route families are structured; more extracted HTML should still be refactored.
Original Astro
The established upstream implementation, with mature source organisation and production history.
Onboarding
Nift rewrite
A small model that is quick to inspect, but a smaller community and less accumulated team familiarity.
Original Astro
Broader familiarity, documentation, integrations, examples, and an existing pool of experienced developers.
Installed footprint
A 35× smaller Node installation
The Nift executable itself was approximately 1.6 MiB. Node remained only to bundle the limited React animation island.
Correctness contracts
Fast should not mean fragile
The final revision moved local relationships out of unchecked strings and into Nift’s dependency graph.
@pathto calls
Internal pages, styles, scripts, images, media, WASM, and island-provided URLs resolve through Nift.
recorded requirements
Nift metadata captures build relationships across 1,259 unique targets.
references audited
An independent output check covered literal local references in generated HTML, CSS, and JavaScript.
missing targets
The final generated-output audit completed without a broken local relationship.
Structured content
@json(site_themes, "content/sites/omarchy/data/site-themes.json")
@for(theme : site_themes){
<button data-preview="@pathto('public/assets/images/theme-previews/$[theme.id].webp')">
$[theme.name]
</button>
}Normal edit loop
# Content, template, data, or path change
$ nift build
# Only when the animation island changes
$ npm run build:islands
$ nift buildAI-DX
Small explicit systems are unusually legible to agents
Nift’s strongest agentic quality was not that an agent never made mistakes—we made several. It was that the build model was compact enough to recover quickly: content, templates, data, tracked pages, and explicit path requirements.
An agent could inspect the whole architecture, change one section, rebuild one affected page, and receive an immediate dependency error. There was less framework-specific indirection to rediscover between iterations.
Short feedback loops
A one-page edit rebuilt in roughly 0.15 seconds in the constrained container. Fast verification changes how often an agent can afford to check its work.
Explicit relationships
@input, @json, and @pathto state dependencies close to their use. The build can explain why a page is stale or reject a missing target.
Low context tax
The central model fits into a small mental map. Agents spend fewer tokens rediscovering framework lifecycle and configuration layers.
No immunity from mistakes
The agent still produced visual mismatches and JavaScript integration regressions. Nift made fixes cheap; it did not replace acceptance testing.
Reproducibility
What was compared—and what was not
Complete build from a clean checkout
Install the island’s deliberately small Node dependency set, bundle that island, then let Nift build every output it determines is stale.
nift build is the production build command. Its dependency and path contracts make forcing every page unnecessary; nift build --all was used only to measure worst-case full rendering.
$ npm ci
$ npm run build:islands
$ nift build
✓ 2647 tracked files are up to dateThe reverse-direction test
How difficult would it be to reconstruct an Astro project from the Nift rewrite?
A crude output-equivalent port would be easy. An agent could place the generated HTML and existing browser assets behind an Astro page quickly. That would prove very little—just as the first simplified Nift attempt proved very little. It would use Astro as a wrapper rather than recreate an idiomatic Astro codebase.
A maintainable, idiomatic reconstruction would be materially harder. Starting from the Nift source alone, the agent would need to invent Astro component boundaries, layouts, content collections or data loaders, framework configuration, asset conventions, and React hydration directives; translate Nift’s tracked-page graph and 10,503 path contracts; then verify that those new abstractions still produce the same 2,647 routes and interactive homepage.
My reasoned estimate is roughly 2–3× the implementation and verification effort of this Nift experiment. That is an engineering estimate, not a timed benchmark. The asymmetry comes from expanding a small explicit build model into more framework-specific structure, not from Astro being incapable of reproducing the site.
There is an important qualification: the real original Astro repository already exists. Reusing it would obviously be easier than reverse-engineering Astro from the Nift rewrite. The hypothetical is useful because it asks how much information and architecture each finished codebase makes an agent reconstruct when moving in the other direction.
- 01
Match the actual scope
Both implementations were evaluated as complete 2,647-page sites. The first simplified-homepage attempt was rejected as an invalid comparison.
- 02
Restore visual and interactive behaviour
The homepage was iterated against the live Omarchy site, including its pixel hero, mouse interaction, theme showcase, music, and draggable rails.
- 03
Move structure into Nift
Homepage sections, redirect families, repeated theme data, and internal relationships were moved into templates, JSON, loops, inputs, and path contracts.
- 04
Measure warmed builds
Five runs were collected for each workflow and medians reported. Astro and the comparable Nift production build ran in the same constrained environment.
- 05
Validate the output
Nift status confirmed every tracked page current, while an independent audit resolved local HTML, CSS, and JavaScript references against generated files.
Limitations worth keeping visible
- Total human-and-agent development time was not instrumented, so no precise rewrite-duration claim is made.
- The experiment converged through visual feedback, but did not finish a production-grade screenshot-diff matrix across browsers and viewports.
- The current source still contains extracted page HTML that should be further modelled into reusable templates and structured content.
- The benchmark compares build systems and dependency footprints, not runtime superiority of one UI framework over another.
- The experiment’s early revisions were materially wrong. That history is evidence for stronger visual acceptance tests, not something to hide.
Where each approach fits
Nift does not need to replace the application stack
Nift is especially compelling for
- content-heavy sites and documentation
- large static route sets
- projects valuing tiny, deterministic build tooling
- server-rendered systems needing a template and dependency layer
- sites with a few focused interactive islands
- agent-maintained repositories where explicitness matters
Astro remains a natural choice when
- a team already relies on its component ecosystem
- framework-component integration is the organising model
- existing adapters and conventions reduce organisational risk
- the additional Node dependency surface is acceptable
- the project benefits more from established familiarity than minimal machinery
Conclusion
Promising enough to justify a serious second pass
The experiment does not prove that Omarchy should migrate. It does show that Nift can own a complex, visually distinctive static site while leaving sophisticated browser interaction to a small React island—and do so with dramatically less build time, memory, and installed tooling.
The next useful step is not to ship this prototype. It is to let independent agents and maintainers examine the Nift implementation, Nift’s source and test suites, and the original Astro codebase; define production acceptance criteria; then see whether a planned rewrite preserves the advantages under stricter engineering conditions.