React Fundamentals

React is a JavaScript library for building user interfaces out of components. You describe what the screen should look like for the current data, and React works out which DOM changes are needed to get there. When the data changes, you describe the screen again; React compares the new description with the old one and applies only the difference.

The problem it solves is keeping the screen in sync with the data. In plain DOM code every change is a set of manual instructions — "find this span, change its text, enable that button" — and every place that changes the data has to remember every place on the screen that shows it. With a few dozen interacting pieces of state, those instructions become the main source of bugs. React swaps imperative code ("how to change the page") for declarative code ("what the page is for this data").

A good mental model is a spreadsheet. You don't tell a spreadsheet "when A1 changes, go and rewrite C1". You write the formula C1 = A1 * B1 once, and the spreadsheet keeps it true. A React component is that formula: UI = f(state). You change the inputs; React recomputes the output and patches the page.

export function mountCounter(container) {
  let count = 0;
  const label = document.createElement("span");
  const button = document.createElement("button");
  label.textContent = `Count: ${count}`;
  button.textContent = "Add one";
  button.addEventListener("click", () => {
    count++;
    label.textContent = `Count: ${count}`; // you must remember to update the DOM yourself
  });
  container.append(label, button);
}

The same counter in React:

import { useState } from "react";

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

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

From my notes, the key features of React, with the wording tightened:

• JSX — a syntax extension that lets you write the UI description as HTML-like markup inside JavaScript. It compiles to plain function calls (see JSX).
• Virtual DOM — React's in-memory tree of plain objects describing the UI. My notes call it "a lightweight copy of the real DOM"; more precisely it's a description of what the DOM should be, not a copy of it (see The Virtual DOM and reconciliation).
• Components — reusable functions that take inputs (props) and return UI.
• One-way data binding — data flows down from parents to children through props; children ask for changes through callbacks (see One-way data flow).
• Hooks — functions such as useState and useEffect that give function components state, side effects and other React features.

Where React sits in practice:

• It's a library, not a framework. React itself only renders components and manages their state. Routing, data fetching, forms and styling come from other libraries (React Router, TanStack Query, React Hook Form…), or from a framework built on React such as Next.js or React Router's framework mode, which also adds server rendering.
• It's not only for the web. The component model is shared; the renderer changes. react-dom renders to the browser DOM, React Native renders to iOS/Android views.
• When it's overkill: a mostly static page with a little interactivity doesn't need a client-side React app; plain HTML, or a framework that renders React on the server and ships little JavaScript, serves it better.

"Why React and not Angular?" and "Have you used Vue?" come up in almost every front-end interview. The useful answer isn't which one is better. It's what each one ships, how you write the UI, and how a change in data reaches the screen. React, Vue and Angular all build UIs from components that update when their state changes; they differ in how much comes in the box and in the mechanism behind "update". React Native isn't a rival at all: it's React itself, drawing native mobile views instead of DOM elements.

A mental model: Angular is a fully fitted kitchen: oven, fridge, knives and a manual for how to cook, all from one maker and upgraded together. React is an excellent stove: you pick the fridge and knives yourself, or buy a fitted kitchen built around the stove (Next.js). Vue sits in between: a stove plus an optional set of matching appliances from the same maker (Vue Router, Pinia). React Native is the same chef in a different kitchen: the recipes (components, props, state, hooks) are the same, but the ingredients are View and Text instead of div and span.

Library vs framework

React the package does two things: it lets you describe UI as components, and it keeps the screen in step with their state (react-dom does the DOM part). Everything else is a separate choice: routing (React Router, TanStack Router), server data (TanStack Query), forms (React Hook Form), global state (Redux Toolkit, Zustand), styling, and the build tool. For a new app, react.dev recommends starting from a framework built on React, such as Next.js or React Router's framework mode, which makes those choices for you and adds server rendering (see What React is and why it exists).

