Forem: KhaledSalem

Plugins Are Powerful. But They Shouldn’t Become Your Architecture.

KhaledSalem — Mon, 11 May 2026 16:27:53 +0000

Plugin systems are one of the reasons modern frontend tooling became so flexible.

Vite proved this extremely well.

A good plugin system lets a tool support frameworks, experiments, edge cases, and ecosystem creativity without forcing everything into the core.

But there is a point where something changes.

Plugins stop being extensions.

They become architecture.

And once foundational behavior lives across many plugin hooks, the cost is no longer just “install one more package”.

The cost becomes engineering complexity.

The plugin cost is not the package
When people talk about plugins, they usually talk about installation:

npm install plugin-name

But that is not the real cost.

The real cost is:

hook ordering
duplicated graph knowledge
dev/build parity
cache invalidation
transform boundaries
hidden runtime assumptions
debugging intermediate output
plugin compatibility across versions

A plugin can add a feature.

But if the feature affects the module graph, dependency identity, runtime behavior, or cache correctness, then the build engine needs to understand it deeply.

Not just call a hook and hope the result still makes sense.

Five features Ionify treats as native

Ionify is built around a simple idea:

Foundational build behavior should be understood by the engine, not reconstructed through plugin layers.

Here are five examples.

1. React should not need a plugin to start

In many frontend setups, React support is treated as a plugin concern.

That usually means JSX/TSX transforms, Fast Refresh wiring, runtime overlays, and production stripping need to be coordinated across the dev server and production build.

The engineering cost is not “React support”.

The cost is keeping these pieces consistent:

JSX/TSX transform behavior
Fast Refresh boundaries
error overlay/runtime injection
production-only stripping
dev/build parity

Ionify handles this natively.

React is not treated as an external behavior bolted onto the build.
The engine understands the React path directly, which means fewer moving parts before the app even starts.

2. Resolution should be one authority
Aliases, workspace paths, tsconfig paths, package exports, browser fields, peer dependency identity — these are not small details.

They define what a module is.

When resolution is spread across plugin layers, different parts of the toolchain can develop slightly different answers to the same question:

What does this import point to?

That creates painful bugs:

works in dev, fails in build
duplicate copies of a dependency
broken peer singletons
incorrect workspace resolution
alias behavior that differs from TypeScript

Ionify uses a native resolver with support for aliases, tsconfig / jsconfig paths, package exports/imports/browser fields, and workspace-aware ids.

The goal is simple:

One import should have one identity.

3. CommonJS compatibility should not be a guessing game
CommonJS is still everywhere.

The difficult part is not simply “convert CJS to ESM”.

The difficult part is recovering the shape of exports safely enough that browser ESM can consume it predictably.

Plugin-based CJS conversion can become expensive because it sits at the boundary between:

dependency optimization
dev-time ESM serving
production bundling
named export recovery
default export interop
cache correctness

Ionify handles CJS-to-browser-safe ESM natively in Rust, including export analysis and default/named export recovery.

That means CommonJS compatibility becomes part of the engine’s dependency model instead of an after-the-fact transform.

4. Dependency optimization should not be separate from the graph

Dependency optimization is one of the most important parts of modern frontend tooling.

It affects startup time, browser request counts, cache reuse, shared chunks, and vendor behavior.

The hidden cost appears when dependency optimization is treated as a separate pre-step instead of part of the engine’s persistent understanding of the project.

You end up asking:

Was this dependency already optimized?
Did the graph change?
Is this wrapper deterministic?
Can this output be reused?
Should this vendor pack be shared?
Why did this dependency rebuild?

Ionify treats dependency optimization as native graph work.

It has native /@deps optimization, deterministic dependency wrappers, shared chunks, vendor packs, and slimming.

The important part is not just speed.

The important part is that dependency optimization belongs to the same engine that understands the graph

5. CSS should have dev/build parity

CSS looks simple until it touches real applications.
Then you get:

PostCSS config
CSS Modules tokens
?inline
?raw
?url
?module
assets referenced from CSS
HMR behavior
production extraction
class name generation

The engineering cost is making all of that behave the same way in dev and build.

When CSS is handled through disconnected transforms, it is easy for one mode to understand something another mode does not.

Ionify handles core CSS, PostCSS, CSS Modules, and CSS query modes natively.

The goal is not to make CSS magical.
The goal is to make CSS boring.

