Journey into RemixJS: A Comparative Exploration with NextJS

This website you're reading was originally built with NextJS 13.5, then upgraded to 14. Then I rebuilt the whole thing in RemixJS. Same components. Same features. Different framework. The comparison was eye-opening.

Build Time

Remix builds my site in about one minute. For the same set of components and pages. Build time matters — especially when you're deploying frequently or running CI on every push.

Performance

I deployed both versions through fly.io and ran them through GTMetrix with zero optimization on either side.

NextJS scored a B rating. The browser loaded 366KB of JavaScript. That's respectable for zero optimization effort.

Remix scored slightly lower on raw performance metrics — but here's the key difference. NextJS automatically extends fetch to cache responses behind the scenes. That caching improves performance numbers but also means your UI might serve stale data without you realizing it.

Remix doesn't do this. You control caching explicitly. I prefer that.

The JavaScript payload with Remix was around 210KB — significantly smaller.

Page Transitions

Both frameworks showed roughly 3-second page transitions. Comparable performance here.

Remix maintained that 3-second transition even without the implicit fetch caching NextJS provides. That tells me Remix's architecture is efficient on its own terms.

Developer Experience

This is where Remix pulled ahead for me.

Routing clarity: Remix routes are flat files with clear naming. Files are longer, but the structure is readable. NextJS requires navigating nested folders with multiple files per route — layouts, pages, loading states, error boundaries. More files, more mental overhead.

Customization: Remix lets you swap out the routing system entirely. Don't like the default convention? Change it. That respect for developer autonomy matters on long-lived projects.

The Opinionation Problem

NextJS is becoming more opinionated with each version. That's not inherently bad — Ember was opinionated and powerful. But Ember's steep learning curve and locked-in patterns limited its adoption over time.

I see a similar pattern forming. The more conventions NextJS adds, the more you're learning NextJS-specific concepts rather than transferable web skills.

Remix leans the other direction. It builds on web standards — HTML forms, HTTP semantics, standard request/response. The skills you learn in Remix transfer directly to any web platform.

My Verdict

I migrated gazar.dev to Remix and haven't looked back. The build is faster. The bundle is smaller. The code is more readable. And the framework respects my decisions instead of making them for me.

When to choose Remix: You want explicit control, smaller bundles, and web-standards alignment. Your team values understanding over convention.

When to choose NextJS: You want a larger ecosystem, Vercel's deployment story, and you're comfortable with the convention-heavy approach. Server Components are genuinely innovative and worth considering.

Both are good frameworks. The right choice depends on what trade-offs you're willing to make.