DEV Community: Norah Aiden

React Compiler vs. useMemo: Real Benchmarks

Norah Aiden — Wed, 06 May 2026 15:43:00 +0000

The React Compiler (formerly "React Forget") shipped stable in React 19. The promise? Automatic memoization — no more hand-crafting useMemo, useCallback, and React.memo wrappers. Just write plain React, and the compiler handles the rest.

But does it actually hold up? I ran a battery of benchmarks across real-world-ish scenarios to find out.

What the React Compiler Actually Does

Before we dive into numbers, a quick clarification. The React Compiler is a build-time Babel/SWC transform that analyzes your component tree and automatically inserts memoization where it's safe to do so. It rewrites your components to cache computed values and prevent unnecessary re-renders — all at compile time.

useMemo and useCallback, by contrast, are runtime hooks that you manually place to signal: "cache this between renders."

They're solving the same problem, but at different layers of the stack.

The Test Setup

All benchmarks were run with:

React 19.1 (stable compiler enabled via babel-plugin-react-compiler)
Vite 6 dev build (production builds for final results)
Node 22, MacBook Pro M3
React DevTools Profiler + performance.now() for timing
5 runs each, median reported

Three scenarios were tested:

Heavy list rendering — 5,000 items, filtered + sorted
Deeply nested form — 12-level component tree with shared context
Real-time data dashboard — updates every 100ms, chart + table + stats panel

Benchmark 1: Heavy List Rendering

This is the classic useMemo use case — filtering and sorting a large array that shouldn't recompute unless the source data or filter criteria change.

The Manual Version

function ProductList({ products, filterText, sortBy }) {
  const filtered = useMemo(() => {
    return products
      .filter(p => p.name.includes(filterText))
      .sort((a, b) => a[sortBy] > b[sortBy] ? 1 : -1);
  }, [products, filterText, sortBy]);

  return filtered.map(p => <ProductRow key={p.id} product={p} />);
}

The Compiler Version

// No useMemo — compiler handles it
function ProductList({ products, filterText, sortBy }) {
  const filtered = products
    .filter(p => p.name.includes(filterText))
    .sort((a, b) => a[sortBy] > b[sortBy] ? 1 : -1);

  return filtered.map(p => <ProductRow key={p.id} product={p} />);
}

Results

Scenario	No Memo	`useMemo`	React Compiler
Initial render	41ms	43ms	42ms
Re-render (no change)	38ms	2ms	3ms
Re-render (filter change)	40ms	41ms	40ms
Re-render (unrelated state)	37ms	2ms	2ms

Takeaway: The compiler matched manual useMemo almost exactly. Both deliver ~19× speedup on unnecessary re-renders vs. the unmemoized baseline. The compiler correctly detected that filtered only needs recomputation when products, filterText, or sortBy change.

Benchmark 2: Deeply Nested Form

This is where things get more interesting. A 12-level deep component tree with a shared FormContext. Each field conditionally shows a validation error. Typing in one field shouldn't re-render siblings.

This is also where useMemo gets painful to manage manually — you need useCallback on handlers, useMemo on derived values, and React.memo on subtrees. It's easy to miss one.

The Manual Version (abbreviated)

const FormSection = React.memo(({ sectionId, fields }) => {
  const sectionErrors = useMemo(
    () => errors.filter(e => e.sectionId === sectionId),
    [errors, sectionId]
  );

  const handleChange = useCallback((fieldId, value) => {
    dispatch({ type: 'SET_FIELD', sectionId, fieldId, value });
  }, [sectionId, dispatch]);

  return fields.map(field => (
    <FormField
      key={field.id}
      field={field}
      error={sectionErrors.find(e => e.fieldId === field.id)}
      onChange={handleChange}
    />
  ));
});

Results

Metric	Unmemoized	Manual `useMemo`	React Compiler
Typing latency (p50)	28ms	6ms	7ms
Typing latency (p99)	61ms	11ms	12ms
Components re-rendered per keystroke	47	3	4
Lines of memoization boilerplate	0	31	0

Takeaway: Compiler performance is nearly identical to manual memoization. The one extra component re-render was from a context consumer the compiler conservatively chose not to memoize — a correct-but-cautious call. The real win here is 31 fewer lines of boilerplate that you can also mess up.

Benchmark 3: Real-Time Dashboard

A dashboard polling every 100ms — chart updates with new data points, a live table, and a stats strip. The tricky part: the chart and table share a data source, but the stats panel derives independent aggregates.