Angular is a framework: one @angular/* release train, generated and upgraded by the Angular CLI (ng new, ng update). Built in, from the same team:

• Router (@angular/router) with guards, resolvers and lazy-loaded routes.
• Forms: template-driven (ngModel) and reactive forms (FormGroup, FormControl), plus the newer signal-based forms.
• HTTP: HttpClient with interceptors.
• Dependency injection: services are created and handed to components by the framework (inject(UserService)), which is also how you swap them for fakes in tests.
• Reactivity: RxJS observables throughout the older APIs, and signals (signal, computed, effect) since Angular 16; zoneless change detection is the default from Angular 21.
• The CLI's build, dev server, test runner setup and i18n tooling.

Vue is "progressive": the core is a view layer like React's, but the router (Vue Router) and the state library (Pinia) are official, maintained by the core team, and offered by the create-vue scaffold. Nuxt is Vue's equivalent of Next.js.

The trade-off: Angular's batteries-included approach makes every Angular app look alike, so you can move between teams, and upgrades are coordinated. React's approach lets each team pick the best tool for each job, but every team assembles, documents and upgrades its own stack, and two React codebases can look very different.

The same component three ways

A button that counts clicks and a text input that greets you. In React:

import { useState } from "react";

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

  return (
    <>
      <button onClick={() => setCount(count + 1)}>Clicked {count} times</button>
      <input value={name} onChange={(e) => setName(e.target.value)} />
      <p>Hello, {name}</p>
    </>
  );
}

// after two clicks and typing "Rohit":
// <button>Clicked 2 times</button><input value="Rohit"><p>Hello, Rohit</p>

In Vue, as a single-file component (.vue): the script, the template and optionally the styles live in one file.

<script setup>
import { ref } from "vue";

const count = ref(0);
const name = ref("");
</script>

<template>
  <button @click="count++">Clicked {{ count }} times</button>
  <input v-model="name" />
  <p>Hello, {{ name }}</p>
</template>

In Angular 22, as a standalone component with signals:

import { Component, signal } from "@angular/core";
import { FormsModule } from "@angular/forms";

@Component({
  selector: "app-counter",
  imports: [FormsModule],
  template: `
    <button (click)="count.set(count() + 1)">Clicked {{ count() }} times</button>
    <input [(ngModel)]="name" />
    <p>Hello, {{ name() }}</p>
  `,
})
export class Counter {
  count = signal(0);
  name = signal("");
}

JSX vs templates

JSX is JavaScript: a list is items.map(…), a condition is && or a ternary, and you can pull any piece out into a variable or a function. TypeScript checks it like any other code. Templates are HTML with a small extra language: Vue's v-if and v-for, Angular's @if and @for blocks (Angular 17+; older code uses *ngIf and *ngFor). Templates can do less, but because they're more constrained, the compiler can analyse them: Vue marks the parts that can never change and skips them when diffing, and Angular turns templates into direct DOM-update instructions. Vue also supports JSX and render functions, and Angular's strict template type checking catches template mistakes at build time, so in practice the choice is a matter of style more than capability.

How a change reaches the screen

This is the difference that matters most for performance work:

• React re-renders and reconciles. A state update re-runs that component and, by default, every component below it, then compares the new element tree with the previous one and commits only the DOM changes (see The Virtual DOM and reconciliation). React doesn't know which values a component used; it asks again "what should this look like now?". You skip work with React.memo or let the React Compiler memoize for you.
• Vue tracks dependencies. ref and reactive are proxies: during a render Vue records which reactive values each component read. Changing one re-renders only the components that read it. A child whose props didn't change isn't re-rendered. Each component still diffs a virtual DOM inside itself; Vue 3.6 (a release candidate at the time of writing) adds an opt-in Vapor mode that compiles templates without one.
• Angular checks bindings, and signals narrow the check. There's no virtual DOM: the compiled template updates its bindings in place. Classic Angular used zone.js to notice "something async happened" and then checked the component tree top-down (with OnPush to skip subtrees). With signals and zoneless change detection, a signal change schedules a refresh only for the views that read it.

Mental model: React re-asks every component in the subtree and diffs the answers; Vue and Angular signals keep a list of who used each value and notify only them. Neither model is "faster" in general. Benchmarks depend on the app, and all three are fast enough for nearly everything. The practical difference is how much you think about it: in React you sometimes memoize, in Vue you rarely need to, in Angular you use OnPush or signals.

import { useState } from "react";

export const renders = { parent: 0, shows: 0, other: 0 };

function ShowsCount({ count }) {
  renders.shows++;
  return <p>Count: {count}</p>;
}

function Other() {
  renders.other++;
  return <p>I don't use count</p>;
}

export function Parent() {
  const [count, setCount] = useState(0);
  renders.parent++;
  return (
    <>
      <button onClick={() => setCount(count + 1)}>Add</button>
      <ShowsCount count={count} />
      <Other />
    </>
  );
}

// after 3 clicks, React: {"parent":4,"shows":4,"other":4}
// the same tree in Vue 3.5:  {"parent":4,"shows":4,"other":1}

State management

The ideas carry over: Pinia stores and NgRx feature stores are the same "keep shared state outside the components and change it through named operations" idea as Redux and Zustand (see Choosing a state management approach).

React Native: same React, different renderer

React Native uses the same react package: components, props, state, hooks, context, Redux and TanStack Query all work as on the web. What changes is the renderer and the building blocks. Instead of react-dom creating DOM nodes, React Native's renderer creates real platform views: a UIView on iOS, an Android View. There's no HTML and no browser.

import { useState } from "react";
import { View, Text, Pressable, TextInput, StyleSheet } from "react-native";

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

  return (
    <View style={styles.box}>
      <Pressable onPress={() => setCount(count + 1)}>
        <Text>Clicked {count} times</Text>
      </Pressable>
      <TextInput value={name} onChangeText={setName} style={styles.input} />
      <Text>Hello, {name}</Text>
    </View>
  );
}

const styles = StyleSheet.create({
  box: { padding: 16, gap: 8 },
  input: { borderWidth: 1, borderColor: "#999", padding: 8 },
});

The other differences you'll be asked about:

• No DOM or browser APIs: no document, no window.localStorage (use AsyncStorage or MMKV), no CSS files or className.
• Navigation is a library: React Navigation (stack, tab and drawer navigators that behave like native screens) or Expo Router (file-based, built on React Navigation). React Router's web model of URLs doesn't fit mobile screen stacks.
• Tooling: the React Native docs recommend starting with Expo, a framework for React Native much as Next.js is for the web. Code runs on the Hermes JavaScript engine, and the "New Architecture" (the Fabric renderer, with JSI replacing the old asynchronous bridge) is the default since React Native 0.76.
• Code sharing has limits: hooks, stores, API clients, validation schemas and types are plain JavaScript and share well across web and mobile, often in a monorepo package. UI components don't, because <div className> and <View style> are different worlds. You can share UI by writing it with React Native primitives and rendering it on the web with react-native-web (how Expo's web support works), or keep per-platform files (Button.web.jsx, Button.native.jsx, Button.ios.jsx) that the bundler picks automatically. The realistic plan is "share the logic, write the screens per platform".

At a glance

JSX is a syntax extension for JavaScript that looks like HTML and describes what a component should render. Browsers can't run it; a compiler (Babel, esbuild, Oxc, SWC, TypeScript) turns every tag into a function call before the code ships. So JSX is not a template language with its own rules — it's JavaScript with a different way to write one kind of function call, and anything you can do with a JavaScript value you can do with JSX.

The mental model: a JSX tag is an expression that produces an object, like [1, 2] produces an array. That's why you can store it in a variable, return it, pass it as a prop or put it in an array. And curly braces { } are the way back from markup into JavaScript: anything inside them is a JavaScript expression whose value goes into the output.

export function ProfileCard({ user }) {
  const initials = user.name
    .split(" ")
    .map((part) => part[0])
    .join("");

  return (
    <article className="card" style={{ borderColor: user.online ? "green" : "grey", padding: 12 }}>
      {/* a comment inside JSX goes in braces */}
      <h2>{user.name.toUpperCase()}</h2>
      <span title="initials">{initials}</span>
      <label htmlFor="bio">Bio</label>
      <textarea id="bio" defaultValue={user.bio} />
      <p>{user.online ? "Online" : "Offline"}</p>
      <ul>
        {user.skills.map((skill) => (
          <li key={skill}>{skill}</li>
        ))}
      </ul>
    </article>
  );
}

