TanStack Redact vs React: What Changes When You Switch?

React is widely used to build interactive web applications, but its browser runtime adds JavaScript to every production build. For a small application, that cost may be acceptable. For a website that serves many pages or users on slower devices, reducing the amount of JavaScript can improve loading performance.

TanStack Redact offers another option. It is a smaller, React-compatible runtime designed to run existing React components and hooks without requiring developers to rewrite their application code. Instead of using the standard React runtime in the browser, a build-time integration replaces it with Redact.

The main difference is not the component syntax. It is how the runtime handles rendering and scheduling.

Redact aims to keep the React APIs developers already use while removing some of the complexity associated with React's concurrent rendering model. That trade-off can reduce bundle size, but it also means some React features behave differently.

This article compares TanStack Redact with React, explains how to try Redact in a Vite application, and identifies the situations where switching makes sense.

What Is TanStack Redact?

TanStack Redact is a lightweight runtime for applications written with React. It implements many of the React APIs used to render components, manage state, handle events, and update the DOM.

The goal is straightforward: let developers keep their existing React components while shipping a smaller browser runtime.

For example, a component can continue to use familiar React imports:

import { useState } from "react";

export default function Counter() {
    const [count, setCount] = useState(0);

    return (
        <button onClick={() => setCount(value => value + 1)}>
            Count: {count}
        </button>
    );
}

When an application is configured to use Redact, the build integration redirects supported React imports to the alternative runtime.

The component itself does not need to be rewritten simply because the application uses Redact in the browser.

However, API compatibility does not mean complete behavioral equivalence. Redact uses synchronous rendering rather than React's concurrent scheduling. Some APIs related to transitions, deferred rendering, optimistic updates, and other advanced features have different behavior or limitations.

That distinction should guide the decision to adopt it.

TanStack Redact vs React: Key Differences

The following table summarizes the main differences developers should evaluate.

Area	React	TanStack Redact
Primary purpose	General-purpose UI library and runtime	Smaller React-compatible runtime
Component syntax	JSX and React APIs	Retains supported React-style components and APIs
Browser bundle	Includes React's rendering and scheduling capabilities	Designed to reduce browser runtime size
Rendering model	Supports concurrent rendering and scheduling	Uses synchronous rendering
Transitions	Can schedule non-urgent updates	Transition APIs do not provide React's concurrent scheduling behavior
Deferred updates	Supports APIs such as `useDeferredValue`	Does not provide the same deferred-rendering behavior
Suspense	Supports React's Suspense model	Implements supported Suspense behavior with compatibility limitations
Server Components	Supported through compatible React frameworks	Uses upstream React for the Server Components environment
Ecosystem compatibility	Broad and established	Depends on the runtime's supported API surface and integrations
Migration effort	No change when staying with React	Build configuration changes, followed by compatibility testing

Redact is not a replacement for every React capability. It is an alternative for applications that can benefit from a smaller runtime without relying on behavior that Redact does not implement.

Why Bundle Size Matters

Every JavaScript file sent to the browser must be downloaded, parsed, and evaluated before or while the application becomes interactive.

Reducing JavaScript can help, particularly on mobile devices, slower networks, and pages where the framework runtime represents a meaningful part of the total payload.

TanStack's published comparisons report a substantially smaller runtime than React in their benchmark configurations. These figures describe runtime bundles, not the complete JavaScript payload of a production application.

For example, an application may still include a large charting library, an editor, analytics code, and several other dependencies. Replacing the React runtime does not remove those packages.

A smaller runtime also does not guarantee that every page becomes faster. Rendering behavior, hydration, effects, Suspense retries, and application-specific workloads can produce different results.

The right question is not simply whether Redact has a smaller bundle. It is whether the change improves the application's actual performance without compromising the features it needs.

How to Try TanStack Redact in a Vite Application

Before switching an existing application, create a separate branch and establish a baseline for bundle size, page performance, and automated test results.

The following example shows the general setup for a Vite application using the React plugin.

Step 1: Install the package

Install TanStack Redact in your project:

npm install @tanstack/redact

Keep your existing React dependencies while preparing the migration. Follow the installation instructions for the Redact release you choose, because supported integrations and package requirements can change.

Step 2: Configure the Vite build

Update your Vite configuration to include the Redact plugin.

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { redact } from "@tanstack/redact/vite";

export default defineConfig({
    plugins: [
        react(),
        redact()
    ]
});

The React plugin continues to support the application's React development workflow, while the Redact plugin configures the alternative runtime for the build.

Use the configuration recommended by the installed Redact release. Do not assume that every Vite plugin combination or third-party integration will work without adjustment.

Step 3: Keep existing component imports

Your application can continue using its familiar imports:

import { useState, useEffect } from "react";
import { createRoot } from "react-dom/client";

function StatusPanel() {
    const [status, setStatus] = useState("Loading");

    useEffect(() => {
        setStatus("Ready");
    }, []);

    return <p>Application status: {status}</p>;
}

createRoot(document.getElementById("root")).render(
    <StatusPanel />
);

The component still uses React-style state, effects, and DOM rendering APIs. The build integration handles the runtime replacement.

This small example confirms basic rendering, but it is not enough to approve a production migration. Existing applications often rely on more complex behavior involving forms, routing, hydration, Suspense, and third-party libraries.

Step 4: Build and test the application

Run the same build and test commands used by your project.

npm run build
npm test

If your project uses a separate end-to-end test command, run that as well.

Compare the resulting production bundle with the baseline. Test the pages that matter most to users, including initial navigation, client-side navigation, form submission, error handling, and interactive components.

