DEV Community: KhaledSalem

When Does Local State Become Shared State? A React State Ownership Guide

KhaledSalem — Sat, 24 Oct 2026 20:24:57 +0000

State Management Decision Authority — Part 02

Your React state doesn't need to be global just because two components need it.

In Part 1, useState vs useReducer: Stop Choosing Tools Before Understanding State, I explored an architectural idea I call the State Management Decision Authority: choosing state management strategies through consistent criteria rather than tool preferences.

One of those criteria deserves a deeper discussion:

State Ownership.

Because sharing state and globalizing state are two very different decisions.

1. The Checkout Problem

Imagine a checkout feature with three components:

function Checkout() {
  return (
    <>
      <ShippingForm />
      <OrderSummary />
      <PaymentSection />
    </>
  );
}

Each component has a different responsibility.

ShippingForm collects the delivery address.
OrderSummary displays the shipping cost.
PaymentSection checks whether checkout requirements are satisfied.

But they all depend on some of the same information.

If the user changes the shipping country, the available shipping methods might change. The order summary may need to recalculate its totals, and payment might need to be disabled until a valid shipping option is selected.

The three components now need to coordinate.

Does that mean we should introduce a global store?

Not yet.

2. First Principle: Ownership Before Accessibility

Before choosing a tool, ask:

Who should own this state?

This is different from asking who needs to read it.

A component may consume state without owning its lifecycle or controlling its transitions.

For our checkout example, the checkout feature itself is a reasonable ownership boundary.

We can lift state to the nearest common ancestor:

import { useState } from "react";

function Checkout() {
  const [country, setCountry] = useState("EG");

  return (
    <>
      <ShippingForm
        country={country}
        onCountryChange={setCountry}
      />

      <OrderSummary country={country} />

      <PaymentSection country={country} />
    </>
  );
}

Now we have a single source of truth for country.

No Zustand. No Redux. No global Context provider.

Just state ownership aligned with the component tree.

Of course, the example is intentionally simplified. A real checkout flow would also need shipping options, validation rules, and order totals. Those can be derived or managed within the same feature boundary as appropriate.

Sharing state doesn't automatically require global ownership.

3. The Smallest Sufficient Ownership Boundary

Here's a principle I find useful:

Give each piece of state the smallest ownership boundary that satisfies its requirements.

Why the smallest?

Because expanding the ownership boundary also expands the potential dependency surface.

More components may gain access to the state. More logic may begin relying on its shape and behavior. Changes to that state can become harder to reason about.

That doesn't make shared state inherently bad.

It means accessibility should be intentional.

For example:

Requirement	Potential ownership
Toggle a local dropdown	Dropdown component
Coordinate shipping and payment	Checkout feature
Share a wizard's progress across steps	Wizard boundary
Display a notification across independent features	Shared notification service or store
Cache fetched product data	Server-state cache

Notice that ownership isn't determined by the number of components alone.

It's determined by the scope of coordination.

4. When useReducer Still Belongs Inside a Feature

What if our checkout state becomes more complicated?

Changing the shipping country might invalidate the selected shipping method.

Applying a discount might update the totals.

Submitting the checkout might require a valid combination of address, shipping option, and payment information.

Now we have related transitions and invariants.

This might justify useReducer:

const initialState = {
  country: "EG",
  shippingMethod: null
};

function checkoutReducer(state, action) {
  switch (action.type) {
    case "COUNTRY_CHANGED":
      return {
        ...state,
        country: action.country,
        shippingMethod: null
      };

    case "SHIPPING_SELECTED":
      return {
        ...state,
        shippingMethod: action.method
      };

    default:
      return state;
  }
}

In a production implementation, SHIPPING_SELECTED should also validate that the selected shipping method is permitted for the current country, or accept only previously validated options.

The important architectural detail is that introducing useReducer changes how we manage transitions, not who needs to own the state.

We can continue keeping the reducer inside Checkout.

A complex state is not necessarily a global state.

5. When Context Becomes Useful

Now imagine our checkout feature grows deeper:

Checkout
  └── CheckoutLayout
       └── CheckoutSteps
            └── ShippingStep
                 └── ShippingForm

Passing checkout state through components that don't use it can become inconvenient.

This is where Context might help.

import {
  createContext,
  useContext,
  useReducer
} from "react";

const CheckoutContext = createContext(null);

function CheckoutProvider({ children }) {
  const [state, dispatch] = useReducer(
    checkoutReducer,
    initialState
  );

  return (
    <CheckoutContext.Provider value={{ state, dispatch }}>
      {children}
    </CheckoutContext.Provider>
  );
}

function useCheckout() {
  const context = useContext(CheckoutContext);

  if (context === null) {
    throw new Error("Missing CheckoutProvider");
  }

  return context;
}

We can place CheckoutProvider around the checkout feature rather than the entire application.

Context solves an accessibility problem: delivering a value to consumers deeper in a component tree.

