# Deciphering 'use client': Why Automatic Migration Tools Prioritize It > Source: > Published: 2026-07-01 10:00:12+00:00 If you have spent the last few years building with Vite, you are accustomed to the Single Page Application (SPA) mental model. In that world, every component is a client component. Every `useEffect` runs in the browser, and every `useState` hook manages memory directly on the user's machine. However, migrating to Next.js and the App Router changes this paradigm fundamentally. Next.js assumes every component is a Server Component by default. This shift offers massive performance gains by reducing bundle sizes, but it introduces a friction point: the `'use client'` directive. When transitioning a legacy Vite project to Next.js, manually auditing hundreds of files to decide whether they should be Server or Client components is a monumental task. This is why tools like [ViteToNext.AI](https://vitetonext.codebypaki.online/) often default to injecting the `'use client'` directive at the top of migrated files to ensure immediate functional parity with the original SPA logic. Automating this injection serves three primary purposes during a migration: `useState` and `useContext` . Server Components cannot hold state, so without the directive, the application would crash during build.`window` , `localStorage` , or `document` . Since Server Components execute in the Node.js/Edge environment, these references throw errors unless marked for the client.`onClick` or `onChange` are strictly client-side features. It is important to remember that `'use client'` does not mean "only run in the browser." Client Components are still pre-rendered on the server to generate initial HTML. Instead, the directive acts as a boundary marker. It tells the Next.js compiler that this component and all the components it imports should be included in the client-side JavaScript bundle. Automated tools look for specific patterns to trigger this injection: `useState` , `useEffect` , `useReducer` ).While automation speeds up the migration process, it isn't flawless. There are specific scenarios where an AI or script might over-apply the directive, leading to sub-optimal performance. If an automated tool detects a `useState` in a high-level wrapper, it will mark it as a Client Component. Consequently, every child component in that tree—even if they are purely static—becomes part of the client bundle. This negates the benefits of Server Components. Sometimes a component simply formats a date or renders a static list. If this component was part of a folder containing other client-heavy files, a broad migration script might tag it unnecessarily. A pure Server Component would be much lighter for the end user. In Vite, we fetch data inside `useEffect` . A migrated script might keep this pattern by using `'use client'` . However, in Next.js, the "Right Way" is often to remove the directive, delete the `useEffect` , and fetch the data directly as an `async` function within a Server Component to avoid waterfalls. Once you have successfully used an automated flow to get your project running in Next.js, you should perform a manual "De-clienting" audit: `@next/bundle-analyzer` to see if your `page.js` files are heavier than expected due to excessive client boundaries.Automatic injection of `'use client'` is a necessary bridge. It transforms a complex, potentially months-long manual refactoring process into a manageable starting point. The goal of automation is to get the code "working" in the new environment; the developer's role is then to optimize it by selectively removing those boundaries where they aren't needed. By understanding why these directives appear, you can better navigate the transition from a Vite SPA to a high-performance Next.js application. Further reading: [ViteToNext.AI Documentation](https://vitetonext.codebypaki.online/)