Remix vs Next.js

Beyond this enticing title, the aim is to compare Remix, the soon-to-be-not-so-new framework from the creators of react-router and unpkg, and Next.js, which we've been actively using at the agency for a number of years, from various angles. The idea is to understand the strengths and weaknesses of each in order to determine which types of project can benefit from one or the other.

It may seem obvious, but this whole comparison is based on the current versions of Remix (1.18) and Next.js (13.4). Many aspects will probably continue to evolve over the coming months and make some comparisons totally obsolete, but that's all to the good.

Personally, I don't think there's ever been a better time to be doing JavaScript development than right now; all the solutions and frameworks on offer are excellent (even Angular), and they're all going to offer highly polished results and a great development experience!

Before going any further, it's also important to point out that these two frameworks are built around React.js. Wanting to remain within this ecosystem for the time being, here's why we've chosen to pit Next.js against Remix, and not Nuxt or Sveltkit, which are no less interesting.

Since React is 'just' a library for managing user interfaces, these frameworks provide solutions for managing routes, rendering and server-side logic, and all the tools needed to run, build and deploy our application.

First of all, it's about clearly separating server and client logic. Unlike the early days of Next.js, with its getInitialProps executed sometimes on the server and sometimes in the browser, Remix clearly marks the boundary between server and client by the names of the xyz.client and xyz.server files and by the methods exposed and used by the routes.

Secondly, Remix has a real desire to be as close as possible to web standards. On the one hand to avoid any adoption frictions, but also to be as consistent as possible. This applies to HTML attributes, the use of the Fetch API on the server side and the way forms are managed.

Then there's the question of using JavaScript wisely: improving the user experience. Obviously, the entire language of our Remix application is in JavaScript (TypeScript ideally), but the JavaScript sent to the web user is intended to be as light and efficient as possible. And unlike Next.js, Remix gives us the option of disabling React hydration for one or more routes by simply export const handle = { hydrate: false; };.

Finally, Remix favours minimum abstraction. In general, this means keeping the terms as close as possible to the origin, as Next.js is also very good at doing.

Now that we've put its philosophy into perspective, what does Remix offer?

To cut a long story short, Remix is :

Remix offers project "stacks" or templates that include a preconfiguration of :

Router

The first big advantage of using Next.js or Remix is their routers. At the time of writing (July 2023), Next.js has two routers: the Page Router and the App Router. I won't go into detail here, but some comparisons will only be made with one or the other, and sometimes both. Now, the App Router is still relatively new, so it's possible that I'm still missing some of its possibilities.

The important thing to remember is that all these routers, including Remix, are file-based, which means that the tree structure and file names will define the URLs (routes) of our application. Now, apart from a few differences in syntax, Next.js and Remix offer the same naming possibilities for generating dynamic route segments. Note, however, that version 2 of Remix offers the option of setting aside nested directories with a simple . profile in the file name to mark the hierarchy.

When it comes to the anatomy of a route, i.e. the file that will render our final page, the two frameworks work in a fairly similar way: exporting a default method for rendering and other methods to manage specific features. One of the very well thought-out features of Remix is the export of loader methods for executing GET logic on the server side and action methods for executing POST, PUT, etc logic on the server side. Next.js offers something similar with getServerSideProps for GET logic in the Page Router or Server Actions for POST, PUT, etc logic in the App Router.

Remix also offers a CatchBoundary and an ErrorBoundary for interceptions. It's also very easy to redefine the headers, meta and links of a route by exporting them without going through a _document.tsx or layout.tsx, as in Next.js.

Our two frameworks handle the revalidation of a route; Remix with the shouldRevalidate method, which must return a boolean, and Next.js with the revalidate option in the Page Router or the revalidatePath method in the App Router.

Remix like Next.js will offer React components that will simplify the integration of certain mechanics. Both will feature the equivocal Link and Script components. Remix will also offer Await, Form, Links, LiveReload, Meta, NavLink, Outlet, PrefetchPageLinks and ScrollRestoration, but unlike Next.js, no Image component.

Next.js already offers a few hooks, such as useRouter and useParams, but Remix offers six times as many. Many are inherited directly from react-router, such as useParams or useNavigate, and others are unique to Remix, such as useLoaderData or useActionData. What's great about this diversity is how easy it is to use these hooks.

Finally, like Next.js, Remix offers utils for managing things like cookies and redirects. Each has its own subtleties.

You've jumped straight to this chapter, so much the better - here's which framework to choose for your project. In themselves, both offer a very similar approach and functionality, as well as a very good development experience.

The first decisive point is the ability to perform Static Site Generation (SSG), which Next.js is capable of doing with its Page Router. It enables pages to be pre-generated and revalidated (rebuilt) on demand. Remix is not positioned in this way; rather than generating pages, it encourages you to rely on the performance of distributed systems. Now, if you want to make a showcase site or a blog with SSG, Remix isn't for you (unlike Astro 🤫).

With that in mind, it's easy to see why Remix is aimed at more application-oriented projects in the same way as Next.js' App Router.

Apart from that, the second and final determining factor will lie in personal preference between the philosophy, syntax and subtleties of Remix or Next.js. Get your hands dirty and choose the one that speaks to you most for developing your application. Either way, you're not going to make a bad choice!