10 Mistakes I Made While Learning Next.js – So You Don’t Have To

Introduction: The Day I Met Next.js (and Got Intimidated) I still remember the day I heard about Next.js for the first time. It was during a casual team call. One of the senior devs casually said, "For this new feature, we’re moving from CRA to Next.js." At that time, I was pretty confident with React. I’d built a few decent apps, knew how useState and useEffect worked, and thought I had a grip on frontend development. So naturally, I assumed learning Next.js would be like switching from a bike to a scooter—same balance, just faster. I was wrong. It was more like switching from a bike to a spaceship... without reading the manual. Next.js came with its own way of doing things—file-based routing, server-side rendering, image optimization, API routes... Honestly, it felt like React on steroids, and I wasn’t ready for it. So I did what many devs do: I winged it. And in the process, I made some dumb mistakes that cost me hours (sometimes days), caused frustration, and made me question if I was even a “real” developer. But the truth is—mistakes teach you faster than success ever can.So here’s me laying it all out—not as a tutorial, but as a friend who's been through the mess and came out a little wiser. Mistake #1: Treating Next.js Like Plain React When I started my first Next.js project, I didn’t bother reading the docs. I just jumped in and created components like I did in any other React app. It looked something like this: function Home() { return Welcome to my app } export default Home Felt good. Familiar. Simple. I was like—"Okay, this is React. I got this." But as soon as I needed routing, I reached for react-router-dom out of habit. When I needed to fetch data, I used useEffect. When I wanted to build an API, I set up a separate Express server. Basically, I ignored everything that made Next.js... Next.js. And because of that, I was adding complexity where Next.js was trying to simplify it. It took me a while to understand that Next.js isn’t just a React framework—it's a different way of thinking. You don’t need react-router. You don’t need a separate backend. You don’t need to fetch everything client-side. Next.js gives you all of that, but only if you stop treating it like Create React App in disguise. Mistake #2: Ignoring File-Based Routing The first time I saw this in a tutorial: /pages/about.js → route: /about /pages/blog/[slug].js → dynamic route: /blog/my-first-post I thought it was cute. Then I ignored it. "How hard can routing be? I’ll just make components and link them manually," I told myself. So I created a components folder, dropped files in there, and tried to manage routing myself. I even tried nesting folders in weird ways just to make things “organized.” But it quickly became chaos. Some links worked, some didn’t. Dynamic routes became an unpredictable mess. SEO? Broken. Deep linking? Forget it. I spent more time debugging my routing than building features. All because I refused to accept how elegant and powerful file-based routing actually is. Once I embraced it, life got easier. Now, if I need a new page? I just create a file in /pages. If I need a dynamic blog post? I use [slug].js and export getStaticPaths. It’s simple. Clean. And it works—without installing anything extra. ⚠️ Mistake #3: Not Learning SSR/SSG at the Start When I first saw the terms getServerSideProps and getStaticProps, I thought—“Ah, that’s advanced stuff. I’ll deal with that later.” Big mistake. I was working on a blog project. Simple idea: fetch content from a CMS and display it. Naturally, I did what I was used to—set up a useEffect, fetched the content from the client side, and rendered it once the data came in. It worked. At least, in dev mode. But then two things hit me: The content wasn’t showing up immediately on slower connections. Users saw a blank screen for a moment before the data appeared. Google couldn’t crawl my blog posts properly. The SEO was practically nonexistent. My blog wasn’t showing up anywhere. That’s when I realized—I had misunderstood one of the most important powers of Next.js: Server-Side Rendering (SSR) and Static Site Generation (SSG). Here's what I learned—after stumbling: getStaticProps is for static generation. It fetches data at build time. Perfect for blogs, portfolios, or anything that doesn't change every minute. getServerSideProps is for server-side rendering. It runs every time the user visits the page. Great for dashboards, user profiles, or dynamic content. I wish I’d taken the time early on to really understand these rendering methods. Because once I did, everything clicked. My pages loaded faster. My SEO improved. And I finally felt like I was building in sync with what Next.js is actually meant to do.

Apr 10, 2025 - 08:41

10 Mistakes I Made While Learning Next.js – So You Don’t Have To

