DEV Community: Shrey Saraswat

How Was State Managed in Frontend Development in the Old Days and Its Evolution?

Shrey Saraswat — Sun, 18 Oct 2026 06:47:06 +0000

Open a jQuery codebase from 2012 and try to answer one question: where is the cart count stored?

Maybe it's a JavaScript variable. Maybe it's the text inside <span class="cart-badge">. Maybe it's a data-count attribute on a button. Often, it's all three, and they disagree.

That disagreement is the problem React, Redux, and every state library after them were built to solve. Here is how it looked before them.

The simplest case: a counter

Plain JavaScript:

<h2 id="count">0</h2>
<button id="increment">Increment</button>

<script>
  let count = 0;

  document.getElementById("increment").addEventListener("click", () => {
    count++;
    document.getElementById("count").textContent = count;
  });
</script>

jQuery (2006 onward):

<h2 id="count">0</h2>
<button id="increment">Increment</button>

<script>
  let count = 0;

  $("#increment").on("click", function () {
    count++;
    $("#count").text(count);
  });
</script>

React:

import { useState } from "react";

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

  return (
    <>
      <h2>{count}</h2>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </>
  );
}

jQuery made selecting elements and wiring events much nicer, but look at what it did not change: you still update the variable and you still tell the DOM what to do. Two steps, both manual.

React removes the second step. You change the state, and React works out the DOM changes.

The difference is imperative (do these DOM operations) versus declarative (here is what the UI looks like for this state).

Where it breaks: the cart

A counter has one number and one place that shows it. Real apps don't.

Think of a shop with a navbar badge, a product page, a cart page, and a checkout summary. Adding an item has to update all of them:

let cart = [];

function addToCart(product) {
  cart.push(product);

  $(".cart-badge").text(cart.length);
  $("#cart-total").text(calculateTotal(cart));
  $("#product-" + product.id + " .add-btn").text("In cart");

  if (cart.length === 1) {
    $("#empty-cart-message").hide();
  }
  // ...and the checkout summary? And the "remove" flow?
}

This is an illustrative example, not code from a specific project, but the shape is very familiar. Every feature that touches the cart needs to remember every place the cart is displayed. Miss one and the UI quietly lies to the user.

Two common failure modes:

Forgotten update: You add a "remove" button and forget to refresh the badge.
DOM as the database: Someone reads parseInt($(".cart-badge").text()) because it was convenient. Now the display is the source of truth, and formatting changes like "1 item" can break logic.

flowchart TD
    A[User clicks Add to cart] --> B[Update cart variable]
    B --> C[Update navbar badge]
    B --> D[Update product button]
    B --> E[Update cart total]
    B --> F[Update checkout summary]
    F -. forgot this one .-> G[UI out of sync]

How the tools evolved

The eras overlap, and none of them fully disappeared, but roughly:

Era	Approach	What it helped with	What was still manual
Static HTML (1990s)	Reload the page from the server	Nothing to sync	Any interactivity
Vanilla JS (late 1990s to 2000s)	Variables + DOM APIs	Dynamic pages	Selecting and updating everything
jQuery (2006)	Selectors, events, simpler DOM	Cross-browser pain, less code	State-to-DOM sync
Backbone / AngularJS (about 2010)	Models, views, bindings	Structure, some automatic syncing	Complexity, tricky data flow
React (2013)	Components render from state	DOM updates	Sharing state across components
Redux, MobX, Context, Zustand (2015 onward)	Centralized or specialized stores	Shared state at scale	Choosing the right tool

Backbone gave you models that fire change events, but you still wrote the render logic. AngularJS added two-way binding, which was convenient and also made it harder to see which change caused which update.

Then React's pitch was simple: stop writing the update step. Describe the UI as a function of state.

The same cart, declaratively

function Navbar({ cart }) {
  return <span className="cart-badge">{cart.length}</span>;
}

function CartSummary({ cart }) {
  const total = cart.reduce((sum, item) => sum + item.price, 0);
  return <p>Total: {total}</p>;
}

function App() {
  const [cart, setCart] = useState([]);

  const addToCart = (product) => setCart((prev) => [...prev, product]);

  return (
    <>
      <Navbar cart={cart} />
      <ProductList onAdd={addToCart} />
      <CartSummary cart={cart} />
    </>
  );
}

There is no "update the badge" code. The badge is cart.length, always.

That solves rendering. It doesn't solve sharing: once many distant components need cart, passing props through layers gets awkward. That is the gap Redux filled in 2015 with a single store and explicit updates:

// Redux Toolkit
const cartSlice = createSlice({
  name: "cart",
  initialState: [],
  reducers: {
    added: (state, action) => {
      state.push(action.payload);
    },
  },
});

Whether you need Redux, Context, or Zustand is a separate question. Plenty of apps are fine with plain React state.

What to take from this

Old-style bugs came from duplicated state: a variable, the DOM, and sometimes an attribute, all claiming to be the truth.
React's biggest change was not "components." It was one source of truth that the UI is derived from.
State management libraries solve sharing and coordinating state, not the basic rendering problem.
You can still see this today: any time you read data back out of the DOM in React (ref.current.value everywhere, document.querySelector), you are partly back in the old model.

If an interviewer asks

Before React, state lived in JavaScript variables, globals, browser storage, and often the DOM itself. jQuery simplified DOM updates, and MVC frameworks like Backbone and AngularJS added structure and bindings. As apps grew, keeping data and UI consistent got hard. React introduced a declarative, component-based model where UI is derived from state, and libraries like Redux later made shared state more predictable.

And one distinction worth making: state existed long before React. React changed how state connects to the UI.

Your turn

If you worked in the jQuery or Backbone days, what was the worst "UI out of sync" bug you remember? And if you started with React, have you ever caught yourself reading values back from the DOM instead of state?

An 11-Week React Roadmap: What to Build Before 2026 Ends

Shrey Saraswat — Wed, 14 Oct 2026 07:20:52 +0000

Most "learn React" plans fail for the same reason: they're lists of topics with no dates and nothing to ship.

So here's a different format. The calendar says there are about 11 weeks left in 2026, and that's enough time to go from "I know some React" to "I have a deployed full-stack app, a tested design system, an AI feature and a portfolio with case studies."

This is a plan in 7 stops, each with a date range, a checklist and one thing you must build before moving on.

A note before we start: this is an ambitious, opinionated plan, and it assumes you already know basic React (components, props, state). If you can only spare a few hours a week, don't skip stops. Cut the scope inside each one. There's a section on that near the end.

The plan at a glance

Stop	Dates	Focus	You ship
01	Oct 14 – 20	Foundations	One mini-UI with modern CSS only
02	Oct 21 – Nov 3	React 19 deep dive	A small React 19 form app
03	Nov 4 – 17	Full-stack Next.js	A deployed CRUD app with auth
04	Nov 18 – 24	State, data and forms	A typed data layer with live updates
05	Nov 25 – Dec 8	UI and design system	10 documented, accessible components
06	Dec 9 – 18	Test, speed and CI	E2E tests, a CI pipeline, error monitoring
07	Dec 19 – 31	AI feature and ship	A streaming AI UI and a published portfolio

The order is deliberate. Each stop produces something the next one needs: the form app from stop 2 becomes the starting point for stop 3, the components from stop 5 get tested in stop 6, and so on.

Stop 1 (Oct 14 – 20): Lock the foundations

The checklist

Audit your gaps in JS, TypeScript and modern CSS
TypeScript strict mode: generics, narrowing, utility types
CSS nesting, @layer, container queries
Build one mini-UI with modern CSS only
Set up pnpm, ESLint, Prettier and Husky

One week is short, so don't try to "learn TypeScript." Instead, find your gaps. Open a few components you've written and ask where you used any, where you cast with as, and where you copied a type without understanding it.

TypeScript: the three ideas that pay off in React

Generics show up the moment you write a reusable component or hook:

function useLocalStorage<T>(key: string, initial: T) {
  const [value, setValue] = useState<T>(() => {
    const raw = localStorage.getItem(key);
    return raw ? (JSON.parse(raw) as T) : initial;
  });
  // ...
  return [value, setValue] as const;
}

Narrowing is how you handle API results safely:

type Result =
  | { status: "success"; data: User }
  | { status: "error"; message: string };

function render(result: Result) {
  if (result.status === "error") return result.message; // narrowed here
  return result.data.name;                               // and here
}

Utility types (Pick, Omit, Partial, ReturnType) save you from retyping the same shape:

type UserPreview = Pick<User, "id" | "name" | "avatarUrl">;
type UserDraft = Partial<Omit<User, "id">>;