// <ProfileCard user={{ name: "Rohit Varma", online: true, bio: "Android + web", skills: ["React", "Kotlin"] }} />
// renders:
// <article class="card" style="border-color: green; padding: 12px;"><h2>ROHIT VARMA</h2>
// <span title="initials">RV</span><label for="bio">Bio</label><textarea id="bio">Android + web</textarea>
// <p>Online</p><ul><li>React</li><li>Kotlin</li></ul></article>

The rules that trip people up:

• One root. A component returns a single element. To return siblings without a wrapper div, use a fragment <>…</> (see Fragments).
• Close everything: <img />, <br />, <input />.
• camelCase attributes and events: tabIndex, onClick, autoFocus. Exceptions: aria-* and data-* keep their dashes.
• Comments are {/* … */} inside JSX.
• Strings vs expressions: size="48" passes the string "48"; size={48} passes the number.

<div>
  {true}{false}{null}{undefined}{0}{""}{NaN}{[1, 2, 3]}
</div>

Every JSX tag compiles to a function call that creates a React element: a small, plain JavaScript object saying "a div with these props and these children". Before JSX was common, and in any file where you don't use a compiler, you write those calls yourself with React.createElement(type, props, ...children).

Knowing this removes the mystery from JSX. An element is not a DOM node and not a component instance — it's a lightweight description that React reads later. Creating one is cheap; nothing happens on screen until React renders it into a root.