It doesn't automatically solve complex transitions, and it isn't inherently a rendering optimization.

When a provider value changes, components consuming that Context are eligible to re-render. In performance-sensitive flows, we may need to split contexts, stabilize values, or use more selective subscription mechanisms.

Context changes how state is accessed. It doesn't require changing who owns it.

6. When an External Store Starts Making Sense

Suppose the requirements evolve again.

Several independent application features now need to coordinate shared client state.

Maybe a shopping cart is modified from product listings, product detail pages, and a persistent cart drawer.

A dedicated shared store may become easier to maintain than repeatedly lifting state or creating an increasingly broad Context.

This is where Zustand or Redux Toolkit becomes worth evaluating.

But the decision shouldn't be:

"We have five components consuming this state, so let's use Zustand."

A more useful question is:

Do we now have an ownership and subscription problem that our existing structure handles poorly?

Other considerations include:

Whether consumers need selective subscriptions
Whether cross-feature updates are becoming difficult to coordinate
Whether state transitions need stronger conventions or debugging capabilities
Whether the project already has a suitable established state management architecture
Whether the additional abstraction reduces more complexity than it introduces

An external store may be the right solution.

But it should be the result of a concrete architectural requirement.

7. Shared Client State Isn't Server State

There's one more boundary worth preserving.

Some data is shared because it originates from the server.

Product catalogs, user records, and remote inventory are examples.

That introduces concerns such as caching, stale data, refetching, invalidation, and synchronization.

For those cases, a server-state solution such as TanStack Query or RTK Query may be more appropriate than manually copying remote data into a general-purpose client store.

This isn't an either-or decision.

A real application can use local React state for a form, a shared client store for a cart, and a server-state cache for product information.

The important thing is to avoid giving one mechanism responsibilities it wasn't chosen to handle.

We'll explore this distinction later in the series.

8. A State Ownership Decision Framework

Before changing your state architecture, try answering these questions:

Question	Possible direction
Does only one component need the state?	Keep it local
Do siblings need to coordinate?	Lift to their nearest common owner
Is passing data through intermediate components becoming cumbersome?	Consider composition or Context
Are related transitions becoming difficult to maintain?	Consider `useReducer` within the existing boundary
Are independent features coordinating shared client state?	Evaluate an external store
Is the state primarily remote data?	Evaluate server-state management

The framework is deliberately not a rigid decision tree.

These dimensions overlap, and different solutions can satisfy the same requirements.

Its purpose is to make our reasoning explicit.

Final Thought

One of the most expensive architectural decisions is making a local concern global before it needs to be.

Once unrelated features begin depending on a shared state boundary, changing that boundary can become harder.

My principle is simple:

Sharing state is a requirement. Globalizing state is an architectural decision.

And the goal should be:

The smallest sufficient ownership boundary.

That's how I'm applying the State Management Decision Authority introduced in Part 1.

Not by standardizing every tool, but by standardizing how we evaluate the problem.

Unify the decision criteria, not necessarily the tools.

What's next?

Part 03: Context vs Zustand vs Redux Toolkit — What Actually Justifies a Shared State Solution?

We'll go beyond feature ownership and explore how subscription behavior, transition complexity, tooling, and application boundaries influence the choice.

What makes you decide that React's built-in state management is no longer enough for a particular feature?

After one React edit, what can your build skip?

KhaledSalem — Wed, 21 Oct 2026 12:00:00 +0000

Compare an unchanged run with a run after a small source edit—and check the output before interpreting the timer.

An unchanged build and a build after an edit answer different questions. For this walkthrough, use a small React label change that you can actually see in the built app. Keep the command and project setup the same. That gives you a more useful comparison than a single “fast build” number: what happened with no edit, and what happened after the source changed?

Why should a frontend developer care?

You want to know whether the build loop improves when you are actually editing, not only when nothing changed. A visible mutation gives the comparison an output check that a timer cannot provide.

1. Keep one direct pilot command

Use one existing supported app. Keep the team’s existing scripts, linting and tests. Add a distinct script if you need one:

{
  "scripts": {
    "build:ionify": "ionify build"
  }
}

Merge this entry into the existing scripts object; do not replace other scripts. Record the installed package version and lockfile. From the app directory run:

pnpm run build:ionify

Let the process exit and run the same command again unchanged, retaining local state and output. Use fresh processes, the same configuration and the same command for the edited run too.

2. Change an imported React component

Replace the original rendered button with the edited version:

// Before
<button id="save-button">Save</button>
// After
<button id="save-button">Save draft</button>

These JSX fragments are illustrative, not observations. Build again. Serve the generated output with the app’s normal preview setup. For a root-page app using the default dist output, one local static preview is:

python3 -m http.server 4173 --bind 127.0.0.1 --directory dist

Open http://127.0.0.1:4173/ and inspect #save-button. Expected after the edit: Save draft. Record what you actually see. Adapt the directory if you intentionally selected another output path; Python’s simple server does not supply SPA route fallback.