This scenario stresses the compiler's ability to detect partial dependency changes — something humans often get wrong.

function Dashboard({ rawData }) {
  // Compiler version — no manual memoization
  const chartData = transformForChart(rawData);
  const tableData = transformForTable(rawData);
  const stats = computeStats(rawData); // expensive aggregate

  return (
    <>
      <StatsStrip stats={stats} />
      <LineChart data={chartData} />
      <DataTable rows={tableData} />
    </>
  );
}

Results (per 100ms update cycle)

Metric	Unmemoized	Manual `useMemo`	React Compiler
CPU time per update	22ms	5ms	6ms
Dropped frames (over 30s)	14	0	1
JS heap growth (MB/min)	2.3	0.4	0.5
Render budget exceeded (>16ms)	31%	0%	2%

Takeaway: The compiler gets very close to hand-tuned results. The 2% budget exceedance vs. 0% for manual came from a single edge case: on the first render after a large data spike, the compiler's cache invalidation triggered a cascade that a human would have caught by splitting useMemo more granularly.

Where the Compiler Wins

1. It's always-on. Every computed value gets memoized if it's safe. Humans forget to wrap things — especially in new components added 6 months after the initial "optimized" pass.

2. It handles prop stability automatically. Inline object literals and arrow functions passed as props (onClick={() => foo()}) are classic performance traps. The compiler stabilizes these references at the call site.

3. No dependency array bugs. Stale closures from wrong useMemo deps are a common production issue. The compiler's static analysis doesn't have this class of bug.

4. Less surface area. Fewer hooks = fewer tests needed to validate memoization behavior = faster code review.

Where `useMemo` Still Wins (or Ties)

1. Surgical optimization. If you're chasing 1-2ms of render budget on a specific hot path, manual useMemo lets you be more precise. You can split one expensive computation into multiple cached chunks in ways the compiler's heuristics don't always replicate.

2. Async + external cache integration. If your memoized value depends on something from a library like Zustand, Jotai, or a React Query result, the compiler may be overly conservative. Manual hooks give you full control.

3. Debugging. When a component re-renders unexpectedly, you can audit useMemo deps with DevTools. The compiler's implicit memoization is harder to introspect — you'd need to look at the compiled output.

4. Legacy codebases. The compiler requires React 19 and specific project setups. If you're on React 17/18 or have custom Babel pipelines, useMemo is what you've got.

The "Can I Just Enable the Compiler and Delete My useMemos?" Question

Mostly yes — with caveats.