Turn on "strict": true in tsconfig.json if you haven't. It's uncomfortable for a day and valuable afterward.

Modern CSS you can use today

Native nesting, cascade layers and container queries remove a lot of reasons to reach for a preprocessor or a utility framework for small components:

@layer base, components;

@layer components {
  .card-wrapper {
    container-type: inline-size;
  }

  .card {
    padding: 1rem;
    border-radius: 0.75rem;

    & h3 {
      margin: 0;
    }

    @container (min-width: 480px) {
      display: grid;
      grid-template-columns: 160px 1fr;
      gap: 1rem;
    }
  }
}

The project for this stop is one mini-UI using only modern CSS: a pricing card, a profile card or a dashboard tile. No Tailwind, no component library. The point is to find out what you can do without them.

Tooling

Set up the boring stuff now so it doesn't interrupt you later:

pnpm create vite my-app --template react-ts
cd my-app
pnpm add -D eslint prettier husky lint-staged
pnpm exec husky init

A pre-commit hook that runs lint and format on staged files will catch most embarrassing commits before your teammates (or recruiters) see them.

Done when: strict TS compiles cleanly, your mini-UI works at three container widths, and committing triggers lint and format.

Stop 2 (Oct 21 – Nov 3): React 19 deep dive

The checklist

Actions, useActionState, useOptimistic
The use() hook and Suspense data loading
Enable React Compiler in one project
Refactor an old app: drop memo clutter
Ship a small React 19 form app

This stop gets two weeks because it changes how you write React day to day.

Actions and `useActionState`

Before React 19, a form that submits to an API meant hand-rolling isLoading, error and data state. Now an async function can be the form's action, and React tracks the pending state for you:

import { useActionState } from "react";

type State = { ok: boolean; message: string } | null;

async function subscribe(_prev: State, formData: FormData): Promise<State> {
  const email = String(formData.get("email") ?? "");
  const res = await fetch("/api/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ email }),
  });
  return res.ok
    ? { ok: true, message: "Subscribed!" }
    : { ok: false, message: "Something went wrong" };
}

export function Newsletter() {
  const [state, action, isPending] = useActionState(subscribe, null);

  return (
    <form action={action}>
      <input name="email" type="email" required />
      <button disabled={isPending}>
        {isPending ? "Subscribing..." : "Subscribe"}
      </button>
      {state && <p role="status">{state.message}</p>}
    </form>
  );
}

`useOptimistic`

Optimistic UI means showing the result before the server confirms it. useOptimistic gives you a temporary value that automatically reverts to the real state when the action finishes:

import { useOptimistic } from "react";

function TodoList({ todos, addTodo }: Props) {
  const [optimisticTodos, addOptimistic] = useOptimistic(
    todos,
    (current, newTitle: string) => [
      ...current,
      { id: crypto.randomUUID(), title: newTitle, pending: true },
    ]
  );

  async function formAction(formData: FormData) {
    const title = String(formData.get("title"));
    addOptimistic(title);
    await addTodo(title); // if this throws, the optimistic item disappears
  }

  return (
    <form action={formAction}>
      <input name="title" />
      <ul>
        {optimisticTodos.map((t) => (
          <li key={t.id} style={{ opacity: t.pending ? 0.5 : 1 }}>
            {t.title}
          </li>
        ))}
      </ul>
    </form>
  );
}

`use()` and Suspense

use() reads a promise (or context) during render and suspends until it resolves. The important rule: the promise must be stable across renders. Creating a new fetch() inside the component body creates a new promise every render. Pass it down from a parent, a framework loader, or a cache:

import { use, Suspense } from "react";

function Comments({ commentsPromise }: { commentsPromise: Promise<Comment[]> }) {
  const comments = use(commentsPromise);
  return comments.map((c) => <p key={c.id}>{c.text}</p>);
}

export function Post({ commentsPromise }: Props) {
  return (
    <Suspense fallback={<p>Loading comments...</p>}>
      <Comments commentsPromise={commentsPromise} />
    </Suspense>
  );
}

React Compiler and the memo cleanup

The React Compiler memoizes components and values at build time. If you've sprinkled useMemo, useCallback and React.memo through a codebase "just in case," the compiler makes most of it unnecessary.

With Vite it's a Babel plugin:

pnpm add -D babel-plugin-react-compiler

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

export default defineConfig({
  plugins: [
    react({
      babel: { plugins: ["babel-plugin-react-compiler"] },
    }),
  ],
});

Setup differs by framework and version, so follow the official React Compiler docs for yours.

The refactor exercise from the roadmap is the best part of this stop:

Pick an old project with lots of manual memoization
Profile it with React DevTools before changing anything
Enable the compiler
Remove manual memoization in small batches
Profile again and compare

Remove useMemo/useCallback where it's only there for performance. Keep it where a value's identity genuinely matters (for example a dependency of an effect that shouldn't re-run). And measure. Don't assume.

Done when: you've shipped a small form app using actions and optimistic updates, and you can explain why you kept or removed each manual memo.

Stop 3 (Nov 4 – 17): Full-stack Next.js

The checklist

Server Components and Server Functions
CRUD app: Next.js + Postgres/Prisma
Auth with Auth.js or Clerk, plus middleware
Streaming, caching and revalidation
Deploy on Vercel with preview URLs

This is the biggest conceptual jump in the plan. Give it the time.

Server Components: data fetching without an API layer

A Server Component runs on the server, so it can talk to the database directly. Nothing from it ships to the browser except the rendered output:

// app/posts/page.tsx (Server Component by default)
import { prisma } from "@/lib/prisma";

export default async function PostsPage() {
  const posts = await prisma.post.findMany({
    orderBy: { createdAt: "desc" },
  });

  return (
    <ul>
      {posts.map((p) => (
        <li key={p.id}>{p.title}</li>
      ))}
    </ul>
  );
}

Server Functions for mutations

// app/posts/actions.ts
"use server";

import { revalidatePath } from "next/cache";
import { z } from "zod";
import { prisma } from "@/lib/prisma";
import { auth } from "@/lib/auth";

const Schema = z.object({ title: z.string().min(1).max(120) });

export async function createPost(formData: FormData) {
  const session = await auth();
  if (!session) throw new Error("Unauthorized");

  const parsed = Schema.safeParse({ title: formData.get("title") });
  if (!parsed.success) return { error: "Invalid title" };

  await prisma.post.create({
    data: { title: parsed.data.title, authorId: session.user.id },
  });
  revalidatePath("/posts");
}

Treat every Server Function like a public HTTP endpoint, because that's what it is. It needs its own authentication check and input validation. Hiding a button in the UI is not authorization. This is one of the most common mistakes in this model, and the roadmap's "auth + middleware" item exists partly to drive the point home.

Auth

Both Auth.js and Clerk are reasonable. A rough rule: Auth.js if you want to own the data and the flow, Clerk if you'd rather not build sign-in, sessions and user management yourself. Whichever you pick, use middleware (called proxy in newer Next.js versions, so check your version's docs) for coarse route protection, and still verify the session inside your data access code.

Streaming, caching and revalidation

Three questions to answer for every page:

Can the shell render immediately? Use loading.tsx or <Suspense> so slow data doesn't block the whole page.
How fresh does this data need to be? Per-user data usually shouldn't be cached shared. A blog list can be.
What invalidates it? Tie mutations to revalidatePath or tag-based revalidation.

Caching defaults have changed between Next.js versions, so don't rely on tutorials older than your installed version. Read the current caching docs, then test by actually mutating data and watching what updates.

Deploy early

Push to GitHub, connect to Vercel, and every pull request gets a preview URL. Do this on day one of this stop, not day fourteen. Deploy problems are easier to fix when the app is tiny.

Done when: you have a deployed CRUD app with sign-in, where logged-out users can't mutate data even if they call the Server Function directly.

Stop 4 (Nov 18 – 24): State, data and forms

The checklist

TanStack Query: cache, mutations, prefetch
Zustand or Redux Toolkit for UI state
React Hook Form + Zod validation
Typed API layer: tRPC or OpenAPI
Live updates via SSE / WebSockets

One week, so focus on the mental model: server state and client state are different things.