3. Name the state you compared

Case	What it tells you	Output check
Whole task restored, if applicable	The task runner reused its recorded result; the engine may not have run	Inspect the restored app
Task executed with retained engine state	The command ran; unchanged and edited runs remain separate observations	Inspect the exact label after each run
Fresh-state control in a separate disposable copy	A different starting state, with the original fixture preserved	Inspect that copy’s built app

The first row is conceptual. This walkthrough does not establish a named task-runner integration or provide invented runner commands. If your repository already has one, use its documentation to declare inputs and outputs, then verify restored versus executed status from its actual logs. If the label changed but the task remains a hit unexpectedly, preserve the evidence and investigate input declarations.

Running pnpm run build:ionify directly bypasses that orchestration. Do not compare its elapsed boundary with a whole-task restore as if they were identical work.

4. Separate output evidence from interpretation

Installed version / checkout / exact command:
Mutation and retained local state:
Task outcome: restored / executed / unknown
Engine outcome: not invoked / completed / failed / unknown
Expected and observed label:
Served directory / URL / cache observations:
Elapsed boundary and observations, if measured:

A prior label experiment initially displayed an old label through same-origin HTTP 304 reuse; a fresh origin serving the retained-state output displayed the new one. Check the served directory, URL and browser reuse before concluding that generated output or engine reuse is correct or incorrect. Generated-string presence alone is not browser verification.

No timing, log or internal skip count is fabricated here. Use diagnostics supported by your installed release if you need to explain the work, and report an unexpected result as carefully as a favorable one. Which edit would you use as your smallest useful check?

Cover description: “One edit. Less repeat work”: an amber pencil touches one raised amber code tile among graphite tiles on an ivory background. Conceptual illustration.

Conceptual illustration created with AI assistance for Ionify.

useState vs useReducer: Stop Choosing Tools Before Understanding State

KhaledSalem — Tue, 20 Oct 2026 20:44:28 +0000

Why React state management needs consistent decision criteria, not another library.

When should you use useState instead of useReducer?

The common answer is straightforward:

Use useState for simple state.
Use useReducer for complex state.

It's not necessarily wrong. But I think it's incomplete.

Because state management complexity isn't just about how many values we store. It's also about who owns the state, how it changes, which rules govern those changes, and how long that state needs to live.

That leads me to a more fundamental question:

Why do we start by choosing a state management tool before defining the criteria that should guide that choice?

1. The Problem with Tool-First Thinking

Imagine we're building a checkout flow in React.

We have a shipping address, payment method, discount code, and several validation rules.

We could use multiple useState hooks. Or we could combine the logic into a useReducer.

But having multiple state variables doesn't automatically justify a reducer.

What matters is how those values relate to each other.

For example, changing the shipping country might invalidate the selected shipping method.

Now we're no longer dealing with independent values. We're dealing with related state transitions governed by business rules.

And that's where the architectural decision becomes interesting.

2. Introducing a State Management Decision Authority

What if we separated the decision-making process from the tools themselves?

I like to think of this as a State Management Decision Authority.

It's not a new React API, an additional library, or an official design pattern.

It's a proposed architectural approach: define a consistent set of criteria that determines which state management strategy fits a particular problem.

Before choosing a tool, evaluate five dimensions.

State ownership

Who needs access to this state?

Is it owned by a single component, a feature, or multiple independent parts of the application?

Update complexity

Does updating the state involve assigning a new value, or applying several related business rules?

State relationships

Are state values independent, or must certain invariants remain true whenever one value changes?

State transitions

Are there explicit transitions between states, such as idle, processing, success, and error?

State lifecycle

Are we managing local UI state, shared client state, or server state that requires fetching, caching, and synchronization?

The answers should determine the tool, rather than the tool shaping how we define the problem.

3. When useState Is the Right Choice

Consider a simple toggle:

const [isOpen, setIsOpen] = useState(false);

The state is local, the update is straightforward, and there are no complex transition rules.

Introducing actions and a reducer here would add complexity without providing much value.

The same applies to many inputs, visibility flags, and independently updated UI values.

Importantly, the number of state variables alone is not a reliable decision criterion.

A component with five independent state variables might be better served by five useState hooks than by one reducer.

The goal isn't to minimize the number of hooks. It's to minimize unnecessary complexity.

4. When useReducer Becomes More Valuable

Now consider a payment workflow.

We have several possible states, and transitions between them must follow particular rules.

const initialState = {
  status: "idle",
  error: null
};

function paymentReducer(state, action) {
  switch (action.type) {
    case "PAYMENT_STARTED":
      if (state.status !== "idle") {
        return state;
      }

      return {
        status: "processing",
        error: null
      };

    case "PAYMENT_SUCCEEDED":
      if (state.status !== "processing") {
        return state;
      }

      return {
        status: "success",
        error: null
      };

    case "PAYMENT_FAILED":
      if (state.status !== "processing") {
        return state;
      }

      return {
        status: "error",
        error: action.error
      };

    default:
      return state;
  }
}

