What Exactly Is Next.js?
Next.js is a React framework that provides the structure needed to build full web applications with React. While React itself is a library for building user interfaces, Next.js layers on the tools and conventions required to turn those interfaces into complete, production-ready products. It handles concerns that sit outside the component model, such as routing, server-side rendering, and configuration.
The framework was created by Guillermo Rauch, who is also the CEO of Vercel. In a recent Smashing Podcast episode, Rauch sat down with Drew McLellan to discuss the origins of Next.js, the architecture behind it, and the ecosystem of front-end development that has grown around it.
Rendering on the Server by Default
The foundational idea behind Next.js is that it runs React on the server by default. This is a deliberate departure from the traditional client-side rendering approach where a React application boots up in the browser and renders content only after then JavaScript bundle has been downloaded and executed.
By pre-rendering the page on the server, Next.js sends HTML to the client that is immediately viewable. This improves perceived performance and ensures that content is available even if JavaScript fails to load or execute on the user's device. Rauch noted that this server-first mindset mirrors the way the web originally worked, before the shift toward heavy client-side JavaScript.
Hydration, the process of attaching React's event handlers and state management to the pre-rendered HTML after it loads in the browser, still takes place. But the critical distinction is that the visitor sees real content first, rather than a blank page waiting for the JavaScript engine to run.
The Evolution of React in Production
Rauch explained that the early days of server-side rendering with React were cumbersome. Developers had to assemble their own tooling—manually reconciling React's client-side code with a separate Node.js server, handling routing, and bundling assets. This fragmented setup was difficult to maintain and led to a poor development experience where errors were hard to debug and the architecture was bespoke for every project.
Next.js emerged to systematize these pieces. It offers a unified approach that bakes in best practices for server-side rendering, code splitting, and routing. The aim was to simplify the developer's job by removing the burden of stitching multiple libraries and scripts together.
By doing so, the framework also normalized the deployment model. An application built with Next.js can be deployed to any environment that supports Node.js. This portability means front-end teams do not need to worry about environment-specific configuration when moving from a local server to a production host.
Static and Dynamic on the Same Site
One of the framework's strengths, according to Rauch, is that it does not force a single rendering model. Developers can choose a path per page:
- Static generation: Pages are compiled into HTML at build time and served via a CDN. This is suitable for content that changes infrequently and provides the best possible performance.
- Server-side rendering: Pages are rendered on each request against a Node.js server, which is appropriate for truly dynamic data that changes by the second or is personalized per user.
Applications can mix these two approaches comfortably, using static generation for marketing pages while falling back to server rendering or client-side data fetching for parts of the interface that are interactive or permission-sensitive. Static pages can also anticipate dynamic content by querying an API from the client after hydration.
This hybrid model recognizes that with a single monolithic server, a site experiences traffic peaks that are difficult to scale. Static pages distributed on a CDN offload the heaviest volume, while only the most time-sensitive pages hit the server logic.
The Progress of the Front-End Stack
The conversation also touched on how far front-end tooling has come since the early 2010s. Ten years ago, building a web app required invoking a command line to run tools like Grunt or Gulp, and then handling a pile of disparate modules for JavaScript, CSS and live reloading.
Rauch characterized the driving forces of progress as efficiency and quality. Developers persistently favor the stack that lets them ship quickly without sacrificing maintainability. This led to module bundlers capable of transforming code in reasonable amounts of times, and later to zero-configuration build tools that abstract away all the low-level concerns.
Looking ahead, Rauch suggests that the front-end and back-end ecosystems will continue to converge. Tools will increasingly focus on the products themselves, asserting sensible defaults and codifying performance best practices so that teams of any size can deliver web experiences that are fast, accessible and easy to update.
Show Notes
- Guillermo Rauch on Twitter
- Next.js
Guillermo Rauch, co-creator of Next.js and CEO of Vercel, talks about how the framework fits into the Jamstack world, why it’s built around React, and where it lands between fully static sites and server-rendered applications. Rather than a step-by-step guide, this is a look at the architectural thinking behind one of the most widely used React frameworks.
Why React needs a framework layer
Rauch draws a clear line between how React works inside Facebook and how it works in the wild. At Facebook, React runs alongside internal server-rendering infrastructure that is tightly coupled to the company’s own stack. When Facebook open-sourced React, it shipped what Rauch calls “the engine, but not the car.” Developers were left to assemble their own vehicles, and out of that need came frameworks like Next.js, Gatsby, and React Static.
The distinction is important because React alone is more of a component library than a full application framework. Facebook itself uses React for discrete widgets — chat, notifications, newsfeed components — embedded in a much larger existing application. For anyone building standalone products, that component-level approach isn't enough.
Next.js takes React as its base and adds the missing primitives. “The learning curve is primarily about React with some added surface for Next.js, particularly around data fetching and routing,” Rauch says. That includes a set of production defaults around bundling with Webpack, TypeScript support, and zero-config build tooling. Instead of tuning Babel and Webpack manually, developers get an environment that is ready to run, and the promise is that upgrading the framework brings performance improvements without rework.
The opinionation trade-off
Rauch describes Next.js as unopinionated in its ecosystem, citing the large examples directory on GitHub. There are integrations for Apollo, Redux, MobX, Firebase, and a wide variety of CSS approaches. The embedded default is CSS with support for styled-jsx, which Rauch says deliberately models web platform conventions.
The framework does take firm positions, though, on two core points. React is not swappable, and the page model is fixed. Next.js organizes code in a pages directory, and each file becomes an entry point. This diverges from the single-page application pattern that dominated the early React era.
“The internet is made up of websites with lots of pages that create distinct entry points,” Rauch explains. Those entry points arrive from search engines, social media, and email links. Each visitor shouldn’t have to download the entire application at once. That decision to embrace the multi-page model drove the move to server rendering and, eventually, static generation.
From server rendering to static hiccups
Next.js did not start as a Jamstack framework. It was built for server-side rendering, which is why it gained traction in dynamic environments like e-commerce and social networks. Later versions added static optimization: pages without top-level data fetching are automatically exported as plain HTML instead of being server-rendered during requests.
That hybrid model is central to how Next.js is positioned today. Static pages can be “hoisted” to a CDN, cached at the edge, and served without ever hitting the origin server. Dynamic needs, on the other hand, are handled with server-side rendering where runtime code executes per request. The user can choose a static page for the home page, statically generate blog posts from a dynamic data source, and rely on client-side JavaScript for a dashboard where data is highly personalized.
For Vercel’s own site, Rauch notes that all marketing pages are fully static, the blog uses static site generation from a CMS, and the dashboard relies on static shells backed by API calls. Even those seemingly dynamic interfaces can be pre-rendered, because the initial HTML skeleton is served statically and JavaScript takes over on the client.
Code splitting and bundle optimization
JavaScript is one of the heaviest contributors to web performance problems, Rauch notes, because it tends to execute rapidly and synchronously on the main thread. Small amounts of JavaScript can have a disproportionate impact compared to images, which the browser can process in parallel. That’s where code splitting plays a crucial role.
Next.js automatically splits JavaScript per page. The initial request delivers code relevant to that one route, plus some common shared bundle so that subsequent navigations are instant. Following a link triggers automatic prefetching of related pages, resulting in navigation that feels like a single-page app while preserving the benefits of distinct entry points.
Google has contributed a further optimization called Module and No Module. This ships progressive differential JavaScript — a modern bundle to browsers that support modules, and a legacy bundle with polyfills to those that don’t. It’s turned on automatically for all users of the framework. One named example was an unnamed Parnaby’s installation on Vercel that saw roughly a 30 percent reduction in code size just by upgrading Next.js versions.
Those wins compound because of the community ecosystem. Sticking with popular defaults has its own benefits — a comment Rauch validated by noting that build performance claims about alternatives often overlook the value of inherited ecosystem compatibility. For Next.js itself, that means evolving from Webpack 4 to Webpack 5 in an incremental way, offering it as an opt-in flag before making it the default, so that third-party tools aren’t broken by each update.
The path between static and dynamic
The architecture of Next.js grew around the idea of the Jamstack tenet: pre-render as much as possible at build time rather than rendering at runtime. That preference reduces infrastructure load and improves user-perceived latency.
Yet the useful life of a static page stretches only as far as the underlying content stays unchanged, and some sites live in that middle ground permanently. Set the two extremes of fully static pages and full SSE (server-side rendering), Rauch says, and Next.js offers a few tools that fall between them to avoid making the content editor wait on a full rebuild to fix a typo.
Next.js 9.5 took incremental static generation ( Incremental Static Regeneration as it was later named) from an experimental flag to a flagship feature. Then pages can be regenerated individually, at runtime, without touching the rest of the site. What used to require a complete build that took minutes now resolves in milliseconds for a single page.
The other 9.5 win for production users is rewrites, making gradual adoption of Next.js less intrusive.
He explains: “You can say, ‘I want to handle all new pages that I created with Next.js with Next.js, and the rest I want to hand off to a legacy system.’” This way, development teams migrate incrementally, and old URLs are proxied to existing stacks while new ones resolve through the framework that is replacing them.
Deployment and community
There is no single way to run Next.js in production, and that’s intentional. Running the included next start production server is equivalent to self-hosting. In that scenario, the operator is responsible for administration, scaling, caching and cache invalidation, replication, and global failover.
Vercel deploys the platform on a serverless model with no infrastructure administration duties, and it handles these concerns.
Apple self-hosts on Next.js due to private security and privacy requirements, while The Washington Post uses Vercel as a customer.
The book on who works on Next.js is not all Vercel either. Google’s Chrome has a longstanding role in optimizing and testing by partnerships with companies building large deployments. A faster update cycle, named Fast Refresh,### Heading
Deployment and community
Next.js offers two distinct operating modes in production: next start runs a self-hosted server, putting infrastructure responsibility on your own team; Vercel deploys the same application as serverless functions, removing the administration burden. Both are valid, and Rauch notes that Apple relies on self-hosting for its homepage while The Washington Post picks the Vercel-managed path.
Development follows a similar pattern. The built-in dev server makes heavy use of fast refresh, live HMR updates, to keep the edits instantly visiable. The same principles are carrying what has grown into a wide ecosystem of contributors that sit well beyond Vercel’s perimeters. Google Chrome is a regular contributor to the framework for engineering reasons, contributing to optimizations, shared testing and partner