State type	Examples	Tool
Server state	Lists, profiles, anything from an API	TanStack Query (or your framework's data layer)
Client UI state	Open modal, selected tab, filters	`useState`, then Zustand or Redux Toolkit if shared widely
Form state	Inputs, errors, dirty/touched	React Hook Form
Validation	Shape and rules of data	Zod

TanStack Query: cache and mutations

import { useQuery, useMutation, useQueryClient } from "@tanstack/react-query";

function Todos() {
  const queryClient = useQueryClient();

  const { data, isPending, error } = useQuery({
    queryKey: ["todos"],
    queryFn: () => fetch("/api/todos").then((r) => r.json()),
  });

  const addTodo = useMutation({
    mutationFn: (title: string) =>
      fetch("/api/todos", {
        method: "POST",
        body: JSON.stringify({ title }),
      }),
    onSuccess: () => queryClient.invalidateQueries({ queryKey: ["todos"] }),
  });

  if (isPending) return <p>Loading...</p>;
  if (error) return <p>Something went wrong</p>;
  // render data, call addTodo.mutate(...)
}

Spend time on queryKey design and invalidation. Most TanStack Query bugs are cache-key bugs.

Forms: React Hook Form + Zod

Define the schema once, then use it for both types and validation:

import { useForm } from "react-hook-form";
import { zodResolver } from "@hookform/resolvers/zod";
import { z } from "zod";

const Schema = z.object({
  email: z.string().email("Enter a valid email"),
  age: z.coerce.number().int().min(18, "Must be 18 or older"),
});
type FormValues = z.infer<typeof Schema>;

export function SignupForm() {
  const {
    register,
    handleSubmit,
    formState: { errors, isSubmitting },
  } = useForm<FormValues>({ resolver: zodResolver(Schema) });

  return (
    <form onSubmit={handleSubmit(async (values) => { /* send */ })}>
      <input {...register("email")} />
      {errors.email && <p role="alert">{errors.email.message}</p>}
      <input type="number" {...register("age")} />
      {errors.age && <p role="alert">{errors.age.message}</p>}
      <button disabled={isSubmitting}>Sign up</button>
    </form>
  );
}

Remember that client-side validation is for UX. The server must validate again with the same schema.

Typed API layer

tRPC gives end-to-end type safety with no schema file, but works best when your frontend and backend are both TypeScript and in the same repo or workspace.
OpenAPI with a generated client is a better fit when the backend is a different language or owned by another team.

Pick whichever matches your situation, and try the other briefly so you know the trade-off.

Live updates

For one-way updates (notifications, progress, a live feed), Server-Sent Events are simpler than WebSockets:

useEffect(() => {
  const source = new EventSource("/api/notifications");
  source.onmessage = (e) => {
    const event = JSON.parse(e.data);
    queryClient.setQueryData(["notifications"], (old = []) => [event, ...old]);
  };
  return () => source.close();
}, [queryClient]);

Use WebSockets when you need two-way, low-latency communication such as chat or collaborative editing.

Done when: your app from stop 3 has a typed data layer, a validated form, and at least one feature that updates live without a refresh.

Stop 5 (Nov 25 – Dec 8): UI and design system

The checklist

Tailwind v4 + design tokens
10 components with Radix / shadcn/ui
Document them in Storybook
Pass an axe audit: keyboard, ARIA, contrast
Dark mode, motion and i18n

Design tokens in Tailwind v4

Tailwind v4 moved configuration into CSS. Your tokens live in @theme:

@import "tailwindcss";

@theme {
  --color-brand-500: oklch(0.62 0.19 259);
  --color-surface: oklch(0.99 0 0);
  --radius-card: 0.75rem;
  --font-sans: "Inter", system-ui, sans-serif;
}

Then bg-brand-500 and rounded-card just work. The benefit of tokens is that a rebrand or a dark theme becomes a change in one file.

Ten components, not fifty

Pick ten you'd genuinely reuse: Button, Input, Select, Checkbox, Dialog, Dropdown menu, Tabs, Toast, Card, Skeleton. Build them on Radix primitives or copy them in via shadcn/ui and then actually read and adjust the code. The value of shadcn/ui is that you own the components, so treat them as your code.

Storybook as documentation

For each component, write stories for its meaningful states: default, disabled, loading, error, long text and dark mode. If you can't think of a state to document, you probably don't understand the component's contract yet.

Accessibility audit

Run the audit in this order:

Keyboard only: unplug the mouse. Can you reach and operate everything? Is focus visible? Does a dialog trap and restore focus?
Automated: run axe (the browser extension, @axe-core/playwright, or Storybook's a11y addon). It finds a portion of issues, not all.
Contrast: check text and UI against WCAG AA ratios.
Screen reader spot check: at least try VoiceOver or NVDA on one flow.

Dark mode, motion and i18n

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Respect prefers-color-scheme and prefers-reduced-motion by default, and use a library such as next-intl or react-i18next to pull strings out of components early. Retrofitting i18n into a finished UI is painful.

Done when: you have ten documented components that pass keyboard navigation and an axe scan, in both light and dark themes.

Stop 6 (Dec 9 – 18): Test, speed and CI

The checklist

Vitest + React Testing Library for core flows
Playwright E2E for 3 user journeys
INP under 200ms, LCP under 2.5s
GitHub Actions: lint, test, deploy
Sentry error monitoring

Unit and component tests

Test what the user experiences, not implementation details:

import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import { SignupForm } from "./SignupForm";

test("shows a validation error for an invalid email", async () => {
  const user = userEvent.setup();
  render(<SignupForm />);

  await user.type(screen.getByRole("textbox", { name: /email/i }), "nope");
  await user.click(screen.getByRole("button", { name: /sign up/i }));

  expect(await screen.findByRole("alert")).toHaveTextContent(/valid email/i);
});

Selecting by role and accessible name pushes you toward accessible markup as a side effect.

Three E2E journeys

Don't try to cover everything. Pick the three flows that would hurt most if they broke, for example sign in, create a post, and checkout (or whatever your app's core action is):

import { test, expect } from "@playwright/test";

test("signed-in user can create a post", async ({ page }) => {
  await page.goto("/login");
  await page.getByLabel("Email").fill("test@example.com");
  await page.getByLabel("Password").fill(process.env.E2E_PASSWORD!);
  await page.getByRole("button", { name: "Sign in" }).click();

  await page.getByRole("link", { name: "New post" }).click();
  await page.getByLabel("Title").fill("Hello from Playwright");
  await page.getByRole("button", { name: "Publish" }).click();

  await expect(page.getByText("Hello from Playwright")).toBeVisible();
});

Performance targets

The roadmap's targets match Google's "good" thresholds for Core Web Vitals: LCP at or under 2.5 seconds and INP under 200 milliseconds (at the 75th percentile of real users). A few notes:

Lighthouse gives you lab data. It's useful for debugging but not the same as what your users experience.
INP measures responsiveness across the whole visit, so it's usually hurt by long tasks from heavy JavaScript. Look at the Performance panel for long tasks after interactions.
LCP is most often an image or hero text problem. Check what the LCP element actually is before optimizing anything.

You can capture field data from your own app with the web-vitals library:

import { onINP, onLCP } from "web-vitals";

onINP((metric) => console.log("INP", metric.value));
onLCP((metric) => console.log("LCP", metric.value));

CI with GitHub Actions

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm tsc --noEmit
      - run: pnpm test run

Action and Node versions move over time, so check the current ones when you copy this. Add the Playwright job after the basics work.

Error monitoring

Add Sentry (or an equivalent) and deliberately trigger a test error in production. The first time you see a real stack trace with source maps is when monitoring clicks.

Done when: a pull request that breaks a core flow fails CI, and an error in production shows up in your monitoring tool.

Stop 7 (Dec 19 – 31): AI feature and ship

The checklist

Streaming AI chat UI with Vercel AI SDK
Try tool-calling and MCP in an app
Publish portfolio with 3 case studies
Write on DEV.to and post an X thread
Plan 2027: pick 1 deep-dive track

Build the AI feature with the right expectations

Most of the engineering in an AI feature is UX, not the model call. A server route that streams a response looks roughly like this with the Vercel AI SDK:

// app/api/chat/route.ts
import { streamText, convertToModelMessages, type UIMessage } from "ai";

export async function POST(req: Request) {
  const { messages }: { messages: UIMessage[] } = await req.json();

  const result = streamText({
    model: "YOUR_MODEL_ID", // see the SDK docs for supported models
    messages: convertToModelMessages(messages),
  });

  return result.toUIMessageStreamResponse();
}

The SDK's API has changed between major versions, so follow the docs for the version you install rather than copying older examples.

The frontend questions that actually matter:

What does the user see while the model is thinking?
What happens when a response is wrong, slow or fails halfway?
Can the user stop a response, retry, or edit their message?
Where does it stop being trustworthy, and is that visible to the user?

Treat model output as untrusted input. Don't render it as raw HTML, and don't let it call tools with side effects (sending email, deleting data) without validation and user confirmation.

Tool-calling and MCP

Tool-calling lets the model request that your code run a function with structured arguments, such as "look up this order" or "search these docs." MCP (Model Context Protocol) standardizes how apps expose tools and data to models. For this stop, one small experiment is enough: give your app a read-only tool and watch how the model decides when to use it. Keep write actions behind explicit confirmation.

Ship the portfolio and write about it

This is the step people skip, and it's the one that makes the other six count.

A case study doesn't need to be long. For each of three projects, cover:

The problem: what it does and who it's for
A decision you made: and what you rejected
Something that went wrong: and how you found the cause
What you'd change: being honest builds more trust than being polished

Then write about it on DEV.to, post a short X thread, and link the repo and live demo. Use only results you actually measured. Don't claim a Lighthouse score or a speedup you didn't verify.

Plan 2027

Finish with a decision: pick one deep-dive track for the new year, such as performance, design systems, full-stack architecture, testing, or AI engineering. Breadth got you through this plan. Depth is what makes you recognizable.

Done when: your portfolio is live with three case studies, you've published at least one write-up, and you can say in one sentence what you're going deeper on next.

Common mistakes with a plan like this

Tutorial hopping instead of building. Every stop has a deliverable for a reason. If you haven't shipped something, you haven't finished the stop.
Skipping foundations to get to the exciting stops. Stop 7 on a weak stop 1 gives you a demo that falls apart.
Letting one stop eat the schedule. Stop 3 will tempt you to extend it. Don't. Ship the smaller version.
Copying code without checking versions. React, Next.js, the AI SDK and Tailwind have all shifted APIs in recent versions. Always check the docs for what you've installed.
Never writing it down. Notes become blog posts, and blog posts become the portfolio.

If you can't do 11 full weeks

Keep all seven stops but shrink the scope inside each:

If you have...	Do this
About 5 hours/week	Do one mini-project per stop, skip Storybook and i18n, and extend the schedule into January
About 10 hours/week	Follow the plan, but cut stop 4's live updates and stop 7's MCP experiment
Full-time availability	Follow the plan as written, and add a second project at stops 3 and 5

A plan you finish at 70% beats one you abandon in week three.

Key takeaways

A roadmap is only useful if every stop ends with something shipped.
Learn React 19's model (actions, use(), the compiler) before layering a framework on top.
Treat Server Functions like public endpoints: authenticate and validate inside them.
Separate server state, client state and form state, and use the right tool for each.
Accessibility, tests and CI are part of building the thing, not a final polish step.
AI features are mostly a UX and safety problem. Design the failure states first.

What would you change in this plan? If you've been through some of these stops, which one took longer than expected, and what would you cut or add? And if you're starting it this week, tell me which stop you're most worried about. I'd like to hear how it goes.

The Death of Server-Side Uploads? A Frontend Guide to Direct-to-Cloud Uploads in React

Shrey Saraswat — Mon, 12 Oct 2026 11:45:58 +0000

A 100 MB upload through your API server holds a connection, memory, and a worker for the whole transfer. With a few users uploading at once, your app feels slow even though nothing is wrong with your code.

The common fix is to let the browser send the file straight to cloud storage (S3, Cloudflare R2, and similar). The backend stops carrying the bytes and only decides who may upload what.

This post covers the frontend side of that flow: browser APIs, a React implementation, progress, cancellation, validation, and the mistakes that break most first attempts. The code is illustrative, so test it against your storage provider.

Traditionally, a file travels through your application server:

Browser → Backend API → Cloud Storage

With direct-to-cloud uploads, the browser talks to storage itself:

Browser ──────────────→ Cloud Storage
   │                          │
   └── Backend authorizes ────┘

The backend still controls permissions and verifies the result. It just doesn't proxy the file.

1. The Browser Already Gives You the Tools

You don't need a library to start handling files. These built-in APIs cover most of the upload experience:

API	What it does
`File`	Represents a selected file
`FileList`	Provides access to selected files
`URL.createObjectURL()`	Creates a local URL for previews
`XMLHttpRequest`	Supports upload progress events
`AbortController`	Cancels supported network requests
`FormData`	Packages files for multipart form submissions

A good example is the image preview. Selecting an image and showing it doesn't require uploading anything.

Before: this works, but it creates a new object URL on every render and never releases it.

import { useEffect, useState } from "react";

function ImagePreview() {
  const [file, setFile] = useState(null);

  useEffect(() => {
    if (!file) return;
    const previewUrl = URL.createObjectURL(file);
    return () => URL.revokeObjectURL(previewUrl);
  }, [file]);

  return (
    <div>
      <input
        type="file"
        accept="image/*"
        onChange={(event) => setFile(event.target.files?.[0] ?? null)}
      />

      {file && (
        // New object URL on every render, and the one above is never used
        <img src={URL.createObjectURL(file)} alt="Selected image preview" />
      )}
    </div>
  );
}

After: one URL per file, stored in state and revoked on cleanup.

import { useEffect, useState } from "react";

function ImagePreview() {
  const [file, setFile] = useState(null);
  const [previewUrl, setPreviewUrl] = useState("");

  useEffect(() => {
    if (!file) {
      setPreviewUrl("");
      return;
    }

    const url = URL.createObjectURL(file);
    setPreviewUrl(url);

    return () => URL.revokeObjectURL(url);
  }, [file]);

  return (
    <div>
      <input
        type="file"
        accept="image/*"
        onChange={(event) => setFile(event.target.files?.[0] ?? null)}
      />

      {previewUrl && <img src={previewUrl} alt="Selected image preview" />}
    </div>
  );
}

The preview stays local until the user actually uploads.

2. What Changes With Direct Uploads?

In a conventional setup, the frontend sends the file to an application endpoint, and the server forwards it to storage:

await fetch("/api/upload", {
  method: "POST",
  body: formData,
});

With direct uploads, the flow has four steps:

1. React requests upload authorization
2. Backend returns a signed upload URL
3. React uploads the file directly to storage
4. React reports completion to the backend

The browser is now responsible for the transfer. That reduces load on your application server, especially when many users upload large files. It also means the frontend has to handle failures, progress, and completion properly.

3. Implementing Direct Uploads in React

Start by separating the upload logic from the UI. Assume the backend exposes an endpoint that returns a short-lived signed URL and an asset identifier. The exact response depends on your storage provider.

async function getUploadAuthorization(file) {
  const response = await fetch("/api/uploads/sign", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      filename: file.name,
      contentType: file.type,
      size: file.size,
    }),
  });

  if (!response.ok) {
    throw new Error("Could not authorize upload");
  }

  return response.json(); // { uploadUrl, assetId }
}