Inside the component:

const [state, dispatch] = useReducer(
  paymentReducer,
  initialState
);

Instead of allowing different parts of the component to independently decide how the state should change, we dispatch actions describing what happened.

The reducer calculates the next state.

This creates a useful separation:

What happened vs. how the state should respond.

But a reducer doesn't automatically guarantee correctness.

We still need to define valid transitions, protect state invariants, and keep side effects outside the reducer.

In this example, initiating an actual payment request is a side effect, not something the reducer should perform.

5. Decision Authority vs. Transition Authority

There's an important distinction here.

Decision Authority determines which state management approach we should use.

State Transition Authority determines how state changes are evaluated and applied.

A reducer can centralize transition logic within a particular state boundary.

But that doesn't mean every state variable needs a reducer, or that every reducer needs a full state machine.

The architectural objective isn't to centralize everything.

It's to make decisions consistently while preserving the simplest appropriate implementation.

6. Beyond React Hooks: Zustand, Redux Toolkit, and Server State

The same decision criteria can extend beyond useState and useReducer.

When multiple components need the same state, we can first consider lifting state up or using Context.

When multiple features need shared client state, tools such as Zustand or Redux Toolkit may become appropriate.

If the primary challenge involves remote data fetching, caching, invalidation, and synchronization, a dedicated server-state solution such as TanStack Query or RTK Query can be more suitable.

These tools aren't necessarily mutually exclusive.

An application might use:

useState for local UI interactions.
useReducer for a complex form workflow.
Zustand or Redux Toolkit for shared client state.
TanStack Query or RTK Query for server-state management.

The decision depends on the responsibility of each state boundary.

7. A Practical Decision Framework

Here's a lightweight framework I would use before making a state management decision.

Question	Possible direction
Is the state local with simple, independent updates?	Start with `useState`
Are transitions governed by related rules?	Consider `useReducer`
Is state shared within a component subtree?	Consider lifting state or Context
Do independent features require shared client state?	Evaluate Zustand or Redux Toolkit
Does the state primarily represent remote server data?	Evaluate TanStack Query or RTK Query

This isn't a rigid rules engine.

A shared state doesn't automatically require a global store, and a complex state doesn't automatically require useReducer.

It's a framework for asking better questions before committing to an implementation.

8. The Bigger Architectural Principle

State management discussions often become comparisons between libraries.

Which is faster?

Which has less boilerplate?

Which is easier to learn?

Those questions matter, but they're secondary to understanding the problem.

I believe we should first establish consistent criteria for choosing a state management strategy.

Then evaluate available tools against those criteria.

Unify the decision criteria, not necessarily the tools.

That's the architectural principle I'm exploring here.

The real skill isn't knowing every state management library.

It's understanding why, when, and where each one belongs.

Final Thoughts

useState and useReducer aren't competing solutions where one must win.

They're different approaches to managing state, each valuable in the right context.

And the same reasoning applies when we move toward Context, Zustand, Redux Toolkit, or server-state solutions.

Let the problem define the tool, not the tool define the solution.

I'd love to hear how other developers approach these decisions.

Do you follow explicit state management criteria in your projects, or do team preferences and existing architecture usually drive the choice?

Part 1 of the State Management Decision Authority series.

Keep useful build work after closing the terminal

KhaledSalem — Mon, 19 Oct 2026 12:00:00 +0000

A small Ionify walkthrough: run a build, let the process exit, then return to the same app without deleting its local state.

You shouldn’t have to leave a terminal running just to preserve useful build work. In an existing, supported Ionify project, start with two separate invocations of the same build command. Keep the local state between them. Then change a visible label and check the built app. The point is practical: distinguish work that survives a process restart from work that exists only while a process is alive.

Why should a frontend developer care?

Closing a terminal should not make you lose the opportunity to reuse valid local work. This exercise gives you a small way to evaluate that boundary without replacing your team’s workflow or claiming a remote-cache result.

1. Build an unchanged baseline

Use an existing app configured according to the supported setup. Record the installed Ionify version, checkout revision, lockfile and exact command. This is not a standalone installation recipe.

pnpm exec ionify build
# Let this process exit. Keep the project's local state.
pnpm exec ionify build

Run each invocation to completion in a fresh process; for the second, open a new terminal in the same checkout. Preserve .ionify and the output directory, including workspace-root state in a monorepo. Do not change packages or configuration between builds. Check the production output after each invocation.

2. Make one visible source edit

In a component that your app imports and renders, replace the original button with the second version:

// Before
<button id="save-button">Save</button>
// After
<button id="save-button">Save draft</button>

These are illustrative JSX fragments; integrate one at a time into your existing component. Run the same build command in another fresh process, keeping local state. Do not add a different mode flag for the edited run.

3. Serve and inspect the production app

