DEV Community: KhaledSalem

Your build tool has amnesia. I built one that remembers.

KhaledSalem — Fri, 26 Jun 2026 19:07:07 +0000

This is not a "Vite is dead" post. I love Vite. It's the reason dev servers stopped being painful. What I'm about to describe doesn't make Vite worse — it points at something every fast build tool still does, including the Rust ones.

Here it is: your build tool has amnesia.

Every layer of computing eventually learned the same lesson — stop redoing work you've already done:

CPUs → caches
Databases → indexes & materialized views
Networks → the CDN
Compilers → incremental compilation
The frontend → memoization & query caches

One layer never learned it: the build.

Every build rediscovers the same dependency behavior, re-transforms the same modules, and rebuilds the same artifacts — from near zero. Vite, Rollup, esbuild, even Turbopack and Rspack made each run faster. But each run still starts from nothing. They optimized the speed of forgetting.

Ionify is what happens when you refuse to accept that.

Not a faster bundler — a different category

Ionify is a Rust-powered build engine that replaces disposable execution with persistent build intelligence. Instead of rediscovering dependency behavior and rebuilding the same artifacts every time, it persists the project's knowledge — the dependency graph, transformed artifacts, dependency contracts — and reuses valid work across dev, CI, and production.

The shift is from build execution to build intelligence. Execution throws its knowledge away after every run. Intelligence keeps it.

The number

On a real production app — 11,000+ modules, 25,000+ dependencies — Ionify produces a warm build in 196ms, deterministically. The number isn't the headline; it's the proof the model works at scale.

What's actually persisted and reused:

Capability	Status
Persistent dependency graph	Stable
Content-Addressable Storage (CAS)	Stable
Native dependency resolver	Stable
Dependency Publication Layer (DPL)	Stable
Unified dev + build pipeline	Stable
Federation foundation	Stable
Cloud CAS	In progress
AI optimization layer	Planned

I'd rather tell you what's stable and what isn't than sell you a roadmap as a fact.

How it works, in four ideas

One Graph. A persistent dependency graph that survives restarts, branch switches, dev/build transitions, and workspace boundaries. The graph is infrastructure, not temporary state.

One CAS. Every transformed artifact is stored by identity. If the inputs haven't changed, Ionify reuses the existing artifact instead of recomputing it. Artifacts are immutable; valid work is never redone.

One Dependency Authority. Dependencies are analyzed once and published as reusable contracts, consumed by the dev server, the production bundler, federation, and (soon) the cloud. No drift. No multiple realities.

One Pipeline. Most tooling quietly maintains a dev reality, a build reality, a CI reality, and a production reality — and they disagree. Ionify runs one deterministic pipeline so development and production can't.

Getting started looks like any other tool:

pnpm create ionify@latest

export default {
  entry: "/src/main.ts",
  outDir: "dist",
};

pnpm ionify dev
pnpm ionify build

The bug that made me build the DPL

The "One Dependency Authority" idea didn't come from a whiteboard. It came from a production bug.

In a real build, shared chunks were importing symbols from entry chunks that those entry chunks never actually exported. Invalid ESM relationships that passed tests and then waited to break at runtime. The root cause wasn't a single bad line — it was that no part of the pipeline owned the truth about what a module exports. Each stage re-derived the export surface, and they quietly disagreed.

The fix became the Dependency Publication Layer: publish a dependency's export surface exactly once as a content-hashed export ABI manifest, make that manifest the single export authority, and put a fail-closed loader in front of it that refuses to hydrate raw node_modules without a verified contract. Published contracts also carry an export-surface hash, singleton ownership, and a deterministic artifact identity.

The principle: one dependency, one contract, one authority. That's what kills duplicate Reacts, version drift, and phantom exports — not at lint time, but structurally.

Publish before build

Here's the part that surprises people. The work to produce production was already latent in your dev session — and every tool throws it away. Ionify doesn't.

While you develop, Ionify can publish production-keyed artifacts ahead of time, so your first production build after a dev session approaches warm-build speed:

export default defineConfig({
  productionArtifactPublishing: "auto",
});