This is the simplest version of the upload itself. Section 4 swaps the PUT for XHR so we get progress.

async function uploadFile(file) {
  const { uploadUrl, assetId } = await getUploadAuthorization(file);

  const response = await fetch(uploadUrl, {
    method: "PUT",
    headers: { "Content-Type": file.type },
    body: file,
  });

  if (!response.ok) {
    throw new Error("Upload failed");
  }

  const completion = await fetch(`/api/uploads/${assetId}/complete`, {
    method: "POST",
  });

  if (!completion.ok) {
    throw new Error("Could not finalize upload");
  }

  return completion.json();
}

The HTTP method, headers, and completion flow must match your storage provider's requirements. The backend must verify the uploaded object before trusting it.

Notice what the frontend doesn't need: storage credentials. It receives permission for one particular upload, not access to the storage account.

4. Upload Progress and Cancel

A button that says "Uploading..." doesn't tell users whether the upload is moving, stalled, or almost done.

fetch() doesn't currently expose a standard upload-progress event. For progress reporting, XMLHttpRequest is the practical option. This version also accepts an AbortSignal so the caller can cancel:

function uploadWithProgress(uploadUrl, file, onProgress, signal) {
  return new Promise((resolve, reject) => {
    const xhr = new XMLHttpRequest();

    xhr.open("PUT", uploadUrl);
    xhr.setRequestHeader("Content-Type", file.type);

    xhr.upload.onprogress = (event) => {
      if (!event.lengthComputable) return;
      onProgress(Math.round((event.loaded / event.total) * 100));
    };

    xhr.onload = () =>
      xhr.status >= 200 && xhr.status < 300
        ? resolve()
        : reject(new Error(`Upload failed: ${xhr.status}`));

    xhr.onerror = () => reject(new Error("Network error during upload"));
    xhr.onabort = () =>
      reject(new DOMException("Upload cancelled", "AbortError"));

    if (signal) {
      if (signal.aborted) return xhr.onabort();
      signal.addEventListener("abort", () => xhr.abort(), { once: true });
    }

    xhr.send(file);
  });
}

