React, Next and friends in designer language

What is a framework and how does it differ from a library?

MDN defines a framework as a library that offers opinions about how software gets built, which brings predictability and homogeneity to an application. Frameworks solve a specific problem: when data changes, the screen has to be updated to match.

A useful precision: MDN points out that, technically, React is not a framework but a library for rendering UI components. In practice it is called a framework anyway; what helps is knowing which part of the project each tool decides.

What is a component, and how does data travel?

React’s documentation sums it up this way: a component is a JavaScript function you can sprinkle with markup, and it can be as small as a button or as large as an entire page. The markup is written in JSX, a syntax that looks like HTML but is stricter.

It is almost a design system in code: if the “Product card” component changes, it changes on every screen where it appears.

Data flows down through props. According to React, every parent component can pass information to its children through props, which resemble HTML attributes but accept any JavaScript value. React also recommends writing components as pure functions: given the same inputs, they return the same result, which avoids an entire class of baffling bugs as the code grows.

The “Thinking in React” guide starts right where you do: drawing boxes around every component in the mockup and naming them. It adds that, if you work with a designer, they may have already named the components in their design tool: “ask them”.

What do Next.js, Vue, Svelte and Astro offer?

Data from each project’s official documentation, checked on November 3, 2026:

In Next.js, routes come from folders: a blog folder with a page file creates the /blog route, and a [slug] folder inside it generates one page per entry from data. A layout file defines what several screens share. Looking at the folders of a generated project tells you how many screens it really has.

For a new project, React’s documentation recommends starting with a framework and names Next.js, React Router and Expo (for native apps). Building from scratch is possible, but you then choose routing and data loading yourself.

How do you choose without getting lost?

You do not need to master the framework to design well, but it helps to know what your project asks of it:

MDN warns about real costs: frameworks take time to learn, add their own code to the final site and, if everything is written in JavaScript, can produce pages that are not semantic or accessible. It also notes that client-side routing does not announce the page change or move focus by itself, and that no framework has solved this perfectly. Ask for it in your design.

What changes when an AI generates the app?

The tool often picks the framework for you. The v0 documentation, for example, says it works with Next.js, Tailwind and shadcn/ui. Three consequences:

• Read the structure. The folders of a Next.js project mirror its routes. You can check that every screen in the design has its page; reading code without coding explains how.
• The framework needs maintenance too. The Next.js blog announced security releases in July, August and September 2026, an out-of-band update on October 14 and another scheduled for November 3. A published app needs someone to update it, as deploy for designers explains.
• Agents read instruction files. Since Next.js 16.2, create-next-app includes an AGENTS.md file that tells coding agents to read the framework’s documentation before writing code.

What runs in the browser and what runs on the server is explained in frontend vs. backend; here it is enough to know that the framework decides that boundary. For data, see APIs for designers, databases for designers and minimum technical skills.

Example

Illustrative example: a designer wants a catalog with search and a detail page for each product. Following “Thinking in React”, she draws boxes on her mockup and names them: Header, SearchBar, ProductCard and ProductList. The card appears in the list and in “related products”, so it is a component. The AI tool proposes Next.js. She goes through the table’s questions: there are several screens with data and no sign-in. Opening the generated project, she finds a [slug] folder with a page file, just as the Next.js documentation describes. Before publishing, she talks to engineering, who confirm the team already uses React: the team makes the decision, not the tool.

How to apply it tomorrow

1. Draw your app as boxes: one per screen and one for each piece that repeats. If a box appears on three screens, it is a component: give it a name and use it the same way in Figma and with the AI.
2. For each box, write what data it receives and where it comes from. That list later defines the props or the API calls.
3. Ask the team which framework they use and who updates it.
4. When the AI generates a new component, ask it to use the name from your design. If it does not match, there is a difference to clear up.

Common mistakes

• Choosing the framework before defining the flow.
• Believing React is a visual design rather than a way to build the interface.
• Using a full framework for a one-screen page.
• Switching frameworks halfway through the project because it is trendy, or accepting the one the AI proposes without asking who will maintain it.

Sources

• React, “Describing the UI” (components, JSX, props and pure components)
• React, “Thinking in React” (from mockup to components)
• React, “Creating a React App” (recommended frameworks)
• React, “Versions” (version 19.3)
• Next.js, “Documentation” (what Next.js is, routers)
• Next.js, “Layouts and Pages” (folder-based routing)
• Next.js, blog (version 16.4 and security notices)
• Next.js, “Next.js 16.2: AI Improvements” (AGENTS.md)
• Vue, “Introduction”
• Svelte, “Overview”
• Astro, “Why Astro?”
• MDN, introduction to client-side frameworks (what a framework is, costs and accessibility)
• v0, documentation (Next.js, Tailwind, shadcn/ui)