Boring is good.
Boring means fewer surprises.

And more...

Those are only five examples.
Ionify also handles more build behavior natively, including:

static assets
images, fonts, SVGs, hashed build assets, and publicDir
build precompression with .br and .gz
compression manifests and compression CAS
SPA history fallback with internal/asset exclusions
.env, define, import.meta.env, and process.env.NODE_ENV
basic analyzer output through ionify analyze, build.stats.json, graph/deps/manifest authorities
manifest-driven ESM federation work, where the graph direction matters

Not every feature belongs in core.
But foundational behavior does.

The real difference: hooks vs understanding

A plugin hook can transform a file.

But the engine still has to answer deeper questions:

What changed?
What can be reused?
What depends on this?
Is this output still valid?
Is this module the same identity as before?
Does dev behavior match build behavior?

If the engine does not understand the feature, the plugin has to simulate that understanding from the outside.

That is where complexity grows.

Ionify’s bet is that many common build features should not be simulated from the outside.

They should be native engine concepts.

This is not anti-plugin

Plugins are still valuable.

There will always be project-specific needs, framework experiments, integrations, and custom behavior that should live outside the core.

But the foundation should be stable.

React startup, module identity, dependency optimization, CommonJS compatibility, CSS behavior, assets, env handling, federation, and build compression are not exotic edge cases.

They are daily build-system work.
Ionify tries to make that work native.
Less hook choreography.
Less duplicated graph logic.
Less rebuilding what the engine should already know.

The question

Where do you draw the line?
Which build features should be native to the engine, and which ones should stay as plugins?

I’m genuinely curious how other teams think about this.

The React Native Architecture Chain — Metro, Hermes, JSI, Yoga & Fabric

KhaledSalem — Sun, 10 May 2026 07:56:55 +0000

Most React Native devs use these five pieces every single day without knowing how they connect. Let's fix that.

🏗️ Build time — Metro

Metro is your only build-time actor. It takes your JSX/TS files, transforms them to plain JavaScript, resolves imports, tree-shakes, and bundles everything.

In dev mode → raw JS bundle.
In production → Hermes pre-compiles it to bytecode before it ships inside the app.

Think of Metro as Vite or Webpack, but purpose-built for React Native.

⚡ Runtime: JS layer — Hermes

Hermes receives the bundle and executes it on device. The key difference from V8: Hermes is AOT (Ahead-of-Time), not JIT.

By the time the app launches, the bytecode is already compiled. No parsing, no JIT warmup — execution starts immediately. That's where the startup speed win comes from.

🔗 Runtime: The bridge killer — JSI

When JS needs to talk to native code, it used to go through the old bridge — JSON-serialized messages passed asynchronously. Slow, unpredictable, and batched.

JSI (JavaScript Interface) replaces it entirely. JS now holds actual C++ host object references. Calls can be synchronous or asynchronous, and there's no serialization cost.

📐 Runtime: Native layer — Yoga + Fabric

JSI feeds two parallel systems:

Yoga — a C++ flexbox layout engine (built by Meta). It runs on the shadow thread, computing x, y, width, and height from your style props — completely off the main thread.

Fabric — the new concurrent renderer (also C++). It builds the native view tree and replaces the old UIManager bridge.

Both feed into the UI thread, which commits the final render to iOS UIKit or Android ViewGroups. Pixels hit the screen.

The flow in one line

Your code → Metro → JS bundle → Hermes → JSI → Yoga + Fabric → Native views → Screen

The new architecture isn't just a performance upgrade — it's a complete rethink of the JS ↔ native boundary.

Drop a question below if any layer is still unclear 👇

I Built a “Stateless” Frontend. Debugging It Nearly Broke Me.

KhaledSalem — Sat, 09 May 2026 21:58:22 +0000

I believed “stateless = simple”

Like many frontend engineers, I bought into the idea early.

No shared mutable state.
No surprises.
Just clean functions and predictable flows.

So I decided to go all in and build a frontend that was as stateless as possible.

It looked clean — until it wasn’t

At first, everything felt disciplined.

Then the app grew.

And “stateless” slowly turned into:

State duplicated across hooks
State mirrored in the URL
State cached, then reconstructed
State synchronized across tabs
State re‑derived after refreshes
State invalidated in multiple places

Nothing was explicitly wrong.
But nothing felt simple anymore.

Debugging became the real problem

Fixing a single UI bug meant answering questions like:

Is this value stale or recomputed?
Did an effect run twice?
Is this coming from cache or network?
Why does refreshing “fix” it?
Where is the source of truth?

The complexity wasn’t visible anymore — it was emergent.

The realization that changed everything

Stateless didn’t remove state.

It removed the ability to point at it.

Instead of saying:

“Here is the state.”

I had to reason:

“If these things run in the correct order, state should emerge.”

That works — until it doesn’t.

State wasn’t the enemy

The real issue wasn’t having state.

It was having implicit state that I wasn’t allowed to name.

At scale, that turned every bug into a guessing game.

That’s when I stopped asking:

“How do I eliminate state?”

And started asking:

“How do I make state explicit, boring, and easy to reason about?”

What I started doing differently

I began experimenting with an alternative approach:

Make state explicit
Make lifecycle boundaries clear
Treat persistence as first‑class
Make “where this comes from” obvious

The result wasn’t flashy.

It was boring.

And for the first time, boring felt like progress.

Why this led to Ionify

Ionify exists because we got tired of pretending.

Not pretending stateless is bad — but pretending it’s always simpler.

Ionify doesn’t reject stateless ideas.
It rejects hidden complexity.

Frontend Build Tools Are Hitting a Wall

KhaledSalem — Fri, 08 May 2026 20:14:19 +0000

For the last few years, frontend tooling has been obsessed with speed benchmarks.

Cold start.
HMR.
Bundle time.
Milliseconds everywhere.

Webpack optimized bundling.
Vite optimized development.
Rolldown is optimizing Rollup itself.

But almost every major tool still shares the same architectural assumption:

The build starts from zero.

That assumption worked when projects had hundreds of modules.
It starts breaking when projects have 10K+ modules, monorepos, AI-generated code, and nonstop rebuild cycles.

The problem is no longer “how fast can we transform code?”
The real question is:

Why are we transforming the same code again at all?

That’s the idea behind Ionify — a persistent frontend build engine built around a long-lived dependency graph and content-addressable storage.

Not a faster stateless runner.

A system that remembers.

Frontend Dev Tools in 2026: What Comes After Vite

KhaledSalem — Wed, 06 May 2026 17:08:29 +0000

The frontend ecosystem has quietly moved on. Your dev tool strategy probably hasn't caught up yet.

This is not a "Vite is dead" post. Vite is excellent. It earned its place. But in 2026, the baseline expectation for what a build engine should do has shifted — and if you haven't noticed, it's probably costing your team time every single day without a single error message to show for it.

The Vite Architecture Was a Great Answer to a 2020 Problem

When Vite arrived, it solved something real: Webpack was slow, config-heavy, and made development feel like punishment. Vite's answer was elegant — lean on native ES modules in the browser, skip the bundle during dev, use esbuild for speed.

It worked. It still works.

But there's a fundamental assumption baked into Vite's architecture that nobody talks about enough:

Every build starts from zero.

When you run vite build or spin up vite dev, here's what happens under the hood:

vite dev
  ↓
spin up esbuild/Rolldown
  ↓
plugin chain: TS plugin → JSX plugin → output
  ↓
main.tsx      → transform → output
utils.ts      → transform → output  
index.css     → transform → output
[every file]  → transform → output

The next time you run it? Same thing. All of it.

The TS plugin doesn't know the JSX plugin already processed a file yesterday. The bundler has no memory of which files changed since last time. The entire pipeline is stateless — by design.

And here's the real cost that nobody measures: the React plugin hook.

Every dev server start, every build — Vite needs @vitejs/plugin-react to hook React into the pipeline. That plugin intercepts the transform chain, injects Fast Refresh runtime, handles JSX compilation, manages the HMR boundary detection. It runs on every file. Every start. Every time.

On a small project, you don't feel it. On a project with thousands of modules and hundreds of dependencies, you feel it in your morning coffee going cold while you wait for the dev server.

On a +10K module, +25K deps React project: Vite build time — 2.4 seconds on a warm machine with aggressive caching config. Every. Single. Time.

That's not a bug. That's the architecture.

The Shift: From Stateless Pipeline to Persistent Engine

The 2026 mental model for build tooling isn't "how fast can we transform files."

It's "how much of this work can we never do again."

This is the insight Ionify was built on.

Ionify is built around a different assumption: most of the work you did last time is still valid.