And in a component:

const [progress, setProgress] = useState(0);
const controllerRef = useRef(null);

async function handleUpload(file, uploadUrl) {
  setProgress(0);
  controllerRef.current = new AbortController();

  try {
    await uploadWithProgress(
      uploadUrl,
      file,
      setProgress,
      controllerRef.current.signal
    );
  } catch (error) {
    if (error.name !== "AbortError") console.error(error);
  }
}

const cancel = () => controllerRef.current?.abort();

One distinction worth remembering: 100% progress means the browser finished sending the bytes. It doesn't mean the storage provider has finished processing the file, or that your application has finalized it.

Cancelling also only stops the browser's request. If the object had already landed in the bucket, it stays there, so you may need a cleanup job for orphaned uploads.

5. Make the Upload UI Resilient

Networks fail, signed URLs expire, users close tabs, and files get rejected. Model those cases deliberately.

The happy path:

idle → selected → authorizing → uploading → finalizing → success

And the failure paths:

uploading ──→ failed ──→ retry
     │
     └──────→ cancelled

A small state shape is enough to start:

const initialUploadState = {
  status: "idle",
  progress: 0,
  error: null,
};

For a production component, I'd cover these:

Disable duplicate submissions while an upload is active
Show progress and a clear cancel action
Keep the selected file after a recoverable failure
Request a new signed URL on every retry, so expired URLs stop being a problem
Avoid updating state after the component unmounts
Announce status changes to screen readers (for example with aria-live="polite")

6. File Validation: What the Frontend Can and Cannot Do

Rejecting obviously invalid files before asking for authorization gives users instant feedback:

function validateFile(file) {
  const maxSize = 5 * 1024 * 1024;
  const allowedTypes = ["image/jpeg", "image/png", "image/webp"];

  if (!allowedTypes.includes(file.type)) {
    return "Please select a JPEG, PNG, or WebP image.";
  }

  if (file.size > maxSize) {
    return "The image must be smaller than 5 MB.";
  }

  return null;
}

But frontend validation is not a security boundary. A user can bypass it or modify the request. The backend and storage policy must enforce the restrictions independently, and file contents may need inspection after upload.

Frontend validation improves usability. Server-side enforcement establishes trust. You need both.

7. Mistakes That Break the First Attempt

CORS on the bucket. The browser sends a preflight request to the storage domain. Without a CORS rule that allows your origin and PUT, the upload fails before it starts. For S3, a minimal rule looks like this (use your real origin):

[
  {
    "AllowedOrigins": ["http://localhost:5173"],
    "AllowedMethods": ["PUT"],
    "AllowedHeaders": ["Content-Type"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3000
  }
]

Content-Type doesn't match what was signed. If the backend signed the URL for image/png and the browser sends something else, S3 typically rejects it with SignatureDoesNotMatch. Send the same type you asked the backend to sign.

Trusting file.type. The browser derives it from the file extension, not the file's contents. Use it for UI feedback, and validate for real on the server or after upload.

Expecting a presigned PUT to enforce size limits. It generally can't. On S3, a presigned POST with policy conditions can, but support differs between providers, so check yours.

Skipping the completion check. The /complete endpoint should verify that the object exists (for example with a HEAD request) before saving metadata. Don't just trust that the client says it finished.

8. Multiple Files and Large Uploads

Once the basic flow works, a few more challenges show up.

Multiple files. Track each file separately, with its own status, progress, and error. A single global progress value falls apart quickly.

Concurrency. Uploading everything at once can saturate the browser's connections and hurt slow networks. A small upload queue gives you control.

Large files. Multipart or resumable uploads help recover from network failures. These usually need coordination with your storage provider's SDK or API.

If you don't want to hand-roll all of this, Uppy or your storage provider's SDK already handle chunking, retries, and queues. Building it once yourself is still a good way to understand what they do.

9. Is Direct-to-Cloud Always Better?

No. Direct uploads shine when an app handles lots of media or large files. A small app with a simple upload endpoint may not need the extra complexity.

Requirement	What to consider
Simple form with small attachments	A conventional backend endpoint may be sufficient
Large images or videos	Direct uploads can reduce backend transfer load
Live progress indicators	Use upload-progress-capable APIs or a suitable SDK
Unreliable networks	Consider retries and resumable uploads
Sensitive documents	Use strict authorization, private storage, and appropriate inspection
Malware scanning or moderation	Scan after upload before exposing the file, or proxy through the server
Many concurrent uploads	Direct uploads plus a controlled client-side queue

Choose the architecture based on your actual requirements, not on what's newer.

Checklist

✓ Bucket CORS allows your origin and PUT
✓ Content-Type sent equals Content-Type signed
✓ Fresh signed URL on every attempt
✓ Progress via XHR, cancel via AbortSignal
✓ Server-side validation, not just validateFile
✓ Completion step verifies the object exists
✓ Plan for orphaned objects after cancelled uploads

Takeaway

Direct uploads don't remove the backend. They change its job from carrying bytes to granting and verifying permission. The frontend takes on the transfer, which means progress, cancel, retry, and error states become your responsibility.

What does your upload flow look like today: a traditional backend endpoint, direct-to-cloud, or a provider SDK? I'd like to hear what made you choose it, especially if you hit problems I haven't covered here.

" What Actually Happens When You Click \"Submit\"? A Request From Browser to Database and Back "

Shrey Saraswat — Thu, 08 Oct 2026 21:27:43 +0000

A login form has two inputs and a button. The code to submit it is about ten lines.

Behind that button there are at least a dozen separate systems, and any of them can be the reason your form "doesn't work." Most of us only debug the first and last ones.

This post follows one login request all the way down and back up. At each layer I'll cover what happens, what can break, and how to look at it yourself.

Here's the form:

<form id="login">
  <input name="email" type="email" required />
  <input name="password" type="password" required />
  <button type="submit">Log in</button>
</form>

The whole trip on one page

sequenceDiagram
    participant B as Browser
    participant D as DNS
    participant E as Edge (CDN / load balancer)
    participant A as App server
    participant DB as Database

    B->>B: click, validation, submit event, fetch()
    B->>D: who is api.example.com?
    D-->>B: IP address
    B->>E: TCP or QUIC handshake, then TLS
    B->>E: POST /api/login
    E->>A: forward request
    A->>DB: SELECT user by email
    DB-->>A: row with password hash
    A->>A: verify hash, create session
    A-->>E: 200 + Set-Cookie
    E-->>B: response
    B->>B: update state, render

One caveat before we start. Steps 3 and 4 often don't happen. If the browser already has an open connection to that host, it reuses it and skips straight to sending the request. I'll show the full cold-start path because it's the most informative, but a warm request is much shorter.

1. The click: from your finger to a `fetch()` call

Clicking the button doesn't send anything. The click fires a click event, which bubbles up the DOM. Its default action is to submit the enclosing form.

Before the submit event fires, the browser runs built-in constraint validation (required, type="email", pattern). If a field is invalid, the browser shows its error bubble and no submit event fires at all. That's why a handler you put on submit sometimes seems to be ignored.

If validation passes, you get the submit event:

const form = document.querySelector("#login");

form.addEventListener("submit", async (event) => {
  event.preventDefault(); // stop the native full-page navigation

  const data = Object.fromEntries(new FormData(form));

  const response = await fetch("/api/login", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(data),
  });
});

Without preventDefault(), the browser does a native form submission: it builds the request itself and navigates to the response, reloading the page. That still works, and it's often the more robust choice, but most SPAs intercept it.

What can go wrong here:

A handler throws before fetch() runs.
preventDefault() is missing, so the page reloads and your state is lost.
Validation blocks the submit and you never see an event.

2. Before the request leaves: CORS, cookies, CSRF

When you call fetch(), the browser decides what it's allowed to send.

CORS only matters if the request is cross-origin (different scheme, host, or port). A POST with Content-Type: application/json isn't a "simple" request, so the browser first sends an OPTIONS preflight asking the server whether this origin, method, and header combination is allowed. If the server doesn't answer correctly, the real request is never sent.

You'll see the classic error in the console:

Access to fetch at 'https://api.example.com/login' from origin
'https://app.example.com' has been blocked by CORS policy

Two points that trip people up:

CORS is enforced by the browser. curl will succeed against the same endpoint, which is a quick way to tell a CORS problem from a server problem.
The server can receive the request and process it; the browser just refuses to hand you the response.

