You don’t need to know every JavaScript framework to ship great products.
But for most of my projects, I keep coming back to Next.js.
It’s not hype. It’s a mix of flexibility, developer experience, and built-in performance wins that make it a solid choice for both small and large projects.
Here’s my story and what I’ve learned along the way.
How I First Met Next.js, Like most frontend devs, I started with plain React. I loved the component model, but I quickly ran into the same problems:
SEO challenges with SPAs
Too much setup for routing and performance optimization
Having to choose between server-side rendering and static generation, with no simple middle ground
Next.js came in like a toolkit that already had answers for most of these problems.
Why I Keep Choosing It
1. SSR + SSG Flexibility
Next.js lets me choose rendering strategies per page. I can make one route statically generated for speed, and another server-rendered for up-to-date data, all in the same project.
2. Performance Built In
Image optimization, smart routing, and lazy loading happen almost automatically. Less time on micro-optimizations, more time on core features.
3. Developer Experience
File-based routing, built-in API routes, TypeScript support, I spend less time wiring things together and more time building.
4. Ecosystem Fit
It works seamlessly with Tailwind CSS, Framer Motion, and my usual backend stack (Node.js, MongoDB, Firebase).
5. Multitenancy Support
One of my recent projects required multi-tenant architecture, different clients having their own custom subdomains, data isolation, and branding, all within a single codebase.
Next.js made it straightforward to handle dynamic routing and domain mapping, which saved weeks of manual work.
Lessons Learned Along the Way
No tool is perfect; I’ve had to manage longer build times on large projects.
The temptation to over-engineer is real, sometimes a plain React app is enough.
For me, Next.js isn’t just a tool; it’s a balance between performance, flexibility, and developer happiness.
Have you tried Next.js? What’s the biggest lesson it taught you, or the biggest pain point you’ve had with it?
Top comments (6)
Great insights! I love how Next.js lets you mix SSR and SSG in one project—it really adds flexibility. The built-in performance features save so much time. Also, handling multitenancy with Next.js sounds like a huge plus! I agree, build times can get long, but overall it’s my favorite React framework. Have you tried the new app directory yet?
You really need to try out multi tenancy in NextJs, I think I should write an article on it.
Yes, I’m currently using the app directory and its like the power house that delivers NextJS full functionality.
Multi-tenancy in Next.js is definitely a hot topic right now, especially with the app directory unlocking so much power. I’d be really interested to see your take on it — particularly any patterns or gotchas you’ve run into while building it.
Yeah, I just published an article on it. The major issue I had was the inability to make the Multi-tenant routing deep level. Like you will want to have routes like
tenat1.app.com/dashboard/level1/level2to point toapp.com/tenat1/dashboard/level1/level2in the NextJs file system, my article covers how I found a way around this, too.I also switched to Next.js recently. Very informative to use its full capabilities.
What do you think about NextAuth and its integration with Firebase? Is it worth the my time or should I just write my own auth?
Thank you, Diana.
You can integrate them, but it’s not always straightforward. Firebase handles identity, while NextAuth handles session management. Combining them can add complexity.
If your app relies heavily on Firebase’s Realtime Database or Firestore rules (tied to Firebase Auth), just use Firebase Auth directly. It supports email/password, Google sign-in, and more without extra layers.
If you want full control over flows, token lifetimes, and sessions, you can roll your own with the Firebase Admin SDK.