Introduction: The Day I Met Next.js (and Got Intimidated)

I still remember the day I heard about Next.js for the first time.

It was during a casual team call. One of the senior devs casually said,

"For this new feature, we’re moving from CRA to Next.js."

At that time, I was pretty confident with React. I’d built a few decent apps, knew how useState and useEffect worked, and thought I had a grip on frontend development. So naturally, I assumed learning Next.js would be like switching from a bike to a scooter—same balance, just faster.

I was wrong. It was more like switching from a bike to a spaceship... without reading the manual.

Next.js came with its own way of doing things—file-based routing, server-side rendering, image optimization, API routes... Honestly, it felt like React on steroids, and I wasn’t ready for it.

So I did what many devs do: I winged it. And in the process, I made some dumb mistakes that cost me hours (sometimes days), caused frustration, and made me question if I was even a “real” developer.

But the truth is—mistakes teach you faster than success ever can.So here’s me laying it all out—not as a tutorial, but as a friend who's been through the mess and came out a little wiser.

Mistake #1: Treating Next.js Like Plain React

When I started my first Next.js project, I didn’t bother reading the docs. I just jumped in and created components like I did in any other React app.

It looked something like this:

function Home() {
  return <div>Welcome to my appdiv>
}
export default Home

Felt good. Familiar. Simple. I was like—"Okay, this is React. I got this."

But as soon as I needed routing, I reached for react-router-dom out of habit.

When I needed to fetch data, I used useEffect.

When I wanted to build an API, I set up a separate Express server.

Basically, I ignored everything that made Next.js... Next.js.

And because of that, I was adding complexity where Next.js was trying to simplify it.

It took me a while to understand that Next.js isn’t just a React framework—it's a different way of thinking. You don’t need react-router. You don’t need a separate backend. You don’t need to fetch everything client-side.

Next.js gives you all of that, but only if you stop treating it like Create React App in disguise.

Mistake #2: Ignoring File-Based Routing

The first time I saw this in a tutorial:

/pages/about.js → route: /about
/pages/blog/[slug].js → dynamic route: /blog/my-first-post

I thought it was cute. Then I ignored it.

"How hard can routing be? I’ll just make components and link them manually," I told myself.

So I created a components folder, dropped files in there, and tried to manage routing myself. I even tried nesting folders in weird ways just to make things “organized.”

But it quickly became chaos.

Some links worked, some didn’t.
Dynamic routes became an unpredictable mess.
SEO? Broken.
Deep linking? Forget it.

I spent more time debugging my routing than building features. All because I refused to accept how elegant and powerful file-based routing actually is.

Once I embraced it, life got easier.

Now, if I need a new page? I just create a file in /pages.

If I need a dynamic blog post? I use [slug].js and export getStaticPaths.

It’s simple. Clean. And it works—without installing anything extra.

⚠️ Mistake #3: Not Learning SSR/SSG at the Start

When I first saw the terms getServerSideProps and getStaticProps, I thought—“Ah, that’s advanced stuff. I’ll deal with that later.”

Big mistake.

I was working on a blog project. Simple idea: fetch content from a CMS and display it. Naturally, I did what I was used to—set up a useEffect, fetched the content from the client side, and rendered it once the data came in.

It worked. At least, in dev mode.

But then two things hit me:

The content wasn’t showing up immediately on slower connections.
- Users saw a blank screen for a moment before the data appeared.
Google couldn’t crawl my blog posts properly.
- The SEO was practically nonexistent. My blog wasn’t showing up anywhere.

That’s when I realized—I had misunderstood one of the most important powers of Next.js: Server-Side Rendering (SSR) and Static Site Generation (SSG).

Here's what I learned—after stumbling:

getStaticProps is for static generation. It fetches data at build time. Perfect for blogs, portfolios, or anything that doesn't change every minute.
getServerSideProps is for server-side rendering. It runs every time the user visits the page. Great for dashboards, user profiles, or dynamic content.

I wish I’d taken the time early on to really understand these rendering methods. Because once I did, everything clicked.

My pages loaded faster. My SEO improved. And I finally felt like I was building in sync with what Next.js is actually meant to do.