Remix vs Next.js in 2026: I Tried Both for My Portfolio — Here's My Honest Take

Look, I wasn't planning on forming a strong opinion about this.

I'm a full stack dev based out of Hyderabad, and like most of you reading this, I've spent more hours than I'd like to admit reading framework comparisons that all say the same things. "Next.js is great for SEO." "Remix has better data loading." "Both are fine, just pick one." Cool. Very helpful.

So instead of regurgitating docs at you, I want to tell you what actually happened when I built two real projects — this portfolio (anuragnandi.com) with Remix, and bigbearsoftware.com with Next.js. Two different codebases, two different use cases, and two very different vibes while building them.

Here's my honest take.

Why I Even Tried Both

When I was building my portfolio from scratch, I was choosing between Next.js (which I already knew) and Remix (which I'd been curious about for a while). At the time, Remix had just hit v2 and the hype was real. I figured — if not now, when? Portfolio is a low-stakes place to experiment.

For bigbearsoftware.com (a software agency site), I went with Next.js because it was familiar, the team expected it, and frankly there's a certain comfort in knowing you can Google any problem and find 47 answers. That's not a knock — that's pragmatism.

Both are in production. Both work. But they feel very different to build with.

What Remix Gets Right (And Why I Chose It for My Portfolio)

Building this site with Remix + Mantine was genuinely one of the more enjoyable dev experiences I've had recently. And I don't say that lightly.

Data Loading That Actually Makes Sense

Remix's loader pattern clicked for me immediately. Every route can export a loader function that runs on the server, and your component just uses useLoaderData(). That's it. No getServerSideProps, no getStaticProps, no API route dance.

// routes/projects.tsx
export async function loader() {
  const projects = await getProjects();
  return json({ projects });
}

export default function Projects() {
  const { projects } = useLoaderData<typeof loader>();
  return <ProjectGrid projects={projects} />;
}

For a portfolio where I'm pulling projects from a CMS, this felt natural. The data and the UI live in the same file, close together. Less jumping around.

You can see the result on my projects page — it's fast, server-rendered, and the code behind it is embarrassingly simple.

Nested Routing is a Game Changer

Remix's nested routes are something I didn't realize I wanted until I had them. Layouts compose naturally, errors bubble up correctly, and loading states can be scoped to just the part of the UI that's actually loading. Once you get it, it's hard to go back.

Forms Are a First-Class Citizen

Remix treats HTML forms seriously. <Form> + action functions handle mutations without touching client state in most cases. It's almost too old-school to be modern, but it works beautifully. For things like a contact form on my about page, this was way less code than I expected.

What Next.js Gets Right (And Why BigBear Still Uses It)

I'm not here to trash Next.js. It's a rock-solid framework and for bigbearsoftware.com, it was absolutely the right call.

The Ecosystem Is Unbeatable

Need auth? There's next-auth. Need i18n? Built in. Need image optimization? next/image. Need ISR? Few lines of config. The Next.js ecosystem is rich, battle-tested, and the Vercel integration is genuinely seamless. For a business site where you want things to just work, this matters a lot.

App Router (When It Works) Is Powerful

The App Router with React Server Components is ambitious and, in 2026, it's finally gotten solid enough to trust. Co-locating server and client components is powerful once you wrap your head around it. For BigBear, where we needed granular control over what's server-rendered vs interactive, it paid off.

Less Cognitive Load for Team Projects

When I'm the only dev, I can hold all the Remix mental model in my head. On a team, Next.js wins because the conventions are everywhere. New dev joins? They've probably used Next.js. That's worth something.

Where They Both Have Pain Points

Remix:

Error handling is great in theory, but debugging nested route errors can get confusing fast
The community is smaller — when you hit a weird edge case, you're more likely to be writing the Stack Overflow answer than reading one
Documentation is good but could be more example-heavy for some edge cases
Deployment outside of Vercel/Fly.io takes a bit more setup

Next.js:

App Router vs Pages Router is still a split that confuses new devs and clutters search results
Server Components mental model has a learning curve that trips people up
Next.js docs are excellent but dense — sometimes it feels like reading a legal document
Vendor lock-in to Vercel is real if you lean too heavily on their platform features

Routing: A Direct Comparison

This is where they diverge most noticeably.

Remix → Next.js (App Router)

File convention → routes/path.tsx → app/path/page.tsx

Nested layouts → Built-in, explicit → layout.tsx files

Dynamic routes → $param → [param]

Error boundaries → Per-route ErrorBoundary → error.tsx

Loading UI → defer + <Suspense> → loading.tsx

Remix's routing feels like a deliberate design. Next.js App Router feels like it evolved over time — powerful, but occasionally awkward.

Deployment

Both deploy easily to Vercel. But here's the thing:

Remix gives you more flexibility out of the box. It runs on Express, Cloudflare Workers, Deno, Fly.io — whatever you want. I deploy this portfolio on Fly.io and it's been smooth.
Next.js is technically portable too, but the best experience is still on Vercel. Self-hosting works, but you lose some of the magic (ISR edge cases, image optimization details, etc.).

If you're locked into a specific cloud or want to keep infrastructure costs low, Remix's flexibility is a genuine advantage.

Which One Would I Pick Today?

Honestly? It depends, but I reach for Remix first when it's my call.

For personal projects, portfolios, and apps where I control the stack — Remix. The data loading model is cleaner, nested routing is elegant, and it keeps me closer to the web platform fundamentals. I like that writing a Remix app teaches you more about how the web works, not just how the framework works.

For team projects, client work, or anything where "just works" matters more than "beautifully designed" — Next.js. The ecosystem, the community, and the Vercel integration are hard to argue with. I used it for bigbearsoftware.com and I'd do it again.

The "pick one and stick with it" crowd is going to hate this answer, but that's the truth.

Wrapping Up

If you're a dev choosing between these two in 2026, stop looking for the objectively correct answer. There isn't one. Both are excellent. Both are actively maintained. Both will get you where you need to go.

What I can tell you is: Remix made building this portfolio feel fun, and that matters more than I expected it to. When you actually enjoy your own stack, you ship more, you care more, and the end result shows it.

Check out what I've built on my projects page if you want to see Remix in action — and if you're curious about the stack details or want to talk shop, hit me up on the about page.

Now go build something.

— Anurag

If this post helped you, share it with a fellow dev who's stuck in analysis paralysis. They'll thank you.