Forem: KhaledSalem

How I reduced React +11K module build time from 2.4s to 459ms

KhaledSalem — Mon, 20 Apr 2026 18:38:20 +0000

A project with +25K dependencies and +11K Module takes 2.4s on Vite8, not to mention the previous Vite, and each day I might need multiple builds, and we have to wait all that time!

To address this problem I moved away from Vite and developed a First Persistent Build Intelligence Engine (#Ionify).

We don't run the same loops twice. Ionify introduces "Build Intelligence" via a Long-Lived Dependency Graph & CAS. Time-to-deploy is now instant.

If you believe complex builds should be instant (we're talking 4000ms for +11k modules). Join the movement!

⭐️ Star us on #GitHub and let's kill 'Past Amnesia' together: https://github.com/ionifyjs/ionify

Why Frontend developers should select Ionify?

KhaledSalem — Mon, 20 Apr 2026 03:52:38 +0000

Over 10 years of experience in software. I realized that moving from Webpack to Vite was a linear improvement, while the core problem remains: stateless and reprocessing.

Build tools were getting faster, but not architectural intelligence. Leveraging my background in software engineering and system design, I recognized that this was not just a tooling issue. but a deeper architectural limitation.

I decided to bridge this gap by applying Content Addressable Storage (CAS) principles. This shift from 'tools that run' to an 'engine that remembers' allows the build process to become cumulative.

Ionify wasn't born from a need for another tool, but from a necessity to fix the fundamental architectural amnesia of modern development pipelines.

We're #building the future of persistent infrastructure with #Ionify If you believe enterprise builds should be instant (we're talking sub-100ms for +11k modules). Join the movement! ⭐️ Star us on #GitHub and let's kill 'Past Amnesia' together: https://github.com/ionifyjs/ionify

React #WebDevelopment #Frontend #Vite #JavaScript #Rust #WebDev #BuildPerformance #OXC #Ionify

build time from 2.4s to 459ms

KhaledSalem — Thu, 16 Apr 2026 23:57:44 +0000

A project from +11K module had 1500 ms warm build using Ionify. Today we reached 400 ms.

While Vite8 takes 2.2s.

I am publishing this new version of Ionify now!

We don't run the same loops twice. Ionify introduces "Build Intelligence" via a Long-Lived Dependency Graph & CAS. Time-to-deploy is now instant. Join the memory revolution: (https://ionify.cloud)]

Moving from Webpack and Vite to Ionify is filling this gap

KhaledSalem — Mon, 13 Apr 2026 11:12:42 +0000

Modern frontend tooling is stateless, forcing repeated work on every build. This leads to slow feedback loops, wasted compute, and poor scalability as applications grow.

Moving from Webpack and Vite to Ionify is filling this gap!!

While Vite repeats work and uses plugins to understand React... Ionify uses CAS "content-addressable cache", and a persistent dependency graph.

https://www.npmjs.com/package/@ionify/ionify

While #Vite repeats work and uses plugins to understand #React... Ionify uses CAS "content-addressable cache", and a persistent dependency graph. Explore more at https://ionify.cloud/

KhaledSalem — Sun, 12 Apr 2026 09:05:34 +0000

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

Vite is fast, but it's still wasting your time. 🚩

KhaledSalem — Sat, 11 Apr 2026 21:29:20 +0000

There, I said it. We’ve all been tricked into thinking that a "faster compiler" is the solution to slow development cycles. It’s not.

If your build tool doesn't have a memory, it’s just a faster treadmill. You’re still running, but you’re going nowhere.

Every time you hear your laptop fans kick in for a "re-build" of something you built 10 minutes ago, you should be angry. That’s not "Modern Dev," that’s Redundant Work.

We built Ionify to stop this madness.
While others optimize the "run," we eliminated the "repeat."

If you’re still okay with your tool forgetting your project state every time you restart, keep using Vite. If you want an engine that actually learns your codebase:

🔗 ionify.cloud

Github Repo for latest new and issues: https://github.com/ionifyjs/ionify/

Move From Vite To Ionify

KhaledSalem — Sat, 11 Apr 2026 12:14:35 +0000

If you are a Frontend developer. Moving from Vite to Ionify is moving from repeating tool work and plugin hooks to Engine with a memory and no plugin hooks!

Try Ionify now, and I am totally sure you will not be able to reverse from Engine to tools again!

It's not about performance only! It's moving from a tool mindset to an engine mindset!

at Ionify: If the file content changes, the moduleHash changes, so the new transformed output goes to a new CAS path. The old one can still physically exist on disk, but the engine now points to the new hash.

That means if Ionify grows with your project and learns from the growing path to provid comperhansive analysis and help!

Explore all of this now and more at
https://ionify.cloud/

Github: https://github.com/ionifyjs/ionify

Most tools optimize speed. I’m trying to eliminate repeated work. Why are we doing the same transforms again? Genuinely curious! Do you see this as a limitation… or just how things are supposed to work? https://ionify.cloud/ #WebDev #Frontend #Vite

KhaledSalem — Thu, 09 Apr 2026 17:06:29 +0000

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

If you’re a Frontend developer .. Does your tool need plugins to understand your framework?

KhaledSalem — Thu, 09 Apr 2026 01:59:27 +0000

If you’re a Frontend developer and your tool needs plugins to understand your framework… Then your transformer doesn’t actually understand it.

Plugins are not a feature. They’re a workaround.

Ionify does not require plugins; instead, it understands the framework as a part of its core!

Explore ionify now at https://ionify.cloud

Started us at GitHub and get the latest news at https://lnkd.in/dHiVER9X

For any issues, we love to talk at https://lnkd.in/eTcsWzum

Slimm-Pack Vs Tree-shaking

KhaledSalem — Wed, 08 Apr 2026 12:03:42 +0000

Tree-shaking runs every build.

Slimm-Pack doesn’t.

Traditional tools:
analyze → build → forget

Ionify:
analyze → store → reuse

This is not optimization.

This is a different architecture.

Ionify vs Vite: What Actually Happens Inside Your Build Tool

KhaledSalem — Tue, 07 Apr 2026 19:24:35 +0000

Most developers use Vite and trust it. It's fast, well-designed, and gets out of the way.

But there's a fundamental assumption baked into Vite's architecture — and every other major build tool — that we decided to challenge when building Ionify.

The assumption: every build starts from zero.

This post is a deep look at what that means in practice, what we built instead, and the architectural tradeoffs we made along the way.

The Stateless Build Problem

When you run vite build, here's roughly what happens:

Vite spins up esbuild/Rollup (now powered by Rolldown + Oxc instead of pure Rollup/Babel in many cases)
Each file goes through its plugin chain independently
main.tsx → TS plugin → JSX plugin → output
utils.ts → TS plugin → output
index.css → CSS plugin → output
Everything gets bundled

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

There's no memory of what already ran. The TS plugin doesn't know the JSX plugin already processed a file. The bundler doesn't know which files actually changed since last time. The entire pipeline is stateless by design.

This isn't a bug — it's a deliberate architectural choice that keeps the tool simple and predictable. But it has a real cost at scale.

How Ionify Thinks About This Differently

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.

When a file changes, Ionify runs a BFS over the reverse dependency index to find exactly which modules are affected:

This means on a 500-module project, changing one utility file might only invalidate 12 modules — not all 500.

The Four-Tier CAS Architecture

As the system evolved, we ended up with four distinct caching layers, each solving a different problem:

Tier 1 — Module Transform Cache

Tier 2 — Deps Artifact Store

Tier 3 — Compression CAS

Pre-compressed build outputs. Brotli-11 + gzip-9 computed once, served forever.

Tier 4 — Chunk-Output CAS

Real Config: Migrating from Vite

Here's an actual ionify.config.ts from a production project that migrated from Vite:

import { defineConfig } from 'ionify'

export default defineConfig({
  entry: '/src/main.tsx',
  server: {
    https: true,
  },
  resolve: {
    // Same aliases as tsconfig — Ionify reads these natively
    // Note: if your tsconfig.json is JSONC (comments/trailing commas),
    // auto-alias parsing currently fails — specify manually here
    alias: {
      '@@': '/',
      '@@/Core': '/Core/src',
      '@': '/src',
    },
    extensions: ['.mjs', '.js', '.mts', '.ts', '.jsx', '.tsx', '.json'],
    conditions: ['import', 'module', 'browser', 'default'],
    mainFields: ['module', 'jsnext:main', 'jsnext', 'main'],
  },
  optimizeDeps: {
    include: ['moment-hijri'],   // pre-warm known-problem deps
    sharedChunks: 'auto',
    packSlimming: 'auto',
    vendorPacks: 'auto',
  },
  build: {
    target: 'esnext',
  },
})

This project has more than +10K module and the results of build time at vite roll-down was 2.4 seconds every time with a lot of configs to reach this time! after migrating to Ionify. The time was reduced to 400ms on warm build, and 3.2 seconds for cold build

The Fundamental Difference

Vite is built around the assumption that each build is independent.

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

Both assumptions are reasonable. Vite's leads to a simpler, more predictable system. Ours leads to a system where the second build, the tenth build, and the CI build all benefit from everything that happened before.

The "With Ionify" side of the transform diagram is mostly empty. Not because we're hiding complexity — but because most of the transforms simply don't run.

Ionify is currently in production use. → ionify.cloud

𝗜𝗳 𝘆𝗼𝘂'𝗿𝗲 𝗮 𝗳𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿, 𝘆𝗼𝘂 𝘀𝗵𝗼𝘂𝗹𝗱 𝘀𝗲𝗿𝗶𝗼𝘂𝘀𝗹𝘆 𝗿𝗲𝘁𝗵𝗶𝗻𝗸 𝘆𝗼𝘂𝗿 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲. Move to a persistent graph + CAS-first engine.

KhaledSalem — Mon, 06 Apr 2026 13:32:32 +0000

𝗜𝗳 𝘆𝗼𝘂'𝗿𝗲 𝗮 𝗳𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿, 𝘆𝗼𝘂 𝘀𝗵𝗼𝘂𝗹𝗱 𝘀𝗲𝗿𝗶𝗼𝘂𝘀𝗹𝘆 𝗿𝗲𝘁𝗵𝗶𝗻𝗸 𝘆𝗼𝘂𝗿 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲.
Move to a persistent graph + CAS-first engine.

╭────────────────────────────────╮
│ pnpm create ionify@latest │
╰────────────────────────────────╯

And you’ll feel the difference:
▸ faster cold starts
▸ near-zero repeated work
▸ builds that don’t redo what’s already done

Ionify isn’t just another tool. It’s built on:
▸ Persistent dependency graph
▸ Content Addressable Storage (CAS)
And this is just the beginning.

We’re rolling out more — step by step.

⭐ Follow the journey: https://lnkd.in/dHiVER9X

💬 Found an issue? Open one — we actively respond:
https://lnkd.in/eTcsWzum

🌐 Try it now: https://ionify.cloud/