# app vs web in nextjs
Picked up nextjs on a Friday. By Sunday, I had something running in production. Here's my actual learning path. I started with the Pages Router (the "web" approach), then hit a wall on a complex dashboard for an Abu Dhabi client. That's when I truly understood the "app" paradigm shift.
Why This Matters (and Why I Care)
Honestly, it's not just about routing. It's a fundamental architectural shift. The Pages Router ("web") is your familiar, file-based, client-side heavy approach. The App Router ("app") is Next.js's modern, server-first vision built on React Server Components. At Beyin Digital, we care because the App Router can cut initial load times significantly for content-heavy sites—a real win for our UAE-based e-commerce clients. I resisted at first, but the performance gains are real.
The Basics You Actually Need
The core difference is in the mental model and the `app/` vs `pages/` directory. The App Router uses server components by default and colocates files like `layout.tsx`, `page.tsx`, and `loading.tsx`.
// App Router (app/dashboard/page.tsx) - Server Component by default
export default async function DashboardPage() {
// Fetch data directly on the server. No useEffect needed.
const data = await fetchData();
return <div>Server-rendered: {data}</div>;
}
// Pages Router (pages/dashboard.tsx) - Client Component by default
import { useEffect, useState } from 'react';
export default function DashboardPage() {
const [data, setData] = useState(null);
// Typically need client-side fetch or getServerSideProps
useEffect(() => { fetchData().then(setData); }, []);
return <div>Client-rendered: {data}</div>;
}
How I Build With It (Step by Step)
I now start all new projects with the App Router. First, I run `npx create-next-app@latest` and select "Yes" for App Router. My `app/` structure defines the experience: `app/layout.tsx` for the root shell, and nested folders create routes. The magic is in `loading.tsx` and `error.tsx` files—they automatically wrap your page. For data, I fetch directly in my server component. If I need interactivity, I add `'use client'` at the top to create a client boundary. This hybrid model is where it shines.
Mistakes I Made (So You Don't Have To)
1. **Trying to use `useState` in a Server Component:** Forgot the `'use client'` directive. The error messages are good now—they'll tell you.
2. **Overusing Client Components:** I initially made everything a client component, losing the server-side rendering benefit. Start server, opt-in to client.
3. **Ignoring the `layout.tsx` pattern:** I duplicated header/footer code. The App Router's nested layouts are its killer feature for shared UI.
Advanced Tips From Production
1. Use `generateStaticParams` for dynamic SSG in the App Router—it's more flexible than the old `getStaticPaths`.
2. For authenticated apps, lean on Middleware in the root to protect routes. It works seamlessly with both routers, but the App Router's server components make auth checks cleaner.
My Honest Take
For greenfield projects, use the App Router. It's the future. The learning curve is worth it for the performance and developer experience (nested layouts alone are a game-changer). For maintaining large existing "pages" projects, migrate incrementally. You can run both routers side-by-side, which is what we did at Beyin for a legacy project. The "app vs web in nextjs" debate is really about embracing a server-first mindset.
---
*Mohamed Qurashi | Full-Stack Developer at Beyin Digital | [https://qurashi.dev](https://qurashi.dev)*
---
**Further reading:**
**Related articles on this blog:**