Cookies are attached automatically for same-origin requests, subject to SameSite, Secure, and domain rules. For cross-origin requests you need credentials: "include" and a matching server configuration.

CSRF is the reason session-cookie apps also need CSRF tokens or SameSite cookies: a malicious page can make the browser send your cookies to a site you're logged into. Authorization headers set by your own JavaScript aren't attached automatically, which is part of why token-in-header APIs are less exposed to CSRF (and more exposed to XSS if you store the token carelessly). Both models have trade-offs.

3. DNS: finding the server

The browser has a URL, but it needs an IP address. It checks, in rough order:

Its own DNS cache
The OS resolver cache
A recursive resolver (your ISP's, or something like 1.1.1.1 or 8.8.8.8)
If the resolver doesn't have it cached: the root servers, then the TLD servers (.com), then the domain's authoritative nameserver

The result is cached according to its TTL, so most lookups never go past step 2 or 3.

dig api.example.com +short

Failure mode: a wrong or missing record, an expired domain, or a stale cache after a migration, which looks like "works for me, fails for them."

4. Connection: TCP or QUIC, then TLS

Now the browser opens a connection.

HTTP/1.1 and HTTP/2 run over TCP:

Client                    Server
  SYN  ------------------>
       <------------------ SYN-ACK
  ACK  ------------------>

Then TLS negotiates encryption: the server presents a certificate, the browser validates it against trusted authorities, and both sides derive session keys. With TLS 1.3, that's one extra round trip after TCP.

HTTP/3 runs over QUIC, which uses UDP. QUIC folds the transport and TLS 1.3 handshakes together, so a new connection needs fewer round trips.

Two honest caveats:

Browsers keep connections open and reuse them. A returning user often skips this whole stage.
TLS protects data in transit. It does nothing for how the password is stored in the database (step 8).

Check the certificate and negotiated protocol yourself:

openssl s_client -connect api.example.com:443 -servername api.example.com
curl -v https://api.example.com/

Failure modes: expired or mismatched certificate (browser blocks it), connection timeout, a firewall dropping packets.

5. The HTTP request, then the packets

Over the secure connection, the browser sends:

POST /api/login HTTP/1.1
Host: api.example.com
Content-Type: application/json
Cookie: ...

{"email":"user@example.com","password":"..."}

(In HTTP/2 and HTTP/3 this is binary-framed and the headers are compressed, but the semantics are the same.)

That data gets encrypted by TLS, split into packets, and handed to the OS network stack. On a typical Ethernet or Wi-Fi link the MTU is 1500 bytes, and a small login request usually fits in one or a few packets.

On your local network, the OS needs the MAC address of your default gateway. For IPv4 that's found with ARP (IPv6 uses Neighbor Discovery). Your router then performs NAT, rewriting your private address to its public one, and forwards the packet to your ISP.

From there, routers across the internet forward it hop by hop toward the destination network. You can see the hops:

traceroute api.example.com   # tracert on Windows

Failure modes: packet loss (TCP retransmits, so you see latency rather than errors), congestion, and a misbehaving middlebox.

6. The edge: CDN, load balancer, reverse proxy

In production, your request rarely hits the app directly. It usually reaches something like a CDN, a load balancer, or a reverse proxy such as nginx first.

These layers often terminate TLS (decrypt the traffic), apply rate limiting or a WAF, choose a healthy backend, and forward the request, frequently over a separate internal connection.

Client -> CDN/LB -> reverse proxy -> app server

This is where 502, 503 and 504 errors usually come from. They mean "I'm the proxy and the server behind me failed, was unavailable, or timed out", not "your code threw."

7. The server's OS and kernel

Here's the part most frontend developers never see. Your backend (Node, Java, Go, whatever) runs in user space. It can't touch network hardware directly. The kernel does that.

The path for an incoming request on Linux, simplified:

NIC -> DMA into a ring buffer -> interrupt / polling
    -> kernel network stack (IP, TCP)
    -> socket receive buffer -> your process

The network card writes incoming packets into memory using DMA, then signals the kernel.
The kernel's TCP/IP stack validates and reassembles the byte stream, handles acknowledgements and retransmission, and puts the data into the socket's receive buffer.
Your process is typically waiting in a system call such as epoll_wait. The kernel wakes it, and it calls read/recv to copy the bytes from kernel space into its own memory.

Node's event loop (libuv), for example, is built on this: one thread watches many sockets with epoll and runs your callback when data arrives.

You can watch the system calls of a running process:

strace -f -e trace=network,read,write -p <pid>

Failure modes: socket backlog full, too many open file descriptors, CPU starvation. These show up under load as timeouts and connection resets, not as exceptions in your code.

8. The backend and the database

Your framework parses the HTTP request and runs it through a pipeline, usually like this:

router -> middleware -> auth/rate limit -> validation -> handler

Frontend validation is for UX. Backend validation is the security boundary, because anyone can send a request without your frontend.

The handler looks up the user. Backends normally use a connection pool instead of opening a new database connection per request:

SELECT id, password_hash FROM users WHERE email = $1;

Inside the database, that query is parsed, planned (the optimizer picks a strategy), and executed. With an index on email it does a B-tree lookup instead of scanning the table. Pages are read from the buffer cache in memory when possible, and only go to disk (filesystem, then SSD) on a cache miss. You can see the plan:

EXPLAIN ANALYZE SELECT id, password_hash FROM users WHERE email = 'user@example.com';

Then the password check. The database stores a hash, never the password:

// pseudocode (use your platform's well-tested library)
const ok = await verifyPasswordHash(submittedPassword, user.password_hash);

Use Argon2id, bcrypt, or scrypt. They are deliberately slow, so a leaked database is expensive to brute-force. That means part of your login latency is intentional. Also return the same generic error for "unknown email" and "wrong password", so the endpoint doesn't reveal which accounts exist.

If login creates a session row, that's a write. A write is recorded in the write-ahead log (WAL) and flushed to durable storage before the database confirms the commit. This is the one place in the trip where the physical disk really is on the critical path.

Failure modes: missing index (slow query), pool exhausted (requests queue up), deadlock or lock wait, a database that's down.

9. The response, and the way back

The backend returns something like:

HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax

{"success":true,"user":{"id":123,"name":"..."}}

It travels back through the same kinds of layers in reverse: your process calls write/send, the kernel segments it into packets, the NIC transmits it, and it goes back through the load balancer, the internet, your router, and your OS to the browser.

Then back in JavaScript, two details are worth knowing:

const response = await fetch("/api/login", { /* ... */ });
// The promise resolves when response HEADERS arrive, not the full body.

if (!response.ok) {
  // fetch does NOT reject on 401/403/500. You must check this yourself.
  throw new Error(`Login failed: ${response.status}`);
}

const user = await response.json(); // reading the body is a separate async step
setUser(user);

fetch only rejects on network-level failures (and CORS blocks). A 401 is a successful HTTP exchange as far as the promise is concerned.

10. State, DOM, pixels

setUser(user) doesn't update the screen directly. React schedules a render, runs your components, reconciles the result against the previous tree, and commits the DOM changes.

Then the browser's rendering pipeline takes over:

Style -> Layout -> Paint -> Raster -> Composite -> GPU -> Screen

Style calculation works out which CSS applies, layout computes sizes and positions, paint records what to draw, and the compositor assembles layers (often on the GPU) and presents them on the next display frame.

If this stage is slow, it's usually a long JavaScript task or an expensive layout, and it shows up as poor INP. The user sees the delay as "the button feels stuck", even though the server answered quickly.

Illustrative timeline

These numbers are made up to show proportions, not measurements. Real values depend on distance, connection reuse, and your backend:

Stage	Typical order of magnitude
Validation + handler + `fetch()` start	about 1-5 ms
DNS (cache miss)	tens of ms
TCP + TLS (cold connection)	1-3 round trips
Network RTT to server	10-200+ ms depending on geography
Kernel + framework overhead	usually under a few ms
Password hash verification	tens to hundreds of ms (intentional)
Database query (indexed)	usually sub-ms to a few ms
React render + browser paint	a few to tens of ms

For most real apps, network round trips and the backend dominate, not kernel overhead and not the database lookup itself.

What can fail at each layer

Layer	Typical failure	Where you'd see it
HTML	Invalid field blocks submit	No submit event
JavaScript	Exception in handler	Console error
Browser	CORS block, mixed content	Console, red request in DevTools
DNS	Resolution failure	`ERR_NAME_NOT_RESOLVED`
TCP/QUIC	Timeout, reset	Stalled request
TLS	Bad or expired certificate	Browser security error
Network	Packet loss	Slow, retried requests
Proxy / LB	502 / 503 / 504	Status code, proxy logs
Server	Process crash, overload	5xx, connection reset
API	Validation failure	400 / 422
Auth	Wrong credentials, no session	401 / 403
Database	Deadlock, slow query, pool exhausted	Timeouts, DB logs
Rendering	Long task	Laggy UI, poor INP

How to debug the whole journey

Start at the top and move down until something looks wrong.

DevTools -> Network tab. Click the request and open Timing. It splits the request into queueing/stalled, DNS lookup, initial connection, SSL, request sent, waiting (TTFB), and content download. Long "Waiting" usually means the server; long "Initial connection" means the network.
Reproduce with curl to separate browser problems (CORS, cookies) from server problems:

   curl -s -o /dev/null -w "dns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n" \
     -X POST https://api.example.com/login \
     -H "Content-Type: application/json" \
     -d '{"email":"user@example.com","password":"test"}'

Check each layer directly: dig for DNS, openssl s_client for certificates, traceroute for the path.
Server side: application logs, proxy logs, then database slow-query logs and EXPLAIN ANALYZE.
Last resort: tcpdump or Wireshark for packets (TLS-encrypted payloads won't be readable) and strace for system calls.

The mental model

A Submit click isn't Button -> API -> Database. It's a stack of layers, each with its own failure modes and its own tools, and the response has to climb back up through every one of them.

You don't need to master all of them. Knowing which layer you're in is what turns "the form is broken" into a specific, checkable question.

Which layer has caused you the most confusing bug: CORS, a proxy timeout, a missing index, something else? And what tool finally showed you the problem?

"Frontend Performance in 2026: The Techniques That Actually Move the Needle Now"

Shrey Saraswat — Tue, 29 Sep 2026 07:44:01 +0000

Most "frontend performance" checklists still read like it's 2021: split your bundles, compress your images, use a CDN.

All still true.

None of it explains why a site can pass Lighthouse and still feel janky the moment someone clicks something.

That gap exists because the metric that actually measures "does this feel responsive" changed.

Interaction to Next Paint (INP) replaced First Input Delay as an official Core Web Vital back in March 2024, and as of early 2026 it's still the metric most sites fail — reporting puts INP as the most commonly-missed Core Web Vital, with a large share of sites still over the 200ms threshold.

FID only measured the delay before the browser started processing your first click.

INP measures every interaction on the page — clicks, taps, key presses — and reports the worst one.

You can't game a single data point anymore.

That shift changes what "performance work" should mean in practice.

This isn't a rehash of the code-splitting/image-optimization basics — it's what's actually new or newly relevant on top of that foundation.

The old checklist still matters, briefly

Skip this section if you've already got these covered.

If not, do them first — nothing below replaces them:

Code splitting — React.lazy() + Suspense, or Angular's lazy-loaded feature modules. Don't ship the whole app on first load.
Image optimization — WebP/AVIF, srcset for responsive sizing, lazy-load offscreen images.
Render-blocking resources — inline critical CSS, defer/async non-critical JS, font-display: swap.
Caching + CDN — hashed filenames so aggressive caching is safe, serve static assets from an edge, not your origin.

These are still correct.

They're also table stakes — most competent frontend teams already do them.

What follows is where the actual gains are hiding in 2026.

1. Diagnose INP with the Long Animation Frames API, not guesswork

The old Long Tasks API told you that something blocked the main thread for 50ms+.

It didn't tell you what — was it a script, a style recalculation, layout?

The Long Animation Frames (LoAF) API exposes that breakdown: script attribution, style/layout duration, and which specific function was responsible.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Blocking duration:', entry.blockingDuration);

    for (const script of entry.scripts) {
      console.log(script.name, script.duration, script.invoker);
    }
  }
});

