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.
What is Next?
Next.js is an open-source JavaScript framework built on top of Node.js and developed by the Vercel team. It was born in 2016 with the goal of enabling server-side rendering in web applications developed in React. It is now one of the most used JavaScript frameworks, and its goal is to make the web faster.
The company was recently valued at $2.5 billion and was able to raise $150 million.
What is Remix?
Remix is an open-source JavaScript framework developed by the maintainers of React Router.
Remix is built on top of standard Web APIs and does not depend on Node.js dependencies. It was announced in April 2020 but became fully open-source only in November 2021. Its goal is to help people build amazing experiences on the web, and it was one of the most trending JavaScript frameworks in 2021.
Remix has recently been able to raise $3 million.
Get started with Remix now
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.
Remix vs Next.js Comparison
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.
1. Routing
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.
On the contrary, Remix adopts the $ character as a prefix in route names. So, this is how the file-system routing works in Next.js:
https://yourwebsite.com/→pages/index.jshttps://yourwebsite.com/login→pages/login.js or pages/login/index.jshttps://yourwebsite.com/articles/<id>→pages/articles/[id].js
And this is how to achieve the same result in Remix:
https://yourwebsite.com/→app/routes/index.jshttps://yourwebsite.com/login→app/routes/login.js or app/routes/login/index.jshttps://yourwebsite.com/articles/<id>→app/routes/articles/$id.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.
2. Page rendering
Next.js comes with the following four different page rendering strategies:
Client-Side Rendering (CSR): the page is rendered by the browser, just like in any React SPA (Single-Page Application)
Server-Side Rendering (SSR): the page is rendered by the server on the fly and then served to the client
Static-Site Generation (SSG): the page is rendered at build time, only one time
Incremental-Static Regeneration (ISR): the page is rendered at build time, but can be regenerated from time to time
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.
3. Data fetching
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 timegetServerSideProps(): 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.
4. JavaScript and Node.js dependencies
Next.js requires JavaScript to allow the client to communicate with the server after the page gets rendered client-side. In other words, Next.js applications require JavaScript to be enabled browser-side to let users interact with the page and send data to the server. On the contrary, as explained here in the official documentation, in some cases Remix can run also with JavaScript turned off. This is particularly evident by studying how forms work in Remix.
Modern frameworks usually do not support the traditional way of performing a POST request, preferring a custom JavaScript implementation to achieve the same result. On the other hand, Remix is built with standards in mind and supports the browser's native HTML form element. So, it comes with a PHP-style server-side POST requests handler. In other words, Remix’s forms can work without any line of JavaScript. In detail, you can learn here how to deal with the traditional onSubmit event in Remix.
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.
5. Extra features
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.
Should You Adopt Next.js or Remix?
Let's go to the core Next.js vs Remix question. Which one should I use?
Remix is a new, fresh, and ambitious project. It deviates from the most modern JavaScript frameworks since it is anchored in Internet standards and does not rely on Node.js. This means that it relies less on JavaScript and more on browser features. As is usually the case with new technologies, Remix is being used by developers to experiment, learn something new, and generally on personal or small projects.
Conversely, Next.js depends on JavaScript, and it is highly coupled with Node.js. Since it has been in development for many years, its community is bigger. This means that more tools, libraries, guides, tutorials, and how-tos are available. So, Next.js is safe to use in both small and large projects.
Next.js vs Remix - Conclusion
Next.js and Remix are two great technologies. They both are JavaScript-based frameworks, but they have been developed with two different goals in mind. Although they share some features and ideas, there are some characteristics on which they completely diverge, and delving into the 5 most important ones to understand which one to pick was what this article was about.
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.