Next.js Is Amazing. So Why Did I Leave?

#webdev #nextjs #javascript

Why I Loved Next.js

Next.js is an amazing framework for building modern web applications. I used it for different projects because it provides routing, server rendering, API capabilities, image optimization, and excellent React integration.

At first, everything felt convenient. A lot of functionality was already built into the framework, so I didn't need to configure everything from scratch.

But after working with it more seriously, I started noticing some things that didn't work well for my development style.

Why I Decided to Leave

1. It Started Feeling Too Complex

My biggest reason was complexity.

As my projects became more advanced, I had to think about Server Components, Client Components, rendering strategies, caching, server actions, and other framework-specific concepts.

These features are powerful, but sometimes I simply wanted to build something without having to think about so many layers.

2. Caching Behavior Was Confusing

Another issue was caching.

Next.js provides powerful caching and rendering features, but understanding exactly when data is cached, revalidated, or rendered again can sometimes be confusing.

I occasionally found myself asking: “Why am I still seeing this old data?”

Instead of focusing on the actual application, I sometimes had to spend time figuring out what Next.js was doing behind the scenes.

3. Too Much Framework Magic

This was probably the most frustrating part for me.

Next.js can automatically handle many things, which sounds great. But sometimes that convenience feels like magic.

When something doesn't behave as expected, I want to clearly understand what is happening underneath. With Next.js, some behavior can feel hidden behind framework conventions.

Does That Mean Next.js Is Bad?

Absolutely not.

I still think Next.js is an excellent framework. It can be a great choice for large applications, content-heavy websites, and projects that benefit from server-side rendering and modern React features.

Leaving it doesn't mean I think Next.js is bad. It simply means I realized that its trade-offs don't always match the way I want to build applications.

Practical Alternatives

If you feel the same way, you don't necessarily need to abandon React. One practical approach is to use React with a simpler build tool when you primarily need a client-side application.

For projects that need server-side rendering but less framework complexity, consider evaluating alternatives such as Astro, Remix, React-Router, Tanstack Start or other React-based frameworks.

Another option is to keep your architecture deliberately simple: use a straightforward API, choose an explicit caching strategy, and avoid adding framework features unless the project actually needs them.

The goal isn't to find a "better Next.js." It's to find a stack where you understand what is happening and can work comfortably with it.

Conclusion

Next.js is amazing, but it isn't perfect for everyone. For me, the combination of complexity, caching behavior, and framework magic eventually became frustrating enough to explore other options.

That doesn't make Next.js a bad framework. It simply taught me an important lesson: the best technology isn't always the one with the most features—it's the one that makes your work easier.