observer.observe({
  type: 'long-animation-frame',
  buffered: true
});

If you've been trying to fix INP by guessing which component is slow, this replaces the guessing with an actual attribution trail. Chromium supports it; check current browser coverage before you build tooling around it exclusively.

2. Cut main-thread work with selective hydration

A big source of poor INP in component-heavy apps isn't one slow interaction — it's the sheer amount of JavaScript competing for the main thread before the page ever becomes interactive. Islands architecture (Astro, Qwik, and increasingly meta-frameworks built on React/Vue) addresses this directly: most of the page ships as static HTML, and only the components that actually need interactivity hydrate — and only when they're needed, not all at once on load.

The practical version of this in a React app you're not rewriting: audit what's actually interactive above the fold. A hero section with a static image and heading doesn't need to hydrate before a click handler three screens down does. If your framework supports partial or deferred hydration, that's real INP budget back.

3. Tell the browser what actually matters with `fetchpriority`

Browsers guess resource priority based on tag type and position. Sometimes the guess is wrong — a below-the-fold image loads before your actual LCP candidate. The fetchpriority attribute overrides that guess:

<img src="/hero.avif" alt="Product dashboard" fetchpriority="high" />
<img src="/footer-logo.svg" alt="Partner logo" fetchpriority="low" loading="lazy" />

It's a one-line change with a direct effect on LCP when your hero image was competing with less important requests. Check current support on Can I Use before relying on it as your only LCP fix — treat it as a targeted correction, not a substitute for actually optimizing the image itself.

4. Stop rendering what nobody can see

content-visibility: auto tells the browser to skip layout and paint work for off-screen content until it's about to become visible, while still reserving space so layout doesn't shift:

.long-list-item {
  content-visibility: auto;
  contain-intrinsic-size: 0 200px; /* estimated size, prevents CLS */
}

For long lists, comment sections, or any page with a lot of below-the-fold DOM, this cuts initial rendering cost without touching your component logic. It's a CSS-only performance win, which is rare enough to be worth calling out. Browser support has broadened over the last couple of years — verify current coverage for the browsers your users actually run.

5. Speculative navigation: prerendering before the click

