Evaluating Server-Side Rendering with Next.js vs Remix

This experiment was prompted by a client-specific challenge: generating dynamic thumbnails for the ChangeEngine project, where SSR would provide performance and SEO advantages. On a broader level, the sunsetting of Create React App nudged us to explore modern alternatives that align with our technical direction.

Our key goal was to determine which framework—Next.js or Remix—would be the best fit for our team moving forward, particularly for projects that require SSR. We hoped to find a solution that would be easy to integrate, performant, and provide long-term value.

What did we do?

To evaluate each framework in a real-world context, we rebuilt the Script Sage project using both Next.js and Remix. This allowed us to directly compare their developer experience, integration smoothness, and performance.

We kept the tech stack lean, using only the two frameworks without additional libraries or tooling, to ensure a focused comparison. Our documentation captured pros, cons, and pain points for each.

Challenges

While working with Remix, we encountered unexpected friction—particularly around integration with our existing pnpm setup. This led to slower development and increased complexity. By contrast, Next.js offered a smoother and more intuitive development experience from the start.

What did we learn?

What worked well
Next.js proved to be the stronger of the two frameworks for our needs. It was easy to set up, worked seamlessly with our existing stack, and provided robust support for SSR out of the box.

What didn’t work
Remix, while promising on paper, posed challenges with integration—especially with pnpm. This slowed down development and made it harder to recommend as a go-to option.

Surprises?
No major surprises. The results aligned with our expectations as we progressed through the builds.

What’s next?

Given the positive experience with Next.js, we’re leaning toward adopting it as our default front-end framework for SSR-based projects moving forward. The experiment gave us confidence in Next.js as a reliable, scalable choice—no follow-up testing is necessary at this point.