Use your project’s static preview setup against the generated output, not the dev server. The CLI’s default build output is dist; if your command explicitly selects another directory with --out-dir, serve that directory consistently. A simple local preview for a root-page app is:

python3 -m http.server 4173 --bind 127.0.0.1 --directory dist

Open http://127.0.0.1:4173/. Inspect #save-button and confirm its visible text is Save draft. A static Python server does not add SPA routing fallback; use your app’s normal preview server for routes that require it.

Expected: the new label appears. Observed: fill this in from your browser. No successful run, timing or internal work count is asserted by this walkthrough.

If the old label appears, preserve the evidence. Check which directory and origin are served and whether the browser reused an earlier response. A prior label experiment saw same-origin 304 reuse display the old label while a fresh origin serving the retained-state output displayed the new one. A new preview origin can help distinguish serving/browser-cache behavior; it is not evidence of universal cache correctness.

Keep the record small and honest

Installed version / checkout / command:
Same checkout and lockfile: yes/no
Engine state and output retained: yes/no
New process for each invocation: yes/no
Configuration unchanged: yes/no
Expected label / observed label:
Served directory / URL / browser-cache observations:
Elapsed observations, if actually collected:

Timing alone cannot reveal which internal work was skipped. Use only diagnostics the installed release supports. For a fresh-state comparison, keep this fixture intact and use a separate disposable copy. Local persistence and cross-machine reuse need different evidence.

Which part of returning to your project still makes you wait? Share the boundary you tested, even if the result was unfavorable.

Cover description: “The second build”: a terminal window floats above retained ivory and amber work tiles, with a faded window behind it. Conceptual illustration.

Conceptual illustration created with AI assistance for Ionify.

A CSS mutation test for your Ionify pilot

KhaledSalem — Wed, 14 Oct 2026 12:00:00 +0000

A shorter rebuild is useful when the page shows your latest change. This Ionify lab checks one visible result—a border changing from 2px to 6px—while keeping local engine state. Use a disposable, supported app and retain your normal styling packages.

Add an unmistakable rule

In a stylesheet already imported by the app:

.build-lab-card {
  border: 2px solid #b77928;
  padding: 1rem;
}

Apply the class to an element you can easily find. Build with pnpm exec ionify build and inspect the production output through your normal static preview server.

Now change only the border width to 6px. Build again without deleting the local engine state. Check the element's computed border width in the browser. Record the result, not just the time.

Which styling path did you try, and did the production border reach 6px?

Exercise the real styling path

If your app uses CSS Modules, repeat with a property in an imported module. If it uses a preprocessor or generated utility CSS, make a change that that pipeline must observe. Do not assume the plain-CSS result covers it.

Ionify's public setup describes CSS/CSS Modules support. Sass and Less still require their compiler packages. Tailwind and PostCSS need their normal packages and configuration. Follow the current configuration reference for the version under test.

Optional: record enough to debug

Project / report key:
Stylesheet mechanism:
Exact build command:
Starting state / state retained:
Changed source and value:
Expected computed style:
Actual production computed style:
Engine and styling package versions:
Config files involved:
Was a service worker or browser cache active?
Evidence: redacted screenshot or public reproduction URL

If the style is stale, first confirm the browser is serving the output you just built. Preserve the failure before clearing caches so the reproduction still explains what happened.

The purpose is a reliable edit-to-check loop. No style change needs to become a migration argument; it just needs to reach the app correctly.

Ionify v0.1.38 Is Live: From Native Packages to a Verified Developer Experience

KhaledSalem — Wed, 14 Oct 2026 06:39:05 +0000

Ionify v0.1.38 is now published on npm.

This release represents an important milestone for Ionify, a Rust-powered frontend build engine exploring a different approach to build infrastructure: persistent builds rather than repeatedly reconstructing the same knowledge.

What shipped?

Version 0.1.38 is published as nine npm packages: the main @ionify/ionify package and eight platform-specific native packages covering supported macOS, Windows, and Linux architecture targets.

The release preserves Ionify's hybrid packaging boundary while distributing native binaries through npm.

All nine packages are now available at version 0.1.38, with their latest dist-tags updated.

Verification beyond publishing

Publishing packages is only part of a release. The more important question is whether developers can install and actually use them.

For v0.1.38, I verified the experience against the real npm registry on macOS ARM64 with Node.js 22.20.0:

Fresh installation of @ionify/ionify@0.1.38
Native module loading and CLI execution
Actual npm create ionify@latest scaffolding
Dependency installation and successful build
Development server startup
Chrome navigation, direct route loading and page reload

The browser run completed without observed runtime errors. React Router future-flag warnings were recorded, and verification on other operating systems remains a separate concern.

The existing create-ionify@0.1.1 package continues to work without republishing, resolving the latest Ionify engine.

Why Ionify exists

Traditional frontend build workflows often repeat work across development, production builds and CI.

Ionify is built around a different architectural direction:

One Graph. One CAS. One Authority.

The goal is to make verified build facts reusable across lifecycle boundaries, while preserving deterministic execution and explicit ownership of build artifacts.