In my tests, enabling the compiler on a codebase that already had manual memoization produced no regressions and a slight improvement (the compiler optimized a few spots I'd missed). You can leave your existing useMemo calls in place — the compiler respects them.

But I wouldn't do a mass-delete of your useMemos without profiling before and after. There are always edge cases.

Verdict

Criterion	Winner
Performance (typical app)	🤝 Tie
Performance (extreme hot paths)	`useMemo`
Developer experience	React Compiler
Debuggability	`useMemo`
Safety (no dep array bugs)	React Compiler
Legacy compatibility	`useMemo`

The React Compiler is not magic — it's a well-engineered static analysis tool that handles 95% of real-world memoization correctly. For the other 5%, you still need useMemo.

My recommendation: enable the compiler, stop writing useMemo for new code, and reach for it manually only when profiling shows you need more control.

The era of spending 30% of a code review discussing whether a useCallback dependency array is correct should be behind us.

ChatGPT vs Claude vs Gemini: Which AI Is Better for Coding and Content Writing?

Norah Aiden — Tue, 05 May 2026 13:45:26 +0000

Artificial intelligence tools have moved from “interesting experiments” to daily work companions. Whether you're debugging code at 2 AM, drafting a blog post, or brainstorming product ideas, chances are you've tested one (or all) of the big three: ChatGPT, Claude, and Gemini.

But which one actually performs best for coding and content writing?

After comparing them across real-world use cases, here’s a practical breakdown.

The Contenders

1. ChatGPT (OpenAI)

ChatGPT is arguably the most mainstream AI assistant right now. It’s widely used by developers, marketers, students, and businesses.

What stands out:

Strong balance between technical accuracy and conversational quality
Large ecosystem with integrations, APIs, and custom GPTs
Reliable for brainstorming, editing, coding, and structured tasks

Best for:

Full-stack coding help
Debugging and code explanations
Blog writing and editing
Research summaries
Workflow automation

Strengths:

Handles complex prompts well
Great code generation in Python, JavaScript, SQL, and more
Can switch between technical and creative tasks smoothly

Weaknesses:

Sometimes overly verbose
May confidently generate incorrect information if prompts are vague

Example use cases:

“Build a React dashboard with authentication”
“Rewrite this blog in a more engaging tone”
“Explain this API error”

2. Claude (Anthropic)

Claude has developed a strong reputation among writers and developers who prefer cleaner, more natural responses.

What stands out:

Excellent long-form writing quality
Strong context handling for long documents
Thoughtful, readable outputs

Best for:

Long articles
Documentation review
Codebase analysis
Editing and rewriting

Strengths:

Natural writing style feels less robotic
Handles large text inputs exceptionally well
Good at nuanced editing and summarization

Weaknesses:

Can be more cautious or restrictive
Sometimes less direct for coding-specific fixes

Example use cases:

Reviewing a 5,000-line code file
Improving brand voice consistency
Summarizing legal or technical documents

3. Gemini (Google)

Gemini’s biggest advantage is ecosystem integration. If you live inside Google products, it becomes much more useful.

What stands out:

Native Google integration
Search-aware capabilities
Good multimodal features

Best for:

Google Docs/Gmail workflows
Research tasks
Spreadsheet analysis
Productivity assistance

Strengths:

Strong web-connected workflows
Useful inside Workspace
Good for multimodal tasks (images, docs, etc.)

Weaknesses:

Coding can feel less consistent than competitors
Writing output sometimes lacks personality or depth

Example use cases:

Drafting emails in Gmail
Summarizing Docs
Spreadsheet formula assistance

Coding Comparison

Feature	ChatGPT	Claude	Gemini
Debugging	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Code generation	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Refactoring	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Large code context	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
API help	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐

Winner for Coding: ChatGPT

For developers, ChatGPT currently offers the most complete experience:

Fast iteration
Strong debugging
Better code generation across frameworks
Broad language support

Claude is close behind, especially for reviewing large codebases.

Gemini is improving, but still feels more productivity-focused than engineering-focused.

Content Writing Comparison

Feature	ChatGPT	Claude	Gemini
Blog writing	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Tone adaptation	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Long-form writing	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
SEO writing	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Editing	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐

Winner for Writing: Claude (slightly)

Claude shines in:

Long-form content
More human-sounding drafts
Editing and rewriting

ChatGPT is extremely close and often better for:

SEO structure
Faster ideation
Content strategy
Multi-format output

Gemini works well for quick productivity tasks, but feels less polished for serious writing workflows.

Final Verdict

There isn’t a universal winner—only better fits depending on your workflow.

Choose ChatGPT if you:

Code frequently
Need fast debugging and prototyping
Want one tool for both coding and writing
Value ecosystem and integrations

Choose Claude if you:

Write long-form content regularly
Need document-heavy workflows
Review large codebases or research files

Choose Gemini if you:

Work heavily in Google Workspace
Need search-connected productivity help
Prefer Google-native integrations

My Recommendation

If you want one AI tool for both coding and content writing, ChatGPT is currently the most balanced choice.

If your work is primarily writing-heavy, Claude may feel more natural.

If your workflow revolves around Google products, Gemini is the most convenient.

The real power move? Many professionals now use all three strategically:

ChatGPT for execution
Claude for refinement
Gemini for productivity workflows

AI tools are becoming specialized. The best users aren’t loyal to one platform—they know when to switch.

Which AI do you use most for coding or writing?

DEV Community: Norah Aiden

React Compiler vs. useMemo: Real Benchmarks

What the React Compiler Actually Does

The Test Setup

Benchmark 1: Heavy List Rendering

The Manual Version

The Compiler Version

Results

Benchmark 2: Deeply Nested Form

The Manual Version (abbreviated)

Results

Benchmark 3: Real-Time Dashboard

Results (per 100ms update cycle)

Where the Compiler Wins

Where useMemo Still Wins (or Ties)

The "Can I Just Enable the Compiler and Delete My useMemos?" Question

Verdict

Further Reading

ChatGPT vs Claude vs Gemini: Which AI Is Better for Coding and Content Writing?

The Contenders

1. ChatGPT (OpenAI)

2. Claude (Anthropic)

3. Gemini (Google)

Coding Comparison

Winner for Coding: ChatGPT

Content Writing Comparison

Winner for Writing: Claude (slightly)

Final Verdict

Choose ChatGPT if you:

Choose Claude if you:

Choose Gemini if you:

My Recommendation

Where `useMemo` Still Wins (or Ties)