A successful build confirms that the bundler can produce an output. It does not establish full runtime compatibility.

What Changes When You Switch?

The biggest changes appear in areas where React relies on scheduling or specific runtime behavior.

1. Rendering Becomes Synchronous

React can schedule work according to priority and interrupt certain rendering work to keep interactions responsive.

Redact uses synchronous rendering. An update runs without React's concurrent scheduling model.

This can simplify the runtime, but it changes the way expensive updates behave.

Consider a component that filters a very large list after every keystroke. If the filtering and rendering work take too long, synchronous updates can delay subsequent input handling.

Before switching, profile expensive components and consider techniques such as debouncing, pagination, list virtualization, and moving suitable calculations outside the rendering path.

2. Transition APIs Do Not Have the Same Behavior

React supports APIs such as useTransition and startTransition to mark certain updates as non-urgent.

Redact exposes compatible transition APIs, but it does not provide React's concurrent scheduling. Transition work runs synchronously, and the pending state does not behave like React's normal transition tracking.

Similarly, useDeferredValue does not provide the same deferred-rendering behavior.

Applications that rely on transitions to keep search inputs responsive while rendering large results should receive particular attention during migration.

3. Suspense and Hydration Need Testing

Suspense, server rendering, and hydration are important parts of modern React applications.

Redact implements supported Suspense and hydration behavior, but applications should not assume that every edge case behaves identically to upstream React.

Test loading fallbacks, server-rendered pages, hydration recovery, error boundaries, and navigation flows.

For framework-based applications, confirm which runtime handles each part of the rendering process. In supported Next.js and Vinext integrations, for example, upstream React remains responsible for the server-side React and Server Components environment while Redact handles browser rendering.

Do not assume that configuring a client runtime means replacing React throughout the entire application.

4. Some Advanced APIs Have Limitations

Redact aims for compatibility with the APIs used by typical applications, but certain APIs have documented differences.

For example, its transition and deferred-value APIs do not provide React's concurrent scheduling. Some action-related and optimistic-update APIs also have limitations.

If your application uses these features, inspect the compatibility documentation for the exact Redact version before switching.

When Should You Use Redact Instead of React?

Redact is worth evaluating when the application is sensitive to JavaScript payload size and does not depend heavily on React's concurrent rendering behavior.

Application type	Recommendation	Reason
Content-focused website	Evaluate Redact	Reducing runtime JavaScript may benefit pages with relatively simple interactions
Documentation portal	Evaluate Redact	Many pages have predictable rendering needs
Interactive dashboard	Test carefully	Large updates and scheduling behavior may affect responsiveness
Complex data editor	Test carefully	Forms, optimistic updates, and frequent state changes need close review
Application heavily using transitions	Prefer React unless testing proves otherwise	Redact does not provide React's concurrent transition behavior
Application with complex Server Components integration	Verify framework support first	The server and browser may use different runtimes
Existing application with many third-party libraries	Run a compatibility pilot	Dependencies may rely on specific React behavior

These recommendations are starting points, not guarantees. Measure the actual application before deciding.

Best Practices for a Safe Migration

Establish a baseline before changing the runtime

Record the production JavaScript bundle size and measure important user journeys. Use repeatable tests and comparable build settings so the results are meaningful.

Audit advanced React features

Search the codebase for useTransition, useDeferredValue, useOptimistic, useActionState, Suspense boundaries, and other APIs that could expose behavioral differences.

Review how those features are used rather than relying only on a list of imports.

Test real user workflows

Automated component tests are useful, but they may not reveal every hydration or scheduling issue.

Include end-to-end tests for authentication, navigation, forms, loading states, error recovery, and important interactions.

Keep a rollback path

Make the runtime replacement a small, isolated change. Keep the previous build configuration available so the team can revert quickly if compatibility or performance problems appear.

Measure more than bundle size

Track initial load performance, interaction responsiveness, hydration, memory use, and errors in the browser console.

A smaller runtime is valuable only when the overall application benefits from the change.

Common Mistakes to Avoid

One common mistake is assuming that React-compatible imports mean every React feature works identically. Compatibility must be evaluated at the behavior level, especially for concurrent features.

Another mistake is comparing runtime bundle sizes with total application bundle sizes. Keep the measurements separate so the results are not misleading.

Developers may also enable Redact across an entire application before testing third-party packages. A smaller pilot gives the team a chance to identify incompatible dependencies before a broad rollout.

Finally, avoid choosing a runtime based only on microbenchmarks. Performance varies by workload, browser, device, and application architecture.

Advantages and Disadvantages

Advantages

Reduces the size of the browser runtime in supported configurations.
Allows many existing React components and imports to remain unchanged.
Can be integrated into supported build tools without redesigning the component model.
Provides an option for applications that do not need React's concurrent scheduling.
Lets teams evaluate a smaller runtime through a controlled migration.

Disadvantages

Does not provide React's concurrent scheduling model.
Some APIs have different behavior or incomplete functionality.
Third-party library compatibility must be verified.
Hydration and Suspense behavior require testing.
A smaller runtime does not guarantee better whole-application performance.

Summary

TanStack Redact gives React developers another way to reduce browser JavaScript without rewriting every component. Its main advantage is a smaller runtime, while its main trade-off is synchronous rendering and the absence of React's concurrent scheduling model.

For a content-focused site or an application with straightforward interactions, Redact may be worth testing. For a complex application that relies on transitions, deferred updates, optimistic actions, or advanced rendering behavior, React may remain the better choice.

Start with a production build, measure the existing application, test Redact on a limited set of pages, and verify the compatibility of the features your users depend on. The decision should come from application-level evidence rather than bundle size alone.