This release doesn't mean that every part of that vision is finished. It means the current published engine has passed a real consumer installation and startup path.

What's next?

The next engineering focus is bringing development, production artifact prewarming and production builds closer to a shared persistent authority.

That means improving reuse, reducing redundant transforms and validating correctness across lifecycle transitions.

The long-term goal isn't simply to make another bundler.

It's to make frontend build infrastructure remember what it already knows.

Try Ionify:

npm create ionify@latest

Website: https://ionify.cloud

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

javascript #rust #webdev #buildtools

Compare a leaf edit with a shared-helper edit

KhaledSalem — Mon, 12 Oct 2026 12:00:00 +0000

A tiny edit should not leave you guessing about the next build. This Ionify lab compares a footer-label change with a shared-helper change, so you can see what reached the production page and measure the wait from a comparable starting state.

Build a small shared path

// src/formatLabel.ts
export const formatLabel = (name: string) => name.trim();

Use the helper in two components that your app actually imports and displays:

import { formatLabel } from './formatLabel';

export function Header() {
  return <h1>{formatLabel(' Build Lab ')}</h1>;
}

export function Footer() {
  return <footer>{formatLabel(' Ready ')}</footer>;
}

The example illustrates the relationship. Adapt component placement and imports to your app rather than introducing duplicate exports.

Case A: local visible text

Establish a build with pnpm exec ionify build. Change “Ready” to “Ready to test” in the footer. Build again. Check the production footer and record time, starting state and output differences.

Case B: shared behavior

Return to the same baseline in your disposable checkout and establish it again. Change the helper from name.trim() to name.trim().toUpperCase(). Build and verify that both header and footer change.

Do not compare Case B against an unrelated cold baseline. Keep the starting state and measurement boundary explicit. Repeat both experiments rather than reporting a single favorite run.

Interpret the difference

Both cases modify one file. Case B affects multiple consumers. A correct engine may need wider work, even if an unchanged artifact remains reusable elsewhere.

A faster timer is not proof of a particular invalidation path. Pair it with available diagnostics and output checks. If both consumers do not update, minimize that reproduction and report it.

The developer takeaway is practical: a source file's size and its change's reach are different things. Which case changed both consumers in your test? A one-line answer is welcome.

If you want to share a reproducible report

Include a project/report key, tool version, exact command, starting state, mutation, expected/actual output and a redacted screenshot or public reproduction.

Use an output inventory to investigate a repeat build

KhaledSalem — Fri, 09 Oct 2026 12:00:00 +0000

A production build returning exit code zero is necessary, but it does not tell you which artifacts changed. This lab adds a small read-only inventory helper. It does not claim to prove runtime correctness.

Create inventory.mjs outside the output directory:

import { readdir, readFile } from 'node:fs/promises';
import { resolve, relative, join } from 'node:path';
import { createHash } from 'node:crypto';

const root = resolve(process.argv[2] ?? 'dist');
async function walk(dir) {
  const entries = await readdir(dir, { withFileTypes: true });
  const rows = [];
  for (const entry of entries.sort((a, b) => a.name.localeCompare(b.name))) {
    const path = join(dir, entry.name);
    if (entry.isDirectory()) rows.push(...await walk(path));
    else if (entry.isFile()) {
      const bytes = await readFile(path);
      rows.push({
        file: relative(root, path).split('\\').join('/'),
        bytes: bytes.length,
        sha256: createHash('sha256').update(bytes).digest('hex'),
      });
    }
  }
  return rows;
}
console.log(JSON.stringify(await walk(root), null, 2));

This helper includes regular files and skips symbolic links. Use the actual output directory if it is not dist. It fails if the directory cannot be read rather than treating a missing build as an empty success.

Compare two states

pnpm exec ionify build
node inventory.mjs dist > before.json
# Change one visible string in an imported component.
pnpm exec ionify build
node inventory.mjs dist > after.json

Keep the JSON files outside dist. Compare filenames, byte counts and hashes with your normal diff tool. Content-hashed names can turn a change into an addition and removal, so do not compare only matching filenames.

Serve the production output and check the edited label. Repeat without another source change and inspect any unexpected artifact differences. Timestamps, source maps or environment-dependent content can require explanation; a changed hash alone does not identify the cause.

This is a diagnostic tool, not an Ionify feature or a security audit. It helps turn “the build felt strange” into a precise observation that a maintainer can investigate.

Add an Ionify pilot command while keeping your existing build

KhaledSalem — Wed, 07 Oct 2026 12:00:00 +0000

This lab adds an experimental path without replacing your current one. Use a branch or separate checkout, not an unreviewed change to production CI.

Check the prerequisites

Read the current setup guide and support boundaries. The public 0.1.37 package declares Node 22.x or 24.x. Keep optional dependencies enabled because they carry the native engine. Check the installed package if you use a newer release.

Install into the pilot checkout:

pnpm add -D @ionify/ionify

