Next.js is a React framework for server-side rendering, static generation and hybrid applications. It provides file-based routing, API routes, Incremental Static Regeneration and support for React Server Components. Optimized for performance and developer productivity, it runs well on Vercel and other cloud platforms.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Technical building block: can be automated, integrated, or operated.
Concrete cog in the system that works inside larger relationships.
Next.js is a React framework for hybrid web applications: it combines file-based routing with server-side rendering and static generation (optionally including incremental updates). It also provides API routes/route handlers and supports React Server Components.
Next.js was developed by Vercel, together with the open-source community, and was first released on GitHub on October 25, 2016. It grew out of a common problem with client-rendered React apps: content is produced mainly in the browser, making initial delivery and SEO harder to control. Next.js addresses this by shifting parts of the rendered output into the server and/or build context. Public project history lists multiple original authors (including Guillermo Rauch and Tim Neutkens), while Vercel maintains and leads the open-source development.
Think of Next.js as a “route compiler”: (1) The file system defines which URLs exist (file → route). (2) For each route, you apply a rendering path—static output produced during the build, server rendering at request time, and (when configured appropriately) later incremental refreshes of static results. (3) During rendering, Next.js splits execution along a server/client boundary; React Server Components are part of this server-side component model used in the App Router concept. (4) In parallel to UI routes, you can implement server-side endpoints as route handlers/API routes in the same project so page flows can call server logic as part of the request pipeline.
Next.js uses project files to determine URL and page/route structure, reducing the need for manual routing declarations.
The output can be generated as static content during the build, rendered on the server at request time, and—under suitable setup—incrementally refreshed later.
Next.js’s component model separates what runs on the server versus what runs in the browser; React Server Components fit into this server/client approach used in the App Router structure.
Besides UI paths, Next.js can host server-side endpoints inside the same project, integrating server logic into the request flow.
Next.js is a good fit when you want a React application where different routes can use different delivery strategies (e.g., pre-rendered pages vs. server-rendered content) and where routing is derived from the project structure. The main trade-off is operational/modeling complexity: you need to choose the right rendering approach per route and keep the server/client boundary consistent, otherwise you can run into surprises around data availability and caching/refresh behavior. A typical prerequisite is a Node.js-based development/runtime environment.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.