The Speculation Rules API lets the browser prefetch or fully prerender a page before the user clicks the link, based on rules you define:

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/blog/*" },
    "eagerness": "moderate"
  }]
}
</script>

On a prerendered navigation, the next page can feel instant — the browser already rendered it in a hidden tab.

Two honest caveats: it's explicitly a multi-page-application technique (it targets full document navigations, not SPA route changes), and it's still limited availability — Chromium-based browsers only, not Baseline yet.

If you run a content site, blog, or traditional MPA, it's worth testing. If you're a SPA shipping client-side routing, this doesn't apply to you the way code-splitting does.

6. Audit your bundle instead of guessing what's heavy

Tree-shaking and dependency audits aren't new, but the habit of actually looking still gets skipped under deadline pressure. Run a visualizer before you assume you know what's bloating the bundle:

npx vite-bundle-visualizer

# or for webpack
npx webpack-bundle-analyzer stats.json

The recurring surprise is always the same shape: one dependency pulled in for a single utility function, sitting at 30–40kb gzipped. You don't know that until you look at the treemap.

Trade-offs worth being upfront about

Technique	Where it helps	Where it doesn't
LoAF API	Diagnosing why INP is bad	Doesn't fix anything by itself — it's a diagnostic tool
Selective hydration	Component-heavy apps with a lot of non-interactive content	Requires framework support; not a drop-in for existing React SPAs
`fetchpriority`	Correcting a wrong LCP-candidate guess	Doesn't help if the image itself is unoptimized
`content-visibility`	Long pages with lots of off-screen DOM	Needs a reasonable `contain-intrinsic-size` estimate or you'll get CLS instead
Speculation Rules	Multi-page apps, content sites	Doesn't apply to SPA client-side routing; Chromium-only today

None of these replace the fundamentals. They're what's left to optimize once code splitting, image formats, and caching are already handled — which is exactly the point where a lot of teams stop, because the easy wins are gone and the next layer requires knowing these exist.

A quick checklist

Have you measured INP with real user data (CrUX, RUM), not just lab Lighthouse scores?
Do you know which interactions are slow, or are you guessing? (LoAF API answers this)
Is everything above the fold actually necessary to hydrate immediately?
Does your LCP image have fetchpriority="high" and skip loading="lazy"?
Have you looked at a bundle visualizer in the last quarter, or are you assuming you know what's in there?

Worth discussing

If you're on a multi-page site, have you tried the Speculation Rules API yet — and did it actually feel instant, or did prerendering cost outweigh the win?

And for anyone dealing with INP specifically: what turned out to be your actual bottleneck once you looked, versus what you assumed it would be?

A Practical Guide to React's New : What Actually Animates (and What Doesn't)

Shrey Saraswat — Wed, 23 Sep 2026 11:18:25 +0000

React 19.3 shipped on npm on September 9, 2026, and it quietly stabilized something a lot of us have wanted for years: a native way to animate UI changes without reaching for a third-party library.

What `<ViewTransition>` actually is

It's a component that wraps part of your UI and tells React: "when this changes, animate it using the browser's native View Transition API instead of just swapping the DOM."

import { ViewTransition, useState, startTransition } from 'react';

function Panel() {
  const [showItem, setShowItem] = useState(false);

  return (
    <>
      <button
        onClick={() => {
          startTransition(() => {
            setShowItem((prev) => !prev);
          });
        }}
      >
        {showItem ? '➖' : '➕'}
      </button>

      {showItem && (
        <ViewTransition>
          <Details />
        </ViewTransition>
      )}
    </>
  );
}

Toggle showItem, and instead of the panel just popping in and out, it cross-fades. No CSS animation library, no manual onExit juggling.

React decides which kind of animation to run based on how the tree changed:

enter — the <ViewTransition> gets added
exit — it gets removed
update — its children change style or content
share — a named moves from one place to another

The rule that trips people up

Here's the part most quick-recap posts gloss over: <ViewTransition> doesn't animate every update.

It only animates changes caused by:

startTransition
a <Suspense> reveal
useDeferredValue

A plain setState call inside a regular event handler won't trigger the animation — it just updates immediately, the same as always. This is deliberate. React treats "urgent" interactions (typing, dragging, anything that needs to feel instant) differently from "non-urgent" ones (navigating, revealing content), and only the latter get animated.

So if you wrap something in <ViewTransition> and nothing happens, the first thing to check isn't your CSS — it's whether the state update is actually wrapped in startTransition.

Customizing animations by cause: `addTransitionType`

A single piece of state can change for different reasons that should animate differently. Classic example: a carousel. Clicking "next" should slide left-to-right; clicking "previous" should slide the other way — even though both actions just update the same currentSlide number.

addTransitionType lets you attach a label to the cause of the update:

function nextSlide() {
  startTransition(() => {
    addTransitionType('next');
    setCurrentSlide((c) => c + 1);
  });
}

function previousSlide() {
  startTransition(() => {
    addTransitionType('previous');
    setCurrentSlide((c) => c - 1);
  });
}

Then map each type to a different animation:

<ViewTransition
  enter={{ next: 'from-right', previous: 'from-left' }}
  exit={{ next: 'to-left', previous: 'to-right' }}
>
  <Page />
</ViewTransition>

React also exposes the transition type as a browser view transition type, so you can scope the actual animation in plain CSS using :active-view-transition-type(...) instead of inline objects, if you'd rather keep the animation logic out of your components.

Where it gets genuinely interesting: Suspense

This is the part that made me actually want to try it. You can wrap a <Suspense> boundary in <ViewTransition> and animate the swap from fallback to real content:

<ViewTransition>
  <Suspense fallback={<Loading />}>
    <Component />
  </Suspense>
</ViewTransition>

You can even use it to coordinate image and font loading — wrapping an <img> and a @font-face declaration in <ViewTransition><Suspense> means React waits for both to be ready before revealing them together, instead of letting them flicker in independently as they finish.

But the default behavior has a rough edge. If you just wrap a Suspense boundary like above, every reveal animates — including ones where the content was already cached and should just appear instantly. That feels like the app got slower, not smoother.

The fix is to be explicit about what should and shouldn't animate:

<ViewTransition update="auto" default="none">
  <Suspense fallback={<Fallback />}>
    <Component />
  </Suspense>
</ViewTransition>

This gives you three rules worth keeping in mind whenever you combine <ViewTransition> with Suspense:

Fallbacks should appear immediately, without animation — the loading state shouldn't feel delayed
The swap from fallback to final content should animate — that's the actual payoff
Content that's already cached and doesn't suspend should appear immediately, without animation

Skip that last one and you'll animate things that were never actually loading, which just reads as unnecessary lag to the user.

Common mistakes to watch for

Mistake	What happens	Fix
Forgetting `startTransition`	Nothing animates, state just updates instantly	Wrap the update in `startTransition`
Animating every Suspense reveal	Cached content feels artificially slow	Use `update="auto" default="none"`
Using `<ViewTransition>` for React Native	It's DOM-only for now	Native/other-platform support isn't there yet
Expecting it to replace all animation libraries	It only animates transition-triggered changes	Keep a library for hover states, gestures, and non-transition micro-interactions

Should you adopt it now?

Honestly — probably, for the cases it's built for. It's stable, it requires no build step or extra dependency, and it's built on a real web standard rather than a JS-computed animation loop. If you're currently hand-rolling enter/exit animations with useEffect and CSS classes, this replaces that machinery directly.

Where I'd hold off: if you're deep into a library like Framer Motion for complex gesture-driven interactions (drag, spring physics, layout animations outside of React's transition model), there's no reason to rip that out.
<ViewTransition> solves a specific, narrower problem — animating mounts, unmounts, and content swaps tied to state transitions — not general-purpose animation.

A quick checklist

Is the state update wrapped in startTransition (or a Suspense reveal / useDeferredValue)?
Does this update need different animations depending on cause? → use addTransitionType
Are you animating a Suspense boundary? → set update="auto" default="none" to avoid animating cached content
Do you actually need a full animation library for this interaction, or does <ViewTransition> cover it?

Worth discussing

Has anyone here actually shipped <ViewTransition> in production yet? I'm curious whether the Suspense-fallback behavior needed more tuning than the docs suggest, and whether you kept an existing animation library around alongside it or dropped it entirely.

DEV Community: Shrey Saraswat

How Was State Managed in Frontend Development in the Old Days and Its Evolution?

The simplest case: a counter

Where it breaks: the cart

How the tools evolved

The same cart, declaratively

What to take from this

If an interviewer asks

Your turn

An 11-Week React Roadmap: What to Build Before 2026 Ends

The plan at a glance

Stop 1 (Oct 14 – 20): Lock the foundations

TypeScript: the three ideas that pay off in React

Modern CSS you can use today

Tooling

Stop 2 (Oct 21 – Nov 3): React 19 deep dive

Actions and useActionState

useOptimistic

use() and Suspense

React Compiler and the memo cleanup

Stop 3 (Nov 4 – 17): Full-stack Next.js

Server Components: data fetching without an API layer

Server Functions for mutations

Auth

Streaming, caching and revalidation

Deploy early

Stop 4 (Nov 18 – 24): State, data and forms

TanStack Query: cache and mutations

Forms: React Hook Form + Zod

Typed API layer

Live updates

Stop 5 (Nov 25 – Dec 8): UI and design system

Design tokens in Tailwind v4

Ten components, not fifty

Storybook as documentation

Accessibility audit

Dark mode, motion and i18n

Stop 6 (Dec 9 – 18): Test, speed and CI

Unit and component tests

Three E2E journeys

Performance targets

CI with GitHub Actions

Error monitoring

Stop 7 (Dec 19 – 31): AI feature and ship

Build the AI feature with the right expectations

Tool-calling and MCP

Ship the portfolio and write about it

Plan 2027

Common mistakes with a plan like this

If you can't do 11 full weeks

Key takeaways

The Death of Server-Side Uploads? A Frontend Guide to Direct-to-Cloud Uploads in React

1. The Browser Already Gives You the Tools

2. What Changes With Direct Uploads?

3. Implementing Direct Uploads in React

4. Upload Progress and Cancel

5. Make the Upload UI Resilient

6. File Validation: What the Frontend Can and Cannot Do

7. Mistakes That Break the First Attempt

8. Multiple Files and Large Uploads

9. Is Direct-to-Cloud Always Better?

Checklist

Takeaway

" What Actually Happens When You Click \"Submit\"? A Request From Browser to Database and Back "

The whole trip on one page

1. The click: from your finger to a fetch() call

2. Before the request leaves: CORS, cookies, CSRF

3. DNS: finding the server

4. Connection: TCP or QUIC, then TLS

5. The HTTP request, then the packets

6. The edge: CDN, load balancer, reverse proxy

7. The server's OS and kernel

8. The backend and the database

9. The response, and the way back

10. State, DOM, pixels

Illustrative timeline

What can fail at each layer

How to debug the whole journey

The mental model

"Frontend Performance in 2026: The Techniques That Actually Move the Needle Now"

Actions and `useActionState`

`useOptimistic`

`use()` and Suspense

1. The click: from your finger to a `fetch()` call

3. Tell the browser what actually matters with `fetchpriority`

What `<ViewTransition>` actually is

Customizing animations by cause: `addTransitionType`