Record the resolved version from your lockfile. Avoid describing an experiment only as “latest.”

Point at your actual entry

For an app whose entry is src/main.tsx, create ionify.config.ts:

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

export default defineConfig({
  entry: '/src/main.tsx',
});

This config does not create an app or replace required HTML/framework configuration. Adapt it to the project rather than copying a path that does not exist.

Add these scripts alongside your existing scripts:

{
  "dev:ionify": "ionify dev",
  "build:ionify": "ionify build"
}

The snippet is the content to add inside package.json's existing scripts object, not a replacement package file.

Verify the app before the timer

Run pnpm run dev:ionify. Check a route, a static asset, styling and a dynamic import used by the app. Then run pnpm run build:ionify and check the production output through your normal preview server.

Record the first build, an unchanged build and a build after a visible component edit separately. Do not run two engines concurrently into the same output directory. Preserve each output for comparison or use isolated checkouts.

Keep the existing deployment command until correctness, integration support and the repeated workflow have been evaluated. If the pilot does not help, you have learned that cheaply. If it fails, the isolated checkout is already the beginning of a useful reproduction.

Measure three build states without mixing them together

KhaledSalem — Mon, 05 Oct 2026 12:00:00 +0000

A useful build test tells you which wait improved. This lab gives you three observations you can compare later: first run, unchanged run and one visible edit.

Use a disposable checkout of a supported app with Ionify already configured. Keep your normal build command. Check the setup requirements, including the package's Node version and native optional dependencies.

1. Name the starting state

Record the installed Ionify version, Node version, operating system, package lockfile and configuration. For the first run, say whether local engine state or output already exists. Do not call a run cold merely because you opened a new terminal.

Run:

pnpm exec ionify build

Use your shell's elapsed-time facility or an external timer around the complete invocation. State whether the number includes process startup. Do not mix a tool's internal phase timer with an external wall-clock time.

2. Repeat without a change

Keep the local .ionify state and output directory. Run the same command again. Record this as an unchanged build, separately from the first run.

3. Make a visible edit

In an imported component, change a literal label such as “Save” to “Save draft.” Run the command again, serve the production output using your normal static preview setup, and verify that the new label appears. Then make one more unchanged run.

Copy this result template:

Tool and version:
Node / OS / hardware:
Command and timer boundary:
Starting engine/output state:
First run:
Unchanged run:
Edited run:
Next unchanged run:
Correct output checked:
Raw observations / reproduction:

Repeat the sequence, preserve every trial and note background activity. Do not silently discard a slow run.

Ionify aims to reuse valid local work. This test does not establish remote-cache behavior, HMR latency or compatibility with every integration. A single edited file can still require wider work. The result that matters is a shorter wait for the correct app.

If something fails, share a minimal reproduction through Ionify's issue tracker, without secrets or private source.

Ionify 0.1.37 Is Here: 30ms No-Change Builds and ~120ms One-File Rebuilds

KhaledSalem — Wed, 23 Sep 2026 08:48:08 +0000

Ionify 1.0.37 is here.

⠀
Here’s the part I care about most.
⠀
Test project:
⠀

⠀
~15,000 React components
⠀
~25,000 dependencies
⠀
Production build
⠀

⠀
Vite 8:
⠀

⠀
Initial build        ~2.7s
⠀
No-change build      ~2.7s
⠀
One-file change      ~2.7s
⠀

⠀
Ionify:
⠀

⠀
Initial build        ~5s
⠀
No-change build      ~30ms
⠀
One-file change      ~120ms
⠀

⠀
Yes, Ionify currently loses the first build.
⠀
That is something I’m actively working on.
⠀
But the interesting part starts after the first build.
⠀
If nothing changed, Ionify tries not to rebuild anything.
⠀
If one source changed, the goal is to rebuild the affected work rather than traverse and reproduce the entire project again.
⠀
Conceptually:
⠀

⠀
traditional repeated build
⠀
project
⠀
  ↓
⠀
scan
⠀
  ↓
⠀
resolve
⠀
  ↓
⠀
transform
⠀
  ↓
⠀
bundle
⠀
  ↓
⠀
emit
⠀

⠀
Ionify increasingly behaves more like:
⠀

⠀
known project state
⠀
       ↓
⠀
what changed?
⠀
       ↓
⠀
affected work
⠀
       ↓
⠀
reuse everything else
⠀

⠀
That sounds obvious.
⠀
But at scale, the difference becomes significant.
⠀
A build system shouldn’t only become faster because parsing, transforms or bundling became faster.
⠀
It should become faster because most of the previous work no longer needs to happen.
⠀

Fewer plugins by default

⠀
There is another part of Ionify that I’ve learned matters a lot when showing it to frontend developers:
⠀
plugin fatigue is real.
⠀
Plugins are useful. Ionify supports them, and the README now documents the supported plugin surface.
⠀
But the engine shouldn’t require a plugin for every fundamental part of the frontend workflow.
⠀
My direction with Ionify is:
⠀

