By Braian de Barros, Developer at Urudata Software
React changed the way we build user interfaces, but it left key problems unsolved, such as routing, server-side rendering, and SEO. Next.js fills those gaps. During the latest edition of Urudata Software’s Tech Talks, we presented a session that broke down the framework, explored its core concepts, and compared it with other alternatives in the ecosystem.
What Problem Does Next.js Solve?
To understand Next.js, it’s important to first understand where it comes from. React dominated frontend development for years, and for good reason: its component model and ecosystem are enormous. But React by itself only solves part of the problem. It handles the view layer—how components are built and updated on screen—but leaves everything else out: page navigation, data fetching, initial load optimization, and server-rendered content.
A traditional React application runs entirely in the browser. The server delivers a nearly empty page (a <div> and a JavaScript file), and the user’s browser is responsible for building the entire interface. This creates two very real problems:
- Poor SEO: When Google or another search engine attempts to index the page, it encounters mostly empty HTML. The actual content only exists after JavaScript executes, which many crawlers either don’t execute or only execute partially.
- Slow Initial Load: Users see a blank screen until the browser downloads, parses, and executes all the required JavaScript. In large applications with many dependencies, this can mean several seconds of waiting.
Created by Vercel in 2016, Next.js was designed specifically to address these issues. It doesn’t replace React—it extends it. It adds routing, server-side rendering, data fetching, performance optimizations, and backend capabilities, all integrated under a set of clear conventions. Today, it has more than twice the weekly downloads of Angular and has become the de facto standard for production React applications.
The Framework’s Key Building Blocks
Filesystem-Based Routing
In most frameworks, defining routes requires configuring a separate file or library that maps URLs to components. Over time, those configuration files grow, become harder to maintain, and often turn into a source of conflicts in larger teams.
Next.js solves this through one of its most elegant design decisions: the folder structure defines the routes. There is no routing configuration file. Creating a blog/ folder containing a page.tsx file automatically generates the /blog route. A [slug]/ folder creates a dynamic route capable of accepting any URL value (for example, /blog/my-first-post). A (marketing)/ folder groups routes without affecting the URL, making it useful for organizing code internally without changing what users see.
Additionally, each route can include special files of its own: layout.tsx for shared UI across multiple pages, loading.tsx for displaying skeleton states while data loads, error.tsx for handling errors without crashing the entire application, not-found.tsx for customizing 404 pages.
Server Components and Client Components
This is one of the most significant changes introduced by Next.js—and also one of the most misunderstood.
Traditionally, React components run in the browser. The server sends the code, and the browser does all the work. The downside is that this requires shipping a large amount of JavaScript to the client, including logic that doesn’t actually need interactivity, such as product listings, blog articles, or data tables.
Next.js flips that model. By default, all components are Server Components. They render on the server, the resulting HTML is sent ready to display, and they add zero JavaScript to the client bundle. Only when a component requires real interactivity—handling clicks, maintaining state, or using hooks such as useState or useEffect—do developers add the "use client" directive at the top of the file, converting it into a Client Component.
This allows applications to be lighter and faster by sending only the JavaScript that actually needs to run in the browser.
Four Rendering Strategies
Unlike many frameworks that force developers to choose a rendering strategy for the entire application, Next.js supports all four major approaches—even within the same application.
- CSR (Client-Side Rendering): The browser builds the UI using JavaScript. Ideal for private areas such as dashboards where SEO is irrelevant.
- SSR (Server-Side Rendering): The server generates HTML on every request. Ideal for pages that require fresh data and strong search engine visibility, such as search results or personalized content.
- SSG (Static Site Generation): HTML is generated once during the build process. Ideal for content that rarely changes, such as blogs, documentation sites, or landing pages.
- ISR (Incremental Static Regeneration): Combines the strengths of SSG and SSR. Pages are served statically but regenerated in the background every N seconds. Perfect for e-commerce catalogs or news feeds.
The key advantage is flexibility: every page—or even every component—can use the rendering strategy that best fits its requirements, and those decisions can evolve without requiring architectural rewrites.
Built-In Data Fetching
In a traditional React application, fetching data from a server usually involves loading states, side effects, and additional libraries such as React Query. It is repetitive code that every team ends up writing in one way or another.
With Next.js Server Components, the model changes entirely. A component can simply be declared as async and fetch data directly on the server. Data arrives at the client already resolved, without visible loading states, without side effects, and without adding extra JavaScript to the client bundle.
In addition, Next.js allows developers to control caching behavior at the request level. Data can be forced to refresh on every visit, cached indefinitely, or revalidated after a specified period. This level of granularity eliminates the need to choose between an application that is “entirely static” or “entirely dynamic.”
Backend Capabilities Inside the Same Project
One of the most significant shifts in modern web development has been the blurring of the line between frontend and backend. Next.js embraces this trend through two mechanisms.
API Routes allow developers to create traditional REST endpoints within the same project, eliminating the need for a separate server. This is useful for webhooks, third-party integrations, or endpoints consumed by external clients.
Server Actions take the concept even further. These are functions that run on the server but are invoked directly from the user interface. When a user submits a form, the function executes on the server, validates data, writes to the database, and can revalidate the page—all within a single workflow. This removes an entire layer of boilerplate that historically required building APIs solely so the frontend could communicate with the backend.
How Does It Compare to Angular?
This comparison came up during the talk because it is a recurring question among teams evaluating frameworks. The answer is not that one wins and the other loses—they reflect different philosophies.
Angular is opinionated. It makes decisions on behalf of the team, including routing, HTTP communication, forms, and dependency injection. It scales well in large projects with many developers. Its greatest strength is consistency: if you know one Angular project, you can quickly understand another. The tradeoff is a steeper learning curve and the migration costs associated with major paradigm shifts between versions, such as the move to standalone components or the transition from RxJS-centric patterns to signals.
Next.js is flexible. It delegates many decisions to the team, providing freedom but also creating opportunities for inconsistency if clear standards are not established. Its greatest advantage is speed—from idea to production—and the ability to choose exactly the tools each project requires.
In practice, the right choice depends on the team’s context: their previous experience, the nature of the project, team size, and the technologies they already use.
The AI Factor in Stack Selection
One aspect that few teams consider when evaluating frameworks is how they interact with AI tools. Modern AI models are disproportionately trained on React + Next.js + Tailwind code simply because there is significantly more public code available in that stack than in almost any other. Tools such as v0, Cursor, and Claude Code naturally generate this stack—and typically generate it with higher quality than alternative frameworks.
This has practical consequences. Prototypes are built faster because AI can generate functional components with fewer iterations. Refactoring becomes more reliable because models understand Next.js conventions more deeply. Developer onboarding accelerates because new team members can rely on AI assistance to better understand project structures and patterns.
This does not invalidate choosing another stack, but it is a productivity factor that deserves consideration. AI output quality is not consistent across frameworks, and that difference creates an economic impact that accumulates sprint after sprint.
Conclusion
Next.js solves problems that React leaves open: routing, rendering, data fetching, and optimization. It doesn’t solve them through patches or a collection of independent libraries. Instead, it provides an integrated framework that allows development teams to choose how each part of an application should be rendered based on its specific requirements.
Is it the right choice for every project? No. But for teams building with React and looking for strong SEO, high performance, and rapid development, it is difficult to find a more complete alternative. And whether we like it or not, the fact that AI tools generate better code in this ecosystem is becoming an increasingly important factor in day-to-day software development.
Braian de Barros is part of the development team at Urudata Software. During Tech Talks 2026, he presented the session “Next.js”, where he explored tools, approaches, and practical experiences related to modern web development.