Instead of transforming files, Ionify addresses them.

Every module gets a content hash. Same content + same config = same hash = skip the transform entirely. Not faster transforms. No transforms at all — for everything that hasn't changed.

module changes → BFS over reverse dependency index
→ find exactly which modules are affected
→ transform only those
→ everything else: CAS hit, served instantly

On a 500-module project, changing one utility file might only invalidate 12 modules. Not all 500.

The Four Layers of Memory

This is where Ionify gets architecturally interesting. It doesn't just "cache" — it persists intelligence across four distinct layers:

Layer 1 — Module Transform Cache
Every transformed module stored by content hash. If your code didn't change, the transform never runs — not just in this session, but across branches, across teammates, across CI.

Layer 2 — Deps Artifact Store
Your node_modules dependencies, pre-optimized and partitioned by a depsHash. A change in one library doesn't trigger full re-optimization of your entire dependency tree.

Layer 3 — Compression CAS
Brotli-11 + gzip-9 computed once, served forever. The compression work disappears after the first build.

Layer 4 — Chunk-Output CAS
Final build chunks stored by hash. In CI, if nothing changed, the output is assembled from cache — no rebuild at all.

React in 2026 Doesn't Need a Plugin to Start

Here's what the Ionify config looks like for a React project:

import { defineConfig } from "@ionify/ionify";

export default defineConfig({
  entry: "/src/main.tsx",
  optimizeDeps: {
    sharedChunks: "auto",
    vendorPacks: "auto",
    packSlimming: "auto",
  },
});

No @vitejs/plugin-react. No plugin chain. No hook. React's JSX, Fast Refresh, and HMR are handled natively by the engine — because in 2026, a build engine that doesn't understand React natively is leaving performance on the table.

The dev server and the production build use the same pipeline. One mental model. One config. No "why does this work in dev but break in build" mysteries.

The Numbers That Made Me Stop and Look Twice

Same project. Same machine. Same code.

Vite (Rolldown, optimized config) 2.4s and Ionify 124ms.

Ionify's warm build converges toward zero. The engine gets smarter the more you use it.

For a team running builds dozens of times a day, across engineers, across CI pipelines — that's not a 10x improvement. That's a category difference.

"But We've Got Caching Set Up in CI Already"

I hear this. And it's worth being precise about what CI caching actually does vs. what Ionify does.

CI caching (GitHub Actions cache, Turborepo, etc.) saves and restores directories between runs. It's filesystem-level. It works great for node_modules. For build outputs, it's coarse — cache hit or cache miss, nothing in between.

Ionify's CAS is module-level. A cache hit on a specific file's hash means that exact transform never runs, regardless of what else changed. You can change 3 files in a 10,000-module project and Ionify will transform exactly those 3 files. Not the whole project. Not the changed files plus their folder. Exactly those 3.

That's not a caching strategy. That's a different architecture.

