Many frameworks have been built on top of React, but Next.js and Remix are two of the best ones. Next.js represents a more mature solution, while Remix is emerging as its alternative. This means that Remix may become more than just a viable option. Knowing the main differences they have is critical to pick one over the other, therefore, a Next.js vs Remix comparison is necessary.
So, let’s compare them and learn which one fits your needs best.
The company was recently valued at $2.5 billion and was able to raise $150 million.
Remix has recently been able to raise $3 million.
If you don't want to read the whole article and just want to get started, you can install our Remix example on your DatoCMS account right away, by clicking on the button. This action will
Clone a GitHub repo containing the Remix blog template.
Copy the DatoCMS template project to your DatoCMS account.
Deploy the blog on Vercel or Netlify.
Let’s now delve into the top 5 differences the two frameworks have from the technical and conceptual standpoint. It is time to understand their two different approaches to building a website.
Both Next.js and Remix support a file-system-based routing. When it comes to dynamic routes, the main difference between the two frameworks is that Next.js uses  to specify a route involving a parameter.
pages/login.js or pages/login/index.js
And this is how to achieve the same result in Remix:
app/routes/login.js or app/routes/login/index.js
But the real main difference is that Next.js uses a custom library for routing, while Remix is built on top of React Router v6.
This means that Remix natively supports all the features coming with React Router. Particularly, Remix allows nested routing with nested layouts. As explained in the official documentation, this represents “a concept in Remix that is critical to understand”. Getting into it may not be that easy, so following this link is recommended.
Such a feature allows going beyond the 1:1 mapping between a page component and a URL. In fact, In Remix a single URL can correspond to multiple, nested routes, giving Remix a fine-grained control over data, style, and module loading.
This is because since all the routes are known upfront, Remix can match them before rendering anything. So, when the location changes, it can fetch the data, styles, and modules required in parallel. This allows Remix to fetch only what is needed to change the portion of the current page that needs to change, rather than rebuild the page from scratch. That would be impossible without nested routes.
In addition, Remix allows you to define custom routes, that are merged to the routes already defined using the aforementioned file-system-based convention. Use them as described here. This feature is particularly useful when dealing with internationalization routing when route names have to change based on the selected language.
Next.js comes with the following four different page rendering strategies:
In contrast, Remix only supports SSR. This means that Remix cannot statically generate your pages. Thus, SSG and ISR are forbidden in Remix. The reason is that Remix is based on traditional Internet standards, such as CDNs and browser caching.
To address this, Remix provides you with full control over the data returned for a route, including the cache-control headers. As a result, by setting a very high value for the Cache-Control HTTP header and leveraging the browser caching system, you can achieve something similar to SSG. Plus, by using a CDN (Content Delivery Network) and a stale-while-revalidate strategy, it is even possible to achieve the ISR behavior. But what is sure is that achieving the desired page rendering behavior involves manual tweaks and can take more time than in Next.js.
When making a Next.js vs Remix comparison, we need to talk about built-in mechanisms for fetching data. Specifically, Next.js comes with the following two functions:
getStaticProps(): the data retrieved inside here will be used to pre-render the page at build time
getServerSideProps(): the data retrieved inside here will be used to render the page every time a request is received
So, each Next.js page should implement one of these two functions. Then, the objects returned by these two functions will be passed to the page component as props.
Similarly, Remix data fetching depends on the page rendering strategy. In particular, Remix support one function:
loader(): the data retrieved inside here will be passed to the route by the server before rendering the page
So, each route has to implement this loader() function. In this case, the object returned by this function it will not be accessible from the props, but thanks to the built-in
useLoaderData() hook. This takes care of making accessible the JSON parsed data returned by your route loader() function implementation to the page component.
Keep in mind that in both frameworks, these functions are called server-side. Consequently, they can be used to call external APIs, connect to a database and perform queries, or read data from the files.
Also, Remix is not built on top of Node.js, which means that it can be deployed in several deployment providers natively. On the contrary, Next.js can only be deployed to providers supporting a Node.js. Thus, with Remix you are more in control.
Remix is a much younger project compared to Next.js. This means that it falls short on many extra features. Also, the documentation is still under construction, and encountering “To-do”s is not that uncommon.
On the contrary, Next.js is a mature project. Not only does its documentation is highly detailed, but since Next.js 10 many advanced features have been added. For example, you learn more about Next’s image optimization in our blog post here. Similarly, we covered Next’s internationalized routing here.
Let's go to the core Next.js vs Remix question. Which one should I use?
Thanks for reading! We hope that you found this article helpful. Feel free to reach out to us on Twitter with any questions, comments, or suggestions.