From my notes, this is the "without JSX" version — but it has two bugs, which I've corrected below:

// from my notes — doesn't work in React 19
const text = React.createElement('p', {}, 'This is a text');
const container = React.createElement('div', '{}', text); // ❌ props is the *string* '{}'
ReactDOM.render(container, rootElement);                  // ❌ removed in React 19

The second argument must be a props object or null, not the string '{}'. In React 19.3 the development build actually throws on it: TypeError: Cannot use 'in' operator to search for '__self' in {} (React checks the props object for special dev-only keys, and the in operator only works on objects). And ReactDOM.render was removed in React 19 (see Rendering an app: createRoot vs ReactDOM.render). The corrected version:

import { createElement } from "react";

const text = createElement("p", null, "This is a text");
const container = createElement("div", { className: "box", id: "main" }, text);

console.log(container);
// {
//   '$$typeof': Symbol(react.transitional.element),
//   type: 'div',
//   key: null,
//   props: {
//     className: 'box',
//     id: 'main',
//     children: { '$$typeof': Symbol(react.transitional.element), type: 'p', key: null, props: [Object], … }
//   },
//   _owner: null,
//   _store: {}
// }
console.log(container.props.children === text); // true

// To show it: createRoot(rootElement).render(container);
// → <div class="box" id="main"><p>This is a text</p></div>

Here's what a compiler actually emits for a small component. I compiled this with Oxc (the compiler Vite 8 uses) in both modes:

export function Card({ user }) {
  return (
    <div className="card" onClick={() => select(user.id)}>
      <h1>Hello, {user.name}</h1>
      <Avatar user={user} size={48} />
    </div>
  );
}

// Automatic runtime — React 17+ (the default everywhere today)
import { jsxs as _jsxs, jsx as _jsx } from "react/jsx-runtime";
export function Card({ user }) {
	return /* @__PURE__ */ _jsxs("div", {
		className: "card",
		onClick: () => select(user.id),
		children: [/* @__PURE__ */ _jsxs("h1", { children: ["Hello, ", user.name] }), /* @__PURE__ */ _jsx(Avatar, {
			user,
			size: 48
		})]
	});
}

