From React Basics to Shipping With Next.js: My Actual Learning Curve

I picked up React the way a lot of people do: a YouTube tutorial, a to-do list app, and the quiet confidence that I "got it" because the counter button worked. I didn't, not really. That came later, once I started building things nobody was grading.

In college our frontend exposure was mostly vanilla JavaScript and jQuery, with React showing up as an elective topic near the end, if at all. So most of what I know about React and Next.js I picked up outside the classroom, by breaking things on my own projects and figuring out why.

The part that actually took time: thinking in components

The hardest adjustment wasn't JSX syntax, it was learning to stop thinking in terms of "update this part of the page" and start thinking in terms of "what does this UI look like for this piece of state." Every bug I hit in my first few weeks traced back to me still thinking like I was manipulating the DOM by hand.

A few things that took real repetition before they clicked:

• Props flow one direction, down. If a child needs to change something in a parent, you pass a function down, you don't reach up.
• useEffect isn't a lifecycle method with a nice name, it's "run this again whenever any of these values change." I caused more than one infinite loop before that sank in.
• State belongs as close to where it's used as possible, and only gets lifted up once two components actually need to share it.

Why I moved to Next.js instead of staying with plain React

Plain React with Vite was fine for practice projects, but every real idea I had needed routing, decent SEO, and some way to talk to a database without duct-taping five libraries together. Next.js's App Router gave me most of that out of the box:

• File-based routing, so the folder structure is the routing table
• Server Components by default, which meant I could fetch straight from the database in a page and skip writing a separate API layer for things that didn't need one
• Built-in image optimization and metadata handling, which used to be its own rabbit hole

Rebuilding my portfolio site on Next.js with a real Postgres database behind it (Neon, in this case) is what finally made the difference between "I know React" and "I can ship something with it." Reading from a server component, handling a contact form through a server action, wiring up admin auth, none of that comes up in a tutorial, but it's most of what real projects are made of.

What I'd tell myself at the start

Stop building the fifth to-do list app. Pick something with an actual database, actual forms, and actual deployment, even if it's small and a little ugly. That's where the React mental model and the Next.js conventions both stop being abstract and start being muscle memory.

I'm still learning. Server Actions, caching behavior, and when to reach for client state versus letting the server own it are all things I'm sharper on now than six months ago, and I'd bet the same will be true six months from now.