Short answer: declarations vs arrows have no measurable runtime perf difference in modern V8/SpiderMonkey. JIT compiles both equally well. The "performance" question is really about reference identity in React components.

What people actually mean

function Parent() {
  return <Child onClick={() => doStuff()} />;   // new arrow every render
}

() => doStuff() is a new function reference every time Parent re-renders. If Child is wrapped in React.memo, the shallow compare sees a "new prop" and re-renders Child unnecessarily.

This isn't about arrow-vs-declaration; it's about creating a new closure on every render. The same problem happens with a function declaration inside the component:

function Parent() {
  function handleClick() { doStuff(); }      // also new on each render
  return <Child onClick={handleClick} />;
}

Fixes (in order of preference)

1. Hoist if you don't need closure over render values:

function handleClick() { doStuff(); }
function Parent() {
  return <Child onClick={handleClick} />;     // stable reference
}

2. useCallback when you do need closure:

function Parent({ id }) {
  const handleClick = useCallback(() => doStuffWith(id), [id]);
  return <Child onClick={handleClick} />;
}

3. Move the handler into the child so the parent doesn't pass anything:

function Child() {
  return <button onClick={() => doStuff()}>X</button>;
}

When the difference actually matters

useCallback / hoisting only matters if:

• The child is wrapped in React.memo or is a pure component.
• The child is expensive to render.
• The function is in a dep array (useEffect, useMemo) and causes effects to over-fire.

If the child re-renders cheaply anyway, useCallback is overhead with no payoff.

The misconception

"Arrow functions are slow" or "declarations are faster" — both false in modern engines. The microbenchmarks that suggested otherwise were from old JIT versions and were noise even then.

What's true:

• Class methods bound via arrow class properties keep this correct without .bind. That's an ergonomic win, not a perf one.
• Arrow functions are slightly smaller in source (potentially affects gzipped bundle by a few bytes).
• Some old transpilers polyfill arrows; with modern target settings, they compile to native arrows with no overhead.

Where you might see a real difference

• this binding: arrows capture lexical this; declarations don't. In old class-based React, methods had to be bound (this.x = this.x.bind(this)) — arrow class properties avoided that.
• Hot loops: creating millions of small closures in a tight loop has GC cost. Hoist or reuse the function. This is real but rare in app code.
• Hidden classes / inline caches: passing the same function reference allows V8's IC to optimize the call site. Repeatedly passing fresh references prevents that optimization. Usually invisible in app perf.

Mental model

The "use declarations for perf" advice is folklore from a decade ago. Today, pick the form that reads best. In React, focus on reference stability (hoist or useCallback) when the receiving component is memoized. Don't refactor for the syntax itself.

React 19 compiler

The upcoming React Compiler automatically memoizes values and callbacks, removing most useCallback boilerplate. With it, the inline-arrow concern largely goes away. Until then, the manual rule still applies for memoized children.