// Classic runtime — how JSX compiled before React 17
export function Card({ user }) {
	return /* @__PURE__ */ React.createElement("div", {
		className: "card",
		onClick: () => select(user.id)
	}, /* @__PURE__ */ React.createElement("h1", null, "Hello, ", user.name), /* @__PURE__ */ React.createElement(Avatar, {
		user,
		size: 48
	}));
}

const el = <input key="a" ref={ref} placeholder="x" />;
el.key;                // "a"
Object.keys(el.props); // ["ref", "placeholder"] — no "key"
el.ref;                // still returns ref, but logs:
// "Accessing element.ref was removed in React 19. ref is now a regular prop.
//  It will be removed from the JSX Element type in a future release."

The Virtual DOM is the tree of React elements your components return: plain objects that describe what the DOM should look like. Building and comparing these objects is cheap; touching the real DOM (creating nodes, changing attributes, triggering layout) is comparatively expensive. So instead of rebuilding the page on every change, React keeps the previous tree, builds a new one, and reconciles them: works out the smallest set of DOM operations that turns the old result into the new one.

The flow from my notes, with the details filled in:

1. Initial render — React calls your components, gets the first element tree, and creates the matching DOM nodes.
2. State change — something calls a state setter (a click, a timer, a response arriving).
3. New Virtual DOM — React re-renders the component whose state changed and its descendants (not the whole app), producing a new element tree for that part.
4. Diffing — React compares the new tree with the previous one, node by node.
5. DOM update (commit) — only the differences are applied to the real DOM.

A mental model: it's like "track changes" on a document. React keeps the last version, you hand it a complete new version, and it applies only the edits.

export function Greeting({ name, time }) {
  return (
    <div className="greeting">
      <h1>Hello, {name}</h1>
      <p>It is {time}</p>
    </div>
  );
}

// In the test, a MutationObserver records every change React makes to the DOM:
// rerender(<Greeting name="Rohit" time="10:00" />)  → mutations: []
// rerender(<Greeting name="Rohit" time="10:01" />)  → mutations: ["characterData: \"10:01\""]
// The <h1> node before and after is the same object.

To make comparing two trees fast, React uses two assumptions (a full tree diff would be O(n³); these make it O(n)):

• Different type → different tree. If an element changes type (div → section, or ProfileA → ProfileB), React destroys the old subtree — DOM nodes and component state — and builds the new one from scratch.
• Same type → update in place. React keeps the DOM node or component instance and updates only the changed props.
• Lists are matched by key, so reordering items moves them instead of rewriting each one (see Rendering lists and keys).

The first two rules decide whether state survives:

export function Wrapper({ asSection, highlighted }) {
  if (asSection) {
    return (
      <section>
        <input aria-label="note" />
      </section>
    );
  }
  return (
    <div className={highlighted ? "highlight" : ""}>
      <input aria-label="note" />
    </div>
  );
}

// type "hello" into the input
// <Wrapper highlighted />            → same <input> node, value still "hello"
// <Wrapper asSection highlighted />  → a brand-new <input>, value ""

In React, data flows in one direction: down the tree, from parent to child, through props. A child can read its props but can't change them. If a child needs the data to change, it calls a function the parent passed down, and the parent updates its own state. Then the new value flows down again on the next render.

From my notes, how it works:

1. The parent holds the state — the data that needs to be shared.
2. It passes that state down to children via props.
3. The child uses the props to display the data but can't change them directly.
4. To change the data, the child calls a function passed down from the parent (usually an event handler). That updates the parent's state, which re-renders the parent and its children with the new data.

A mental model: the parent is the single owner of a document, and children get read-only copies plus a "request a change" button. Because only the owner edits, there's exactly one place to look when the data is wrong.

import { useState } from "react";

export function Cart() {
  const [quantity, setQuantity] = useState(1); // the single source of truth

  return (
    <div>
      <QuantityPicker value={quantity} onChange={setQuantity} />
      <Summary quantity={quantity} price={250} />
    </div>
  );
}