The guardrails are the whole point — this is not a cache trick:

ionify build stays the verifier. Published artifacts are optional accelerators it must re-validate.
Publication writes only under .ionify — never dist/, never deploy output.
Production namespace only. Dev artifacts can't masquerade as production ones.
Fail-closed. If anything is missing, stale, or incompatible, build repairs via the normal production path.

Speed without giving up correctness — or it doesn't ship.

Why this is a different axis

Vite won on dev speed. Turbopack and Rspack are racing on raw speed too. But that's all the same axis — faster execution. Ionify competes on a different one: accumulated intelligence. When you change the axis, the question changes from "is this faster?" to "why did we ever accept that the build forgets everything, every single time?"

Try it

pnpm create ionify@latest

Site: https://ionify.cloud
GitHub (a star helps a lot): https://github.com/ionifyjs/ionify

This is post 1 in a series. Next up: how Ionify publishes dependency contracts — the DPL in depth, and why "one dependency, one authority" is the end of duplicate Reacts and phantom exports.

What would your CI look like if it never started over? I'd genuinely like to hear where your builds waste the most time — drop it in the comments.

The question that actually decides your state stack (it's not 'Redux or React Query')

KhaledSalem — Sun, 21 Jun 2026 09:39:24 +0000

This is not a "Redux is dead" post. Redux is excellent at what it's for. So is React Query. So is Zustand.

The problem was never the tools. It was that I spent years comparing tools that answer completely different questions — and never noticed.

"Redux or React Query?" "Zustand or RTK?" These read like real choices. They're not. It's like asking "hammer or screwdriver?" before you know what you're building.

The decision that actually matters comes from one question almost nobody asks correctly:

Who owns the source of truth for each piece of state?

There isn't one kind of state. There are two.

Owned truth. The client is the source. Is the sidebar open, what's the theme, which step of the wizard are we on, what's selected right now. Nobody tells this state to go re-verify itself. It lives and dies by your decision.

Borrowed truth. The source lives somewhere else — the server. Whatever you hold on the client is a mirror of a truth that changes behind your back. Its entire job is staying close to reality: staleness, invalidation, deduping, refetch-on-focus, optimistic updates.

These are not two flavors of the same thing. The first is a storage problem. The second is a distributed-systems synchronization problem. They do not share a mental model.

The original sin

A decade of frontend pain came from one move: using one tool for both.

Here's borrowed truth managed as if you owned it:

// The anti-pattern: server state hand-managed in a reducer
const initialState = { users: [], loading: false, error: null };

function usersReducer(state, action) {
  switch (action.type) {
    case 'FETCH_USERS_START':   return { ...state, loading: true };
    case 'FETCH_USERS_SUCCESS': return { users: action.payload, loading: false, error: null };
    case 'FETCH_USERS_ERROR':   return { ...state, loading: false, error: action.error };
    default: return state;
  }
}
// Now hand-write the rest yourself:
// caching, dedup, staleness windows, refetch-on-focus, retries, pagination...

Every line of that is you re-implementing React Query — badly, without the guarantees. The redux + sagas swamp people remember wasn't Redux being bad. It was borrowed truth shoved into a tool built for owned truth.

Split the two, and the swamp drains:

// Borrowed truth → React Query owns the hard part
const { data: users, isLoading } = useQuery({
  queryKey: ['users'],
  queryFn: fetchUsers,
}); // caching, dedup, staleness, refetch, retries — handled

// Owned truth → Zustand owns the trivial part
const useUI = create((set) => ({
  sidebarOpen: false,
  toggleSidebar: () => set((s) => ({ sidebarOpen: !s.sidebarOpen })),
}));

The famous combos are answers, not preferences

Once you split state by who owns the truth, the stacks stop being taste and start being derivations.

react-query + zustand — the separation bet

Most of your state turns out to be borrowed truth that was masquerading as client state. Once React Query absorbs it, what's left of your owned truth is small — so Zustand's near-zero-ceremony store is more than enough. React Query takes the hard distributed-systems problem; Zustand takes the trivial store. The modern default.

The one discipline it demands: never dump server data into Zustand. The boundary is the whole point.

rq + redux + sagas — the orchestration bet

This is the one people misread. Sagas are not a data-fetching tool. They're a concurrency-and-time model — CSP/coroutines for the frontend.

// Sagas model time & concurrency, not data
function* searchSaga() {
  yield takeLatest('SEARCH_INPUT', function* (action) {
    yield delay(300);                      // debounce
    const results = yield call(api.search, action.query); // auto-cancels the previous run
    yield put({ type: 'SEARCH_RESULTS', results });
  });
}

You reach for this when client complexity isn't holding values — it's orchestrating processes over time: cancellable, concurrent, raced flows, websocket streams feeding a state machine, multi-step wizards with rollback. And it's redux specifically — not Zustand — because sagas need a central action stream to subscribe to. The Redux action log is the event bus the saga listens on.

Here's the catch: React Query already ate the data-fetching orchestration. What's left for sagas is pure client-side concurrency. If, after adopting React Query, your sagas have almost nothing to do — that's the signal you never needed them. Justified for trading terminals, collaborative editors, real-time control UIs. Not your average CRUD app. (And in 2026, XState is often a cleaner answer than sagas for this axis — an explicit state machine beats an implicit one.)

RTK only — the unification bet

The opposite philosophy: don't specialize, unify. RTK Query handles borrowed truth, slices handle owned truth, all in one store, one tree, one set of devtools.

Why that's a real architectural argument, not laziness: you get one serializable snapshot of the entire app — server cache + client state in a single object. That makes logout → wipe everything a one-liner, time-travel debugging span the whole app including the cache, SSR hydration of all of it, and offline persistence trivial. react-query + zustand can't hand you one clean snapshot of the universe, because they're two separate universes.

The bet: unification is worth more than React Query's edge-case ergonomics. Enterprise's friend.

The decision matrix

Stack	Borrowed-truth ratio	Client complexity	One app snapshot?	Cost	Best fit
`react-query + zustand`	high	holding values	no	lowest	small, senior teams
`rq + redux + sagas`	high	orchestrating time	no	highest	concurrency-heavy domains
`RTK only`	medium–high	values + unification	yes	medium	large enterprise teams

The function, in plain terms:

Mostly borrowed truth + client just holds values → react-query + zustand
Client orchestrates processes over time → rq + redux + sagas
Need one snapshot of the whole universe → RTK only

(Diagram: the staircase decision tree goes here — each question peels off one answer.)

The uncomfortable part for 2026

React Server Components and server actions are quietly pushing a large chunk of this state back to the server. The app whose state was half client-state is watching RSC eat that half. So the deepest question now sits one level above everything above:

Does this state need to live on the client at all?

Don't pick a state tool. Figure out who owns the truth and where it lives — the tool derives itself from the answer.

What's your current stack, and which of these three is it really? Drop it in the comments 👇

Cache and Memory Are Not the Same Thing. Frontend Engineers Keep Treating Them As If They Are.

KhaledSalem — Sat, 20 Jun 2026 15:17:04 +0000

We use these words interchangeably all the time.

"The browser caches it." "React Query caches the response." "We memoize that calculation." "Service worker cache." "In-memory cache."

Cache. Memory. Memoization. Same bucket, different labels.

They're not the same thing. And the difference isn't pedantic — it's architectural, and it changes how you should design systems.

Start with what they actually are

Memory is a place where a system stores something it owns. The value exists because the system put it there, and the system is the source of truth for what that value is. If memory says X, X is true, by definition, because nothing external defines X.

Cache is a place where a system stores a copy of something whose truth lives somewhere else. The cache is never the source of truth. It's a bet — a bet that the copy still matches the original closely enough to be useful.

That's the entire distinction. Everything else follows from it.

Why this distinction has teeth

If you store something in memory, there is no concept of "going stale." A variable in your JavaScript runtime doesn't expire. let x = 5 doesn't have a TTL. The value is correct until you explicitly change it, because nothing else has authority over it.

If you store something in a cache, staleness is not a bug — it's the entire reason the structure exists in the first place. A cache without a staleness model isn't a cache. It's just memory pretending to be a cache, and it will eventually be wrong in a way nobody designed for.

This is the part frontend engineers skip past constantly.

React state vs React Query cache

useState is memory. The component owns the value. There is no external source of truth this value is trying to track. If you call setCount(5), count is 5. Permanently, until you change it again. No invalidation model needed because there's nothing to invalidate against.

useQuery from React Query is cache. The value it holds is not owned by your component — it's a snapshot of data that lives on a server, fetched at some point in the past. React Query doesn't trust that snapshot indefinitely. That's why staleTime exists. That's why refetchOnWindowFocus exists. That's why every cached entry has an implicit question attached to it: is this still true?

The mental model shift: memory answers "what is the value." Cache answers "what was the value, and how confident am I that it still is."

Redux vs RTK Query — the same codebase, two philosophies

This gets interesting because Redux Toolkit lets you do both inside the same store, and a lot of teams don't realize they're switching philosophies mid-app.

A Redux slice for UI state — isModalOpen, selectedTab, currentStep — is memory. Nobody asks if isModalOpen is "stale." It's either true or false because your application set it directly. There's no external reality it's trying to mirror.

RTK Query's cached API responses, sitting in the same Redux store, are cache. They have lastFetchedAt timestamps. They have invalidation tags. They get refetched when a mutation runs. The data isn't owned — it's borrowed from the server and tracked with suspicion.

Look in your Redux DevTools sometime and notice: some slices have no concept of expiry. Others — usually the RTK Query slices — carry metadata about freshness. That's not an implementation detail. That's two different architectural categories sharing one storage mechanism.

The browser HTTP cache is the purest example

This one is almost a textbook case because the browser is explicit about it.

Cache-Control: max-age=3600 is the browser literally encoding: "this is not the truth, it's a copy, and the copy is good enough for 3600 seconds." After that, the browser doesn't trust its own copy anymore. It revalidates.

ETag headers exist purely to answer "is my copy still accurate?" without re-downloading the whole resource. That's the cache asking the source of truth a cheap question instead of assuming.

There's no equivalent concept for, say, a value stored in localStorage that you wrote and control entirely. localStorage.setItem('theme', 'dark') doesn't go stale. It's memory. You own it. Nothing external invalidates it except you.

Why conflating them breaks systems

The actual cost of treating cache as memory: you stop asking "is this still true?" You start trusting a copy as if it were the source.

This is how stale UI bugs happen — a cached value gets treated like owned state, gets read without revalidation, and the user sees data that diverged from reality minutes ago.

The actual cost of treating memory as cache: you start adding unnecessary invalidation logic, staleness checks, and revalidation triggers to a value that was never uncertain in the first place. This is how you end up with useEffect chains trying to "sync" a piece of state that should have just been derived directly.

Both mistakes come from the same root cause: not asking, at design time, who owns this value, and is there an external truth it needs to track.

The question to ask before choosing a storage mechanism

Before reaching for useState, Redux, React Query, SWR, localStorage, or any cache layer — ask one question:

Does an external source of truth exist for this value, separate from my application?

If yes — server data, another service's state, anything outside your control — you need a cache. Build in staleness, invalidation, and revalidation from day one. Don't treat the first fetch as permanent truth.

If no — UI state, derived values, anything your application fully owns — you need memory. Don't add expiry logic to something that can't go stale. Don't "invalidate" a value nothing external can contradict.

Most frontend bugs involving "stale data" or "state out of sync" trace back to answering this question wrong at the start — usually by treating cache like memory, and trusting a copy longer than the copy deserves to be trusted.

If this was useful, I write about frontend architecture and build systems. Follow for more.

Vite's cold and warm builds cost the same. That's not a flex.

KhaledSalem — Tue, 16 Jun 2026 10:50:34 +0000

Look at this:

Vite cold build: 111ms
Vite warm build: 110ms

One millisecond difference.

That's not impressive performance.
That's an architecture with no memory between runs.

When cold and warm cost the same —
your tool isn't remembering anything.
It's rebuilding from scratch every single time.
Whether you ran it 10 seconds ago or 10 days ago.

What memory looks like

Ionify cold: 50ms
Ionify warm: 20ms

60% faster on warm. Because the engine remembered.

The persistent dependency graph loaded from disk.
The CAS checked which artifacts are still valid.
Only changed modules were retransformed.

The gap between cold and warm isn't a cache trick.
It's the measurable value of a build engine that persists.

Why this compounds across a team

On a single machine, the difference is 80ms.
Noticeable. Not life-changing.

Across a team with CI:

Every CI run rebuilds what dev already built
Every machine reconstructs what another machine already knew
Every deploy sends the full bundle to the browser

Because no tool in the chain remembers anything.

Ionify's persistent graph and CAS are shared.
What one machine computes, another can reuse.
The dependency contracts published at analysis time
are consumed by dev, build, CI, and federation — identically.

One machine's work stops being wasted.

The browser side

After a bugfix deploy:

Tool	Re-download
Vite	~479 KB (full bundle)
Ionify	~10 KB (entry chunk only)

Because Ionify knows which chunk changed.
Vite knows a build happened.

Ionify is open source and production-ready.
Validated on 11,000+ module, 25,000+ dependency apps.

→ github.com/ionifyjs/ionify ⭐
Drop your warm build time in the comments 👇

Vite Unified Toolchains IS Brilliant, But Is it Enough for Frontend 2026

KhaledSalem — Tue, 09 Jun 2026 18:11:45 +0000

Unified Toolchains Are Solving Yesterday's Problem

Vite 8 is a huge engineering achievement.

A unified stack built around:

Vite
Rolldown
OXC

This reduces inconsistencies and improves collaboration across layers.

But I think we're asking the wrong question.

The problem was never:

"Which compiler should we use?"

The problem was:

"Why does the same application have multiple realities?"

For years frontend developers have accepted:

Development Reality
Build Reality
CI Reality
Production Reality

And then we act surprised when bugs appear after deployment.

The industry keeps optimizing execution.

But execution isn't the root problem.

Authority is.

At Ionify Engine, we're exploring a different model:

One Graph.
One CAS.
One Dependency Authority.
One Pipeline.

The objective isn't simply replacing a compiler or bundler.
The objective is making dev and production consume the same artifact identities.

Because every time two systems disagree about ownership, exports, dependencies, or module identity, you create a new place where production-only bugs can hide.

The future of frontend tooling may not belong to the fastest compiler.

It may belong to the system with the fewest realities.

⭐ github.com/ionifyjs/ionify

🌐 ionify.cloud

You are Using Module Federation Wrong.

KhaledSalem — Mon, 08 Jun 2026 12:01:11 +0000

Let’s look at the actual workflow of an enterprise team using Module Federation today.

Team A works on the authentication micro-frontend. Team B works on the dashboard. Both pull a shared UI component library.

Team A updates a component, builds it, and deploys it independently. Awesome. Runtime code sharing works exactly as advertised.

But what happens on Team B's machine five minutes later?

When they pull the latest changes, their local bundler or CI container still has to reconstruct the dependency graph, re-optimize the incoming packages, and re-transform the modules from absolute zero.

The Micro-Frontend Tax

Traditional Module Federation only shares runtime code.
But behind the scenes, your build systems are completely isolated, stateless, and blind to each other. You are decoupled at runtime, but your pipelines are stuck running the exact same redundant computations over and over again.

In 2026, sharing JavaScript chunks shouldn't be the ultimate goal. Code sharing should just be a natural consequence of a smart, federated architecture.

Enter Ionify: Sharing the Brain, Not Just the Code

We built Ionify Federation to change how teams scale large-scale applications. We shifted the baseline from ephemeral local compilation to Federated Build Intelligence.

With Ionify, when one team handles a compilation step, the entire ecosystem instantly inherits the result.


javascript
// Traditional MF: Shares the built chunk at runtime
// Ionify Federation: Shares the actual computation state

- No More Re-Transformation: Teams see remote transformations and share them. If Team A transformed a module, Team B hydrates it instantly in milliseconds.
- No More Re-Optimization: Teams see remote dependency optimizations. Graph resolution and package splitting happen exactly once in human history.

RTK Query and React Query look identical from the outside.

KhaledSalem — Sun, 07 Jun 2026 19:11:33 +0000

RTK Query and React Query look identical from the outside.

Both cache API responses.
Both deduplicate in-flight requests.
Both have cache invalidation.
Both give you loading/error states.

So developers ask: which one should I use?

Wrong question. The right question is: where do you believe server state belongs?

━━━━━━━━━━━━━━━

RTK Query's architectural answer:

Server state is just another slice of your Redux store.

The cache lives inside Redux. That means:
→ Your API responses are inspectable in Redux DevTools
→ Your server state and client state share the same update cycle
→ Cache invalidation is a Redux action under the hood
→ You can select server cache the same way you select any Redux state

RTK Query treats the server as an external mutation source — but the data, once fetched, becomes Redux state. You own it now.

━━━━━━━━━━━━━━━

React Query's architectural answer:

Server state doesn't belong in your state manager at all.

The cache is completely isolated — React Query has no idea Redux exists, and Redux has no idea React Query exists. They operate in different layers entirely.

React Query treats every cached value as a temporary observation. It never fully trusts local state. staleTime is not an optimization — it's a philosophical statement: "I don't own this truth, I'm just borrowing it."

━━━━━━━━━━━━━━━

One layer deeper — the invalidation model:

RTK Query invalidation: tag-based.
You define tags on queries and mutations. When a mutation runs, it invalidates matching tags. Deterministic. Explicit. You're in control.

React Query invalidation: time + intent based.
Data goes stale automatically after staleTime. You also manually call queryClient.invalidateQueries(). The cache itself knows it might be wrong — you don't have to tell it.

RTK Query: "invalid until I say otherwise"
React Query: "valid until time proves otherwise"

━━━━━━━━━━━━━━━

So which one?

If your app is Redux-first and server state needs to be part of a unified state model → RTK Query. The integration is seamless and DevTools alone are worth it.

If server state is its own concern — separate from UI state, separate from client decisions → React Query. The isolation is a feature, not a limitation.

The confusion happens because both solve the same surface problem.
The difference is where they believe the truth should live.

Redux says: truth lives in the store.
React Query says: truth lives on the server. We just cache it.

Your build tool gets dumber every deploy! Time To Move On

KhaledSalem — Sun, 07 Jun 2026 10:33:19 +0000

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

Frontend Build Tools Speed is a Placebo

KhaledSalem — Thu, 04 Jun 2026 10:36:48 +0000

One of the hardest engineering decisions is to walk away from Vite. Let’s be honest, the current Build Tools have a real Engineering Leakage.

You change a single interface in a shared Monorepo package. You run your build script. Your terminal proudly flashes: CACHE HIT or Tasks: 12 cached, 1 executed. You get a hit of dopamine. You think your tooling is smart.

But then you check the network tab, the CI logs, and the cloud compute bill.

It’s a placebo.

Traditional build caches don’t understand the semantic layout of your application. They cache files based on file-system timestamps or naive input hashing. The moment a core graph node shifts—even by a byte—the entire stateless machine panics, invalidates the downstream cache, and triggers a full, brutal Cold Start.

The Cache vs. Memory Illusion

Caching is trying to save a temporary snapshot of a dumb process.
Memory is an inherent property of an intelligent architecture.

Traditional tools (Webpack, Vite, and even modern stateless wrappers) store artifacts but throw away the Dependency Graph after the run. They have no past memory. They don't track route history, dependency depth, or runtime co-requests over time.

How Ionify’s CAS Rewrites the Rules

We built Ionify because we got tired of faking build speed with file-system caches.

Ionify treats your codebase as a permanent,Persistence Graph driven by true Content-Addressable Storage (CAS).

It doesn't look at when a file changed; it looks at what the file actually contains.
If a module's cryptographic identity matches a verified artifact in the CAS, the transformation is skipped completely—even across different branches, and even across different machines on your team via Ionify Cloud.

The result is absolute determinism:

Ionify Warm Build: 30ms (CAS hits)
Vite Warm Build: 110ms (Full re-transformation, every single time)

Stop using tools that need to be reminded of who you are on every run. Give your infrastructure a memory layer that actually computes valid work exactly once.

👉 Haven't you asked yourself in 2026 why your build architecture is still this primitive?

ionify.cloud

Why Our CI Pipeline Kept Rebuilding the Same Graph (And How I Fixed It)

KhaledSalem — Mon, 01 Jun 2026 12:47:48 +0000

Most frontend teams optimise build speed.

But few measure how much work is unnecessarily repeated.

We ran into this problem while working on larger frontend systems:

multiple developers
multiple apps
shared dependencies
constant CI runs

On paper, builds were “fast”.
In practice, we were still wasting time

The Symptom

Our CI pipeline looked healthy.
But we noticed:

small changes triggered large rebuilds
identical graphs were recomputed across runs
the same dependencies were resolved repeatedly
different apps rebuilt overlapping work

Nothing was technically broken.
But everything was being repeated.

The Root Cause

The issue wasn’t tooling performance.

It was an assumption:
Every build starts from zero.

That assumption forces:

graph rediscovery
redundant transformations
duplicate dependency resolution
no shared memory between runs

At small scale → acceptable. 
At team scale → expensive.

Measuring the Cost

** Even without precise metrics, the pattern was clear:**

identical work across CI runs
repeated build steps across developers
overlapping dependency graphs across apps

Speed improvements didn’t solve it.
They only made repetition faster.

The Shift

Instead of asking:
How do we make builds faster?

We asked:
Why are we rebuilding valid work at all?

The Solution Approach

The key idea is simple:

Treat the build as a persistent graph system, not a disposable process.

This means:

remembering valid work
tracking changes at graph level
invalidating only what changed
reusing work across runs

Where Ionify Fits

This is the problem Ionify is designed to solve.

Not by optimising execution speed, but by eliminating unnecessary repetition.

Final Thought

Most build discussions focus on speed.

At scale, the real problem is wasted work.

And wasted work isn’t a performance problem.

It’s a memory problem.

Kicking a dead horse at the speed of light doesn't make it run.

KhaledSalem — Sat, 30 May 2026 19:43:12 +0000

Let’s be honest. The frontend community has a new silver bullet, and it’s called Rust.

Every week, there’s a new wrapper, a new linter, or a new bundler boasting "100x faster execution because of Rust." But here is the uncomfortable truth about the 2026 frontend tooling ecosystem:

Kicking a dead horse at the speed of light doesn't make it run.

Writing your compiler or transformer in Rust (like Oxc or SWC) is fantastic for raw compute. But if your underlying architecture is still stateless—meaning it completely destroys the dependency graph after every run and starts from absolute zero on the next boot—you haven't solved the bottleneck. You just made a dumb architecture execute faster.

The Real Problem: Stateless Amnesia

Traditional tools like Vite and Webpack suffer from "Past Amnesia". Every time you switch a branch, pull from main, or clear a cache, the tool treats your project like a stranger.

At scale, in enterprise monorepos with thousands of modules, this is a massive tax on engineering velocity.

The Ionify Paradigm Shift

We built Ionify because we realized that the next bottleneck isn't execution speed—it's system memory.

Ionify uses a native Persistence Graph backed by Content-Addressable Storage (CAS)

We don’t cache; we remember. - If a module or its dependencies haven't changed, the compiled artifact is immutable and permanently verified.

The benchmark proves it:

Ionify Warm Build: 30ms (CAS hits)
Vite Warm Build: 110ms (Full re-transformation every single time)

At the scale of +11K module, the benchmark becomes:

Ionify Warm Build: 200ms (CAS hits)
Vite Warm Build: 2.2s (Full re-transformation every single time)

Stop celebrating tools that just do useless repeated work faster. It’s 2026. Your build system should have a brain.

👉 Check out how memory beats raw speed: ionify.cloud

I built a build engine that remembers. Here's what happened.

KhaledSalem — Sat, 23 May 2026 18:11:23 +0000

We've been optimizing the wrong thing.

Vite made builds fast. Webpack made builds structured. Everyone declared victory and moved on.

But nobody asked the question that's been bothering me for years:

Why does every build start from zero?

Not as a philosophical exercise. As a real engineering problem.

Your dependency graph didn't change. Your packages didn't change. 90% of what your build tool is about to do — it already did last week. On this machine. And on every other machine on your team.

But it rebuilds anyway because it doesn't remember.

So I built something that does.

Ionify is a frontend build engine with one core architectural difference from every tool you've used before:

The dependency graph persists.

Not in RAM. Persisted and shared — across runs, across dev and build, across every machine on your team.

// Every other tool
run build
  → build a graph in memory
  → use it
  → destroy it  ❌

// Ionify
run build
  → load graph from disk
  → update only what changed
  → save back  ✅

That one change cascades into everything else.

What actually changes

Content-addressable artifacts

Every output is stored by its content hash. If the content didn't change, the artifact already exists. No rebuild. No retransform. Just reuse.

This works across machines. Your CI doesn't recompute what your dev already computed.

Route-aware vendor packs

The persistent graph accumulates route history. It knows which dependencies appear together at runtime. It groups them accordingly.

Before vendor packs:
  requests: 46    bytes: 1.8 MB    parse time: baseline

After:
  requests:  9    bytes: 420 KB    parse time saved: 120ms

80% fewer requests. 76% fewer bytes. Not from HTTP/2 tricks. From the engine knowing your app better than a single build ever could.

Pre-compressed output

Vite's model: emit raw assets, let nginx compress at request time. At Brotli quality 11, that's too slow for per-request use, so servers use br:4–6. That's 15–30% larger than maximum compression.

Ionify emits .br and .gz sidecars at build time at maximum quality (br:11, gz:9). The server reads pre-built bytes directly.

Request-time CPU:      zero
Brotli quality:        br:11 (maximum)
Warm rebuild cost:     3ms (CAS hit)

The benchmark that surprised me

After fixing three parallelization issues in the build pipeline:

Before:
  cold: 144ms

  ↓ Fix 1: parallel CAS restore (br+gz)    → -35ms
  ↓ Fix 2: eager hash hint                 → -10ms
  ↓ Fix 3: parallel collectFilesRecursive  → -47ms net

After:
  cold: 52ms ✅

And the full comparison:

Ionify cold:  52ms   (full precompression included)
Vite cold:   111ms   (no precompression at all)

Ionify warm:  30ms   (CAS hits + sidecar reuse)
Vite warm:   110ms   (full retransform every time)

Warm at 30ms isn't clever caching. It's the engine verifying previous work is still valid and reusing it. Vite retransforms everything because it has no way to know.

On the browser side

When you ship a bugfix, a Vite user's browser re-downloads the full 479 KB bundle. The vendor code, the React runtime, the shared utilities — all of it. Because from Vite's perspective, a build happened and the output changed.

On the second visit after any deploy: Ionify transfers ~10 KB. Vite transfers 479 KB.

The architectural table nobody shows you

	Webpack	Vite	Ionify
Persistent graph	✗	✗	✓
CAS artifacts	✗	✗	✓
Route-aware packs	✗	✗	✓
Same engine dev+build	✗	✗	✓
Pre-compressed (br:11)	✗	✗	✓
Analysis lifetime	per-run	per-run	persistent
Gets faster over time	✗	✗	✓

What this isn't

This isn't "Vite is bad." Vite is an excellent escape from Webpack and HMR optimization since that time. But frontend grew into a system, and systems need engines, not just tools.

Tools are built for a moment. Engines are built for systems.
That's where Ionify lives.

Single machine → modest improvement.
Multi-machine CI + shared deps + many routes → the gap becomes structural.

At that point, you're not comparing tools. You're comparing whether your build infrastructure has memory or not.

Try it

→ GitHub: github.com/ionify/ ⭐
→ Docs: ionify.cloud

If this resonates, a star goes a long way. And I'd genuinely love to hear if you've hit the same wall.

What's your current build time on a warm run?