Think about what happens to Vite's knowledge of your app after a build.
It disappears.
The dependency graph it just constructed — gone. The module relationships it traced — gone. The vendor boundaries it calculated — gone. Next build, it starts over. From zero. With no memory of anything, it just learned.
Every deploy, Vite is as smart as it was on day one.
What compounding build intelligence actually means
Ionify persists the dependency graph across runs. That's the headline.
But the deeper thing is what that persistence enables over time.
The graph accumulates route history — which modules get requested together, which vendor packages appear on which routes, which closures are shared across navigations. That knowledge doesn't come from a single build. It comes from observing your app across many builds, many runs, many real navigations.
A build tool that runs once knows your code.
A build engine that persists knows your app.
The difference shows up in the output:
Vendor requests: 46 → 9 (−80%)
Bytes transferred: 1.8MB → 420KB (−76%)
Parse time saved: 120ms
That's not from a smarter algorithm on a single run. That's from route-aware vendor packs built from accumulated graph intelligence — knowing which dependencies actually appear together at runtime, not just at build time.
The cold vs warm gap tells the real story
Ionify cold: 52ms (full precompression included)
Ionify warm: 30ms (CAS hits + graph reuse)
Vite cold: 111ms (no precompression)
Vite warm: 110ms (full retransform, every time)
Vite's cold and warm are nearly identical. That's not a coincidence — it's the architecture. Vite has nothing to reuse, so every run costs roughly the same.
Ionify's warm is 42% faster than cold. That gap is the value of memory. And it grows as the graph stabilizes.
Why CAS changes the multi-machine equation
Content-addressable storage means artifacts are keyed by what they contain, not when they were produced.
Practical consequence: if your CI machine and your dev machine built the same module with the same inputs — they produced the same CAS key. One machine's work is reusable by the other.
Traditional tools: every machine rebuilds independently.
Ionify: the team shares a build cache without any explicit cache configuration.
The browser side nobody talks about
After any deploy, Vite users re-download ~479 KB — vendor code, React runtime, shared utilities, all of it — because the build output changed and the browser has no way to know what part changed.
Ionify splits output by cache lifetime:
| Chunk | Changes when |
|---|---|
chunk-vendor |
You update a dependency |
chunk-shared |
You refactor shared utilities |
chunk-entry |
Every deploy |
After a bugfix deploy: chunk-entry changes (10 KB). Everything else stays cached.
Users re-download 10 KB. Not 479 KB.
This isn't "Vite but faster"
Vite optimizes a single build run.
Ionify optimizes the relationship between runs.
That's a different problem. And it compounds.
→ github.com/ionifyjs/ionify ⭐
Ionify — The Build Engine That Doesn’t Start Over
Ionify is a Rust-powered build engine with a persistent dependency graph and content-addressable cache. One unified pipeline for dev, build, and test.
ionify.cloud
Top comments (0)