function QuantityPicker({ value, onChange }) {
  return (
    <div>
      <button onClick={() => onChange(value - 1)} disabled={value === 1}>−</button>
      <span>{value}</span>
      <button onClick={() => onChange(value + 1)}>+</button>
    </div>
  );
}

function Summary({ quantity, price }) {
  return <p>Total: ₹{quantity * price}</p>;
}

Props really are read-only. In development React freezes the props object, so mutating it throws:

function Title(props) {
  props.text = props.text.toUpperCase(); // ❌ TypeError: Cannot assign to read only property 'text' of object '#<Object>'
  return <h1>{props.text}</h1>;
}

Compute a new value instead: const text = props.text.toUpperCase();. (The production build skips the freeze for speed, so the mutation would silently "work" there — another reason to never rely on it.)

Why it matters in real code:

• Debugging: when the summary shows a wrong total, the bug is in Cart or in what it passes down — you never hunt for some distant component that quietly edited the data.
• The cost is "prop drilling": passing a value through several layers that don't use it just to reach a deep child. Composition (passing components as children) and context solve that (see children and composition over inheritance and The Context API).

A React app starts with one call that connects React to a DOM node. You pick an element from your index.html (conventionally <div id="root">), create a root on it, and render your top component into it. From then on React owns everything inside that node. Since React 18 that's createRoot; before that it was ReactDOM.render, which my notes still use (in the Redux example) and which no longer exists in React 19.

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import App from "./App.jsx";

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

The root object has a small API, and calling render again on the same root updates the app instead of starting over:

const root = createRoot(container);
root.render(<Clicker label="Likes" />);   // click twice → "Likes: 2"
root.render(<Clicker label="Hearts" />);  // → "Hearts: 2" — same component, state kept, same <button> node
root.unmount();                           // container is empty again; effects cleaned up

Old and new, side by side:

What changed across versions:

• React 18 deprecated ReactDOM.render. It still worked but logged (wording from the React 18 upgrade guide; I couldn't run React 18 here) "ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it's running React 17." That "behave as if it's React 17" part matters: under the legacy API you got none of React 18's concurrent features and none of its automatic batching (see State updates are batched).
• React 19 removed render, hydrate, unmountComponentAtNode and findDOMNode from react-dom. In React 19.3 all four are undefined, so old code fails with TypeError: ReactDOM.render is not a function. The fix is the table above; React also ships a codemod (npx codemod@latest react/19/replace-reactdom-render).

<StrictMode> is a component that turns on extra checks in development for everything inside it. It renders nothing visible and does nothing in production builds. Its job is to make certain kinds of bugs — impure components, effects without cleanup, use of deprecated APIs — show up immediately instead of months later in production.

It does that by deliberately doing things twice. React's rules say rendering must be pure (same props and state → same result, no side effects) and effects must clean up after themselves. If your code follows the rules, running it twice is harmless. If it doesn't, running it twice produces a visible symptom: a doubled log, a doubled request, a counter that jumps by two. A mental model: StrictMode is a crash-test dummy run — React rehearses mount, unmount and remount so the weak spots show before real users hit them.

import { useEffect, useMemo, useState } from "react";

export const log = [];

export function Probe() {
  log.push("render");
  const [items] = useState(() => {
    log.push("useState initializer");
    return ["a", "b"];
  });
  const total = useMemo(() => {
    log.push("useMemo");
    return items.length;
  }, [items]);

  useEffect(() => {
    log.push("effect setup");
    return () => log.push("effect cleanup");
  }, []);

  return <p>{total} items</p>;
}

// render(<Probe />)
// ["render", "useState initializer", "useMemo", "effect setup"]
//
// render(<StrictMode><Probe /></StrictMode>)
// ["render", "useState initializer", "useState initializer", "useMemo", "useMemo",
//  "render", "effect setup", "effect cleanup", "effect setup"]

What StrictMode checks in React 19.3:

• Double rendering of components, plus initializer functions passed to useState, useReducer and useMemo.
• Double effects: every effect is set up, cleaned up and set up again on mount (added in React 18). React 19.3 does this during hydration of server-rendered HTML too, not just for client-rendered roots.
• Double ref callbacks (React 19): a callback ref is attached, detached and re-attached on mount — the test logs ["attach INPUT", "detach", "attach INPUT"].
• Warnings for deprecated APIs still around in class components, such as UNSAFE_componentWillMount.

Where to use it: wrap the whole app in main.jsx, as every Vite and Next.js template does. You can also wrap just part of a tree when adopting it gradually in an older codebase.

My notes have this heading ("Bundling and VITE vs create-react-app") but the content under it was a screenshot that didn't come through, so everything here is written fresh.

React code can't go to the browser as-is: JSX must be compiled, hundreds of imports must be resolved and bundled, and the result minified. A build tool does all that and also runs a development server with instant reload. For years the default was Create React App (CRA), a zero-config wrapper around webpack and Babel. Today it's Vite — CRA was officially deprecated on 14 February 2025, and the React docs now point to a framework (Next.js, React Router, Expo) or a build tool (Vite, Parcel, Rsbuild).

The mental model for why Vite won: CRA's webpack dev server bundled your entire app before showing anything, and re-bundled on every change, so startup grew with app size. Vite's dev server doesn't bundle your code at all in development — the browser asks for one module at a time over native ES modules, and Vite compiles just that file on request. Startup is near-instant whatever the app size.

# Vite (current)
npm create vite@latest my-app -- --template react      # or react-ts for TypeScript
cd my-app && npm install
npm run dev        # dev server on http://localhost:5173
npm run build      # production bundle in dist/

# Create React App (deprecated, 2016–2025)
npx create-react-app my-app
npm start          # dev server on http://localhost:3000
npm run build      # production bundle in build/

A Vite project's moving parts are small. index.html sits at the project root and loads the entry module directly:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>My App</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/src/main.jsx"></script>
  </body>
</html>

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

export default defineConfig({
  plugins: [react()],
  server: { port: 5173 },
});

$ npx vite
  VITE v8.3.4  ready in 92 ms

  ➜  Local:   http://localhost:5179/
  ➜  Network: use --host to expose

$ npm run build
vite v8.3.4 building client environment for production...
transforming...
✓ 15 modules transformed.
rendering chunks...
computing gzip size...
dist/index.html                  0.31 kB │ gzip:  0.22 kB
dist/assets/index-Botmzbpb.js  219.70 kB │ gzip: 68.68 kB

✓ built in 69ms

Vite vs CRA in the places you'll notice:

My notes have a heading for this ("PACKAGE.json ( React projects looks like this )") but the example itself was a screenshot that didn't come through; here's a current one written from scratch.

package.json is the manifest of a JavaScript project: its name, the commands you run (npm run dev), and the packages it depends on with acceptable version ranges. npm reads it to install node_modules, and the exact versions it chose are recorded in package-lock.json. In an interview, being able to walk through one shows you know how a React app is actually put together.

{
  "name": "my-app",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview",
    "lint": "eslint .",
    "test": "vitest"
  },
  "dependencies": {
    "react": "^19.3.0",
    "react-dom": "^19.3.0"
  },
  "devDependencies": {
    "@vitejs/plugin-react": "^6.1.2",
    "eslint": "^10.12.0",
    "eslint-plugin-react-hooks": "^7.1.1",
    "vite": "^8.3.4",
    "vitest": "^5.0.3"
  }
}

Interviewers like "what changed in React 18?" and "what's new in 19?", and real codebases are spread across all of these versions. The short story: 16 rebuilt the engine (Fiber) and 16.8 added hooks; 17 added nothing visible but made upgrades possible; 18 made rendering concurrent; 19 added Actions and cleaned out a decade of deprecated APIs; 19.1–19.3 are feature releases on top.

You can check what's installed with import { version } from "react" — in this guide's sandbox it's "19.3.0".