The Cold Start (and What's Coming)

The team is working on something interesting here — cross-project CAS sharing. The idea: when you git clone a project and run ionify dev for the first time, the engine checks a shared remote CAS. If your teammates already built those exact modules (same content hash), you pull the transform artifacts instead of rebuilding them.

Warm builds for new engineers, from day one. The cold dead at the architecture level.

The 2026 State of Dev Tooling

The ecosystem has moved. The new baseline for a production build engine in 2026:

Persistent — the graph survives restarts
Content-addressed — transforms are tied to content, not time
Unified — dev and build use the same pipeline
Layered — multiple levels of memory, not one cache flag

Vite gave us the escape from Webpack. Ionify is the next escape — from the assumption that stateless is the only way to be simple.

Wise frontend teams in 2026 aren't asking "is my build fast enough." They're asking "how much of this build can we make permanent."

Try It

npm install @ionify/ionify

Docs and getting started: ionify.cloud

The config is intentionally small. The intelligence is in the engine.

The Real 2026 Frontend Revolution: Why Caching is Not Enough

KhaledSalem — Tue, 05 May 2026 11:39:11 +0000

Everyone is hyped about Vite 8 and AI tools, but let’s talk about the real bottleneck: Stateful vs Stateless builds.

Most tools today suffer from "Past Amnesia". You clone a repo, and you wait. You change a branch, and you wait.

Ionify changes the game with a Persistence Graph and CAS-first architecture.

Memory, not Cache: We built a memory layer that understands your project's journey.

Scalability: As your project grows, Ionify gets faster because it "learns" the relations between your modules.

Intelligence: Try the

ionify analyze
command to see how the engine perceives your dependency graph.

We are killing the "Cold Start" for good. Even for new clones.

https://ionify.cloud/

Your are still reprocessing the same modules. Every. Single. Time.

KhaledSalem — Sun, 03 May 2026 10:22:37 +0000

You are still waiting 40 seconds for a dev server that restarted.

Not because your machine is slow.
Not because your project is too large.

Because your build tool forgot everything it knew the moment the process exited

The pattern every frontend team accepts automatically:


# restart dev server
vite

# watch it reprocess 11,000 modules
# that haven't changed since yesterday

Three wasted phases — resolution, transformation, optimization — on code that the tool already understood. Every restart. Every CI run. Every branch switch.
The architectural flaw:

build starts → analyzes deps → transforms modules → exits
build starts → analyzes deps → transforms modules → exits
build starts → analyzes deps → transforms modules → exits

No memory. No accumulation. Just stateless execution on repeat.

What Ionify does instead:

build starts → checks persistent graph → retrieves CAS result → done

The dependency graph survives the process. The transformation result is stored by content hash. If the input hasn't changed — across restarts, across branches, across machines — the output is retrieved instantly.

Real things this removes from your pipeline:

Re-analysis of unchanged dependencies on every cold start
Tree-shaking running from scratch on modules it processed an hour ago
CI rebuilding what the previous run already computed
The 40-second gap between "I saved the file" and "I see the change"

What this gives you instead:

sub-100ms warm rebuilds on 11,000+ modules
One persistent graph shared across dev and production
Dep optimization that lives from the first cold start and never repeats

How many seconds does your build tool spend reprocessing code that hasn't changed?

pnpm create ionify@latest

⭐ [github.com/ionify](github.com/ionifyjs/ionify) · [ionify.cloud](https://ionify.cloud/)

Tree-Shaking is Over! Are you done with the limitations and repetition of traditional tree-shaking?

KhaledSalem — Sat, 02 May 2026 08:37:11 +0000

If you've used Vite, you know tree-shaking. It's fast, it's smart, and it runs on every single build — from scratch — every time. That's the part nobody talks about.

Today I want to introduce something we've been quietly building inside Ionify: packSlimming. It's our architectural answer to what tree-shaking actually costs at scale.

The problem with tree-shaking

Tree-shaking is a per-build operation. Every time your build tool runs, it re-analyzes your entire dependency. That analysis disappears when the process exits. Next run? Start over.

packSlimming: analysis that lives

packSlimming is backed by Ionify's persistent graph and CAS layer. Here's what that means concretely:

From your very first cold start, packSlimming analyzes your deps and stores the result. Every subsequent run — whether it's a dev server restart, a production build, or a CI run on the same branch — reuses that analysis. Your deps optimization is live from day one and never repeated unless something actually changes.

Ionify isn't trying to be the fastest version of what already exists. It's a different model entirely — a build engine that accumulates intelligence instead of discarding it.

pnpm create ionify@latest

⭐ github.com/ionifyjs/ionify
👉 ionify.cloud

We fixed a subtle HMR bug that was showing false build errors in Ionify

KhaledSalem — Wed, 29 Apr 2026 22:36:56 +0000

Small but satisfying fix shipped today. Worth writing up because the root cause is the kind of bug that's easy to misread as a client-side problem.

*What developers were seeing
*
During React Fast Refresh edits, Ionify would sometimes flash an Ionify Build Error overlay — even when the source edit was valid and the change was already visible in the UI. Confusing, because the build wasn't actually broken.

What was actually happening

The HMR server was treating each queued update as single-consumer state. The moment a client hit /apply for a given update ID, the server consumed and deleted that update.

In practice this meant: if multiple clients were connected, if an apply was attempted more than once, or if refresh timing raced against the same update ID — any attempt after the first would receive 404 Update not found. The client had no way to distinguish that from a real build failure, so it surfaced the error overlay.

The edit was fine. The UI had already updated. But the overlay said otherwise.

The fix

Pending HMR updates are now kept reusable for a short TTL instead of being deleted on first apply. Updates expire by age to keep memory bounded — so you don't accumulate stale state indefinitely, but valid late-arriving apply attempts no longer hit a 404.

Full issue and diff: https://github.com/ionifyjs/ionify/issues/2

In 2026 everyone is talking about AI-powered build tools.

KhaledSalem — Tue, 28 Apr 2026 09:05:36 +0000

In 2026 everyone is talking about AI-powered build tools.

But nobody is talking about the real bottleneck.

Your AI assistant generates code in milliseconds.
Then your build tool spends 40 seconds reprocessing modules it saw yesterday.

The bottleneck isn't your AI. It's your stateless build pipeline.

Ionify fixes the part everyone forgot:
→ Persistent dependency graph
→ CAS: every transform stored by content hash
→ 100ms warm rebuilds on 11k+ modules

Your AI deserves a build engine that keeps up.

Ionify is a Rust-powered build engine that approaches this differently. Instead of optimizing the stateless runner, we built a persistent engine.

⭐ github.com/ionifyjs/ionify
🌐 ionify.cloud

Why your build tool has amnesia — and how we fixed it with a persistent graph and CAS

KhaledSalem — Mon, 27 Apr 2026 14:39:43 +0000

Every few years, the frontend community rallies around a faster build tool.
Grunt gave way to Webpack. Webpack gave way to Parcel, then Rollup, then Vite. Each one measurably faster. Each one celebrated. And yet, there's a problem none of them ever touched: they all start from zero, every single time.

This isn't a performance problem. It's an architectural one.

The real issue: stateless pipelines

When a build process exits — whether that's a dev server restart, a CI run, or a branch switch — everything it computed disappears. The dependency graph it built? Gone. The transforms it ran? Gone. The structural knowledge of your project it accumulated? Gone.

We call this Past Amnesia. And on large projects, it's brutally expensive.

On a large-scale with 25,000+ dependencies, a cold start with today's best tools can cost 40–90 seconds. even vite-8 cost build 2.4 seconds. Not because the machine is slow. Because the tool is reprocessing modules it already analyzed last run, last hour, last week — with no memory of what it already knew.

What we built: Ionify
Ionify is a Rust-powered build engine that approaches this differently. Instead of optimizing the stateless runner, we built a persistent engine.

Persistent Dependency Graph
Module relationships are stored and survive process restarts. When you change a file, the engine re-enters the graph at the changed node — not at zero.

Content-Addressable Storage (CAS)
Every transformed module is stored by the hash of its input. If the input hasn't changed — across restarts, across branches, across machines — the transform is never repeated. The result is retrieved instantly.

Dual-hash isolation
A versionHash ties your graph and CAS to your current configuration. A depsHash partitions optimized dependencies so a single library update doesn't invalidate everything else.

Hybrid transform engine
OXC handles the fast path. SWC provides a resilience fallback.Same pipeline, both engines, no ecosystem compromises.

Unified dev + prod
Same engine, same semantics across both environments. The "works in dev, breaks in prod" class of bugs disappears by design.

The result
sub-100ms warm rebuilds on projects with 11,000+ internal modules. Not a benchmark trick — the natural outcome of a system that stops repeating work it already did.

Why this matters in 2026
Everyone is talking about AI-assisted development. AI generates code in seconds. But if your build pipeline costs 40 seconds every restart, you haven't solved the bottleneck — you've just moved it.

Ionify is the infrastructure layer that lets the rest of your toolchain actually compound. A build engine that gets smarter with every run, instead of forgetting everything when the process exits

Try it

pnpm create ionify@latest

Scaffolds a fully configured environment in seconds.

🌐 ionify.cloud
⭐ github.com/ionifyjs/ionify

Happy to answer questions about the graph model, the CAS design, or the OXC+SWC hybrid decision in the comments

Why Your Build Tool Keeps Rebuilding Everything (And How I Fixed It)

KhaledSalem — Sat, 25 Apr 2026 11:51:44 +0000

Let’s be honest.

Every time you run a build, your tool forgets everything it did before.

Even if nothing changed.

Even if you just ran it seconds ago.

That’s not optimization.
That’s amnesia.

After 10+ years working in frontend, I got tired of this model — so I built Ionify.

I tested a real project with:

11K+ modules
25K+ dependencies

Vite:
→ ~2.4s

Ionify:
→ 124ms

The difference isn’t faster compilation.

The difference is memory.

Ionify uses:

Persistent dependency graph
Content-addressable storage (CAS)

Instead of rebuilding everything,
it reuses everything.

If you're curious, try it yourself:

https://ionify.cloud/