I started using Next.js in early 2021. It quickly became my favorite framework. I liked it so much that I started using it for almost every project, even when I probably didn't need it.
But after a few years with Next.js, my perspective has changed. I still think it's a great framework, but now I don't default to it for every React app.
How I Started Using Next.js
When I first tried Next.js, I was really impressed by how easy it was to build and deploy apps. Platforms like Vercel and Netlify made deployment very simple. Next.js also has great features like Server-Side Rendering (SSR), Incremental Static Regeneration (ISR), and SEO-friendly tools.
Because of these advantages, I started picking Next.js for almost every project, even for internal dashboards and apps where SEO didn't matter.
In the year 2021, I started my own eCommerce business. At the time, I had only 1 year of Software Development experience. I needed to build my own website. So I looked for cutting-edge technology that would be the best choice for my website. Also, since it was an eCommerce website, it needed strong SEO. After researching online, I found Next.js. I learned Next.js and built my own eCommerce website. I used that website for more than a year, and it performed really well.
What Changed My Perspective?
But after working on more projects, I noticed that some of the features I liked in Next.js were not always useful for every app. Two things mainly changed my mind: deployment complexity and whether server-side rendering really helps dashboards.
1. Self-Hosting Next.js Can Require More Work
We can self-host Next.js, no problem. But in my experience, deploying it outside platforms like Vercel or Netlify often requires additional configuration.
Depending on the application, maintaining that setup can also become more complicated than deploying a regular React application.
I've explored several options for hosting Next.js applications. Recently, I became interested in Cloudflare Workers and decided to try it. Cloudflare supports Next.js through solutions like OpenNext and vinext, but setting everything up for my existing application was more complicated than I expected. I didn't particularly enjoy the experience and eventually moved back to Netlify.
There are other options, too. For example, Railway can host a Next.js application using a Node.js server. But depending on how we deploy and scale the application, we may still need to manage things like caching, reverse proxies, and other infrastructure configurations.
On the other hand, deploying a React application built with Vite is usually much simpler. We can generate a static build and host it almost anywhere that supports static files, without needing a Node.js server to run the frontend.
2. Not Every Dashboard Needs Next.js
Next.js has great server-side rendering. But not every application needs it. For example, consider a dashboard that needs authentication and shows a lot of API data.
Most of the app depends on client-side interactions, user data, filters, tables, and other dynamic parts. In these cases, server-side rendering might not offer enough benefits to justify the added complexity.
That doesn't mean Next.js is a bad choice for dashboards. Features like Server Components and server-side data fetching can still be useful. But now I don't pick Next.js just because it has those features.
For a fintech dashboard project, I previously used Next JS. For that particular project, Next. js was really a bad choice. The app didn't need any SEO support, and it didn't need any SSR or other Next. js features. It was mainly a data-heavy application with extensive filtering and searching. So using Next. js was really a bad choice for the app. We also used a lot of unnecessary Next.js API features that weren't needed for that project.
I also used Next. js for a dealership dashboard at Carexpert. From my understanding, Next. js was relevant for that particular application. Because we used some of the features, like Next. js API routes, js API, we could handle complex account management. We also made sure the app is secure; those Next.js features keep no credentials on the client side. Also, since many dealers used the application, caching was important for that dashboard.
Why I Now Consider React + Vite for Dashboards
For a typical data-heavy dashboard, I would seriously consider building the frontend with React and Vite. One benefit is that you can build the frontend as static files and host it separately from the backend. If the app already uses a separate API, this setup is usually easier to deploy and maintain.
Deploying React is almost the same as deploying Next.js on Vercel or Netlify. Otherwise, we can deploy the React application using the static build. If we want to deploy it on AWS, we can upload the static build to S3 and serve it through CloudFront.
One disadvantage of using React instead of Next.js is that Next.js is a full-stack framework. So it supports both the front end and the back end. For a smaller project or MVP, this can be really helpful. Especially if we want to build it quickly. But with React, we need a separate back end.
Today, services like Supabase and Neon let us avoid this issue. With those, we can add backend functionality directly in React. That's also a good option for a smaller application. For complex or large applications, a separate backend is the way to go.
What About the Backend? Why I Like Go
If I were building a new data-heavy dashboard today, I'd seriously consider Go for the backend. In my opinion, Go is really underrated.
It's easy to deploy as a compiled binary, works really well for many backend tasks, and in my experience, uses fewer resources. Keeping the frontend and backend separate also lets me choose the backend technology that fits the app.
That could be Go, Node.js, or something else.
I have built the Fertilizer Shop application for my Father's business. Initially, I built it with Next.js, then converted it to React + Go. And the performance improvement is amazing. Here is the link to the demo of that actual project.
When I Still Prefer Next.js
Even with these limitations, Next.js is still one of my favorite frameworks. For SEO-focused apps like portfolios, blogs, and content-heavy sites, it's usually a great choice.
I also think Next.js is the best choice for e-commerce apps, where server rendering, caching, and performance can really help. And even for dashboards, sometimes I would still pick Next.js.
The main thing is to understand what the app really needs.
How I Choose Between Next.js and React + Vite Today
Now, I don't automatically start a new React project with Next.js.
Instead, I think about a few things:
- Does the application need SEO or server-rendered content?
- Is it primarily an authenticated dashboard?
- Will the frontend and backend be deployed separately?
- How important is keeping deployment simple?
- Do Next.js features provide enough value to make it worth using?
Final Thoughts
Next.js is still a great framework, and I will keep using it. But after a few years, I realized that more features don't always make it the best choice for every project. For SEO-focused apps, Next.js is still one of my first choices. For a typical data-heavy dashboard, I would seriously consider React + Vite with a separate backend.