The dev server serves the source code on demand, but it does not serve the node_modules the same way. The dependencies are pre-bundled once at startup, and the browser receives a single merged file per dependency instead of the library’s internal module tree. The previous chapter covered the on-demand transform; this chapter explains the exception…
The Vite dev server is a static file server with a transform pipeline attached. When the browser requests a module, Vite intercepts the request, transforms the file into browser-executable JavaScript, and returns it. The browser then parses the returned code, discovers the imports, and requests those modules in turn. The module graph is traversed by…
Vite’s project structure differs from the bundler-based tools in one defining way: the index.html is the entry point, and it lives in the project root, not in the public/ directory and not in the src/ directory . The previous chapter covered the scaffolding; this chapter explains what the generated files do, why the index.html is…
Vite is installed as a development dependency of the project, and the project itself is created with the create-vite scaffolding tool. The previous chapter explained why the dev server is unbundled; this chapter covers the commands that put that dev server into a working project. The installation has two requirements that the administrator must check…
Vite was created on a single observation: traditional bundlers process your entire application before the browser can display anything, and the larger the app, the longer you wait . Vite rejected that trade-off by splitting the work into two parts. Dependencies—the libraries that rarely change—are pre-bundled once using fast native tooling. Source code—the application code…
An async component is a Server Component that is declared with the async keyword and uses await directly in its render body. It is the feature that makes the Server Component’s data access natural: the component reads the database, awaits the promise, and returns the JSX. The previous chapters covered the build-time and request-time models;…
The request-time model is the second execution environment for React Server Components. The previous chapter covered the build-time model, where the components run once during the build and the output is frozen into a static artifact. The request-time model runs the Server Components on a web server for each incoming request, which means the component…
The “server” in React Server Components does not have to be a running web server. It is any environment separate from the client application and the SSR server, and it can execute once during the build, on a CI machine, before any bundle is produced . This is the build-time model: the Server Component reads…
The most common source of confusion in the React ecosystem is the conflation of three distinct concepts: Client-Side Rendering (CSR), Server-Side Rendering (SSR), and React Server Components (RSC). They are not competing alternatives; they are layers that solve different problems. The previous chapter established that RSC is a component type, not a framework. This chapter…
React Server Components (RSC) are a new type of component that renders ahead of time, before bundling, in an environment separate from your client app or SSR server . The “server” in RSC refers to this separate environment—it can run once at build time on a CI server, or per-request on a web server ….