⠀
strong core
⠀
+
⠀
plugins when you actually need extension
⠀

⠀
rather than:
⠀

⠀
small core
⠀
+
⠀
plugins required to assemble the normal workflow
⠀

⠀
So the practical pitch for Ionify is becoming very simple:
⠀
Fast builds. Fewer plugins. Less repeated work.
⠀
The architecture underneath that is more complicated, of course.
⠀
Ionify keeps persistent knowledge about previous work, tracks ownership of verified results, and tries to invalidate only the work affected by a change.
⠀
But you shouldn’t need to understand the architecture before the product becomes useful.
⠀
The result should explain itself.
⠀
Change one file.
⠀
Build again.
⠀
And watch how little work actually needs to happen.
⠀
Ionify is open source and still early.
⠀
0.1.37 is another step toward making frontend builds incremental by default rather than repeatedly rebuilding what the system already knows.

Vite Builds My Project in 2.7s. The Next Ionify Build Takes 50ms. Here's Why.

KhaledSalem — Tue, 15 Sep 2026 09:33:17 +0000

Vite is fast.

I'm not trying to argue otherwise.

Its development experience and HMR are a big part of why it became the default choice for a huge part of the frontend ecosystem.

But I wanted to test something else:

What happens when we repeatedly run production builds on a large project?

I benchmarked Vite against Ionify using a real React project with:

15,000 React components
25,000 dependencies
Production builds

Here are the results.

Build	Vite	Ionify
Initial build	2.7s	6s
No changes	2.7s	50ms
One file changed	2.7s	120ms

The obvious result is that Vite wins the first build.

2.7 seconds versus 6 seconds.

No argument there.

But look at what happens afterward.

Vite's build time stays roughly constant.

Ionify drops from seconds to milliseconds.

That's the behavior I care about.

Why does the second build change so much?

Ionify doesn't treat every build as a completely new execution.

The first build establishes verified knowledge about the project.

After that, the engine attempts to reuse that knowledge rather than recompute it.

So a no-change build shouldn't mean:

scan everything
resolve everything
transform everything
bundle everything
discover that nothing changed

It should be much closer to:

load known project state
verify identities
observe no meaningful change
reuse published results

And if one file changes:

identify affected work
invalidate only what depends on it
reuse everything else

That's the model.

Build Authority

Internally, I describe this architecture as Build Authority.

The basic rule is:

Every category of verified work should have one authoritative owner.

For example, imagine multiple stages in a frontend toolchain independently deciding how a dependency should be resolved.

Even if every stage is fast, you're still repeating knowledge.

Authority says:

dependency resolution
        ↓
single authority
        ↓
published verified result
        ↓
dev / build / CI consume it

Not:

dev resolves dependencies
build resolves dependencies
optimizer resolves dependencies
CI resolves dependencies

The goal isn't just faster code.

The goal is eliminating repeated reasoning.

Why this is different from "just cache it"

A cache tells you:

I have an artifact for key X.

Authority also tells you:

This system owns the truth for X,
this result was produced under these conditions,
and downstream consumers should not independently recreate it.

That gives you a stronger invariant.

Instead of multiple systems producing equivalent answers and hoping they agree, one layer publishes the answer and everyone else consumes it.

That is particularly useful when dealing with things like:

dependency resolution
transformed modules
dependency publication
dependency export surfaces
CSS artifacts
build graphs
production plans

The architecture starts becoming less about a pipeline of repeated computations and more about a graph of published knowledge.

The 6-second problem

There is one number in the table I definitely don't want to hand-wave away:

Ionify's first build takes around 6 seconds.

That's more than twice the Vite result in this benchmark.

It's currently the weak point.

Some of that cost comes from establishing the state that later builds reuse.

But architectural justification doesn't make six seconds good.

So first-build performance is the next area I'm focusing on.

The ideal outcome isn't:

slow first build
fast later builds

It's:

fast first build
almost nothing to do afterward

The bigger question

The interesting question for me isn't really:

Can Ionify beat Vite in a benchmark?

It's:

How much frontend build work exists only because our tools keep forgetting what they already know?

Compilers already understand incremental computation.

Build systems already understand dependency graphs.

Content-addressable storage already understands immutable identity.

The experiment behind Ionify is to combine those ideas around one rule:

verified knowledge should persist until something actually invalidates it.

That's what produces the 50ms no-change build.

Not because the engine executes the same build dramatically faster.

Because most of the build no longer needs to happen.

The full Build Authority model is here:

https://ionify.cloud/build-authority

Ionify is open source and still early.

If you're interested in build systems, I'd actually prefer you try to break the model rather than just trust the benchmark.

Run it against a real project.

Change weird things.

Invalidate dependencies.

Push it into cases where incremental systems normally fall apart.

Then tell me where the authority model stops holding.

Starting Ionify on GitHub to help keep development at:https://github.com/ionifyjs/ionify