Framework Reactivity: React, Vue, Svelte, and Solid

Medium•

Most content teaches what APIs do. Senior-level engineering focuses on what work the runtime performs and why. Use this page to reason from mechanics, not framework slogans.

Quick Navigation: Engineering Mental Model (Use This Everywhere) • React Reactivity (Official Model) • Vue Reactivity (Proxy + Effects) • Svelte and Solid (Two Fast Paths) • Reactivity vs Change Detection + Scheduling • What Interviewers Actually Test

Quick Decision Guide

Reactivity = dependency tracking + scheduling + minimal DOM updates.

React: Re-render components, diff trees, then commit DOM changes. Vue: Track property dependencies and trigger only subscribed effects. Svelte: Shift dependency work to compile time. Solid: Update exact signal dependents with fine-grained precision.

Interview signal: Framework syntax is secondary; performance reasoning is primary.

Engineering Mental Model (Use This Everywhere)

🔥 Insight

Good engineers separate framework syntax from reactivity mechanics.

🧠 Mental Model

All frameworks solve the same 3-part loop:

1. Track dependencies

2. Schedule updates

3. Commit minimal DOM changes

How It Works

State change
   -> framework scheduler
   -> DOM mutation
   -> Style
   -> Layout
   -> Paint
   -> Composite

Common Mistakes

•Treating reactivity as magic instead of an execution pipeline

•Ignoring browser costs (layout/paint) and blaming framework only

•Over-sharing state and expanding update surfaces

🎯 Interview Takeaway

If you can explain where work happens and why, you can compare any frontend framework convincingly.

React Reactivity (Official Model)

🔥 Insight

React does not track what changed ahead of time. It re-runs components and figures it out afterward.

🧠 Mental Model

React UI is a function of state:

UI = f(state)

How It Works

setState
   -> schedule update
   -> render phase (pure compute)
   -> reconciliation (tree diff)
   -> commit phase (DOM mutations)

function Counter() {
  const [count, setCount] = useState(0)
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>
}

Trade-offs

•Pros: predictable model, mature ecosystem, excellent tooling

•Cons: coarse update granularity means optimization discipline is required

Common Mistakes

•Assuming re-render equals expensive DOM mutation

•Using unstable list keys and causing remounts

•Overusing global state so small updates fan out widely

🎯 Interview Takeaway

Re-renders are not automatically bad; unnecessary work is bad. Explain identity (keys), boundaries, and batching.

Vue Reactivity (Proxy + Effects)

🔥 Insight

Vue tracks dependencies automatically, but if you lose reactive references, you lose reactivity.

🧠 Mental Model

Reads are tracked, writes trigger only dependent effects/computations.

How It Works

const state = reactive({ count: 0 })

watchEffect(() => {
  console.log(state.count)
})

const doubled = computed(() => state.count * 2)

Edge Case

const { count } = state // breaks reactive linkage

Use toRefs(state) or toRef when destructuring.

Trade-offs

•Pros: granular updates with strong DX

•Cons: subtle caveats around refs/reactive identity and destructuring

🎯 Interview Takeaway

Strong Vue answers mention both the power (fine-grained updates) and the caveat (reference integrity).

Svelte and Solid (Two Fast Paths)

🔥 Insight

Svelte shifts reactivity to build time; Solid keeps it explicit at runtime with signal graphs.

Svelte Mental Model

Assignments mark invalidation, compiler emits targeted updates.

<script>
  let count = 0
  $: doubled = count * 2
</script>

assignment
   -> compiler-emitted invalidation
   -> targeted DOM patch

Solid Mental Model

Signals create explicit dependency edges.

const [count, setCount] = createSignal(0)

createEffect(() => {
  console.log(count())
})

setSignal
   -> notify dependents
   -> update exact subscribed nodes

Trade-offs

•Svelte: very low runtime overhead, compiler-centric model

•Solid: highly precise updates, different mental model from component re-render systems

🎯 Interview Takeaway

Different mechanisms, same objective: minimize unnecessary work while preserving correctness.

Reactivity vs Change Detection + Scheduling

🔥 Insight

A fast rendering model can still feel slow if scheduling and state boundaries are poor.

Reactivity vs Broad Scanning

Older dirty-checking models repeatedly scan broad state surfaces. Modern reactive systems track dependencies and target updates.

Scheduling (Senior-Level Signal)

User input
   -> JS task
   -> framework batching/prioritization
   -> DOM commit
   -> browser frame pipeline

•React: prioritized/concurrent scheduling options

•Vue: async queue + effect batching

•Browser: task and microtask ordering affects responsiveness

🎯 Interview Takeaway

Show that you understand both update granularity and scheduling strategy. That is senior-level reasoning.

What Interviewers Actually Test

🚀 Interview Signals

Interviewers are usually testing whether you can reason about:

•Why React re-renders and when that matters

•Why keys affect identity and state preservation

•When Vue updates and when it does not

•Why fine-grained systems reduce work

•Why architecture choices dominate benchmark headlines

🧠 Senior-Level Insight

Most performance issues come from state placement and rendering boundaries, not framework choice alone.

Practical Checklist

•Co-locate state near consumers

•Keep list identity stable with good keys

•Memoize expensive derived values

•Avoid unnecessary effects/subscriptions

•Virtualize large lists

•Prevent layout thrashing

🎯 Interview Takeaway

Answer with mechanics, trade-offs, and constraints, not framework marketing. That is what stands out.

Key Takeaways

1Teach thinking, not memorization: dependency tracking, scheduling, and commit cost are the core.

2Re-renders are not the enemy; unnecessary work is.

3React, Vue, Svelte, and Solid differ in where tracking happens and how updates are scoped.

4State placement and rendering boundaries often matter more than framework selection.

5Interview-grade answers connect internals to trade-offs and user-perceived performance.