Which is the best? Spoiler alert, but it depends!
Both of these React frameworks have their own strengths and weaknesses, so it can vary which is best for certain situations:
More often than not, they're both great options for whatever you want to build.
However, the key to choosing between either of these is to be aware of these strengths and weaknesses and then pick the best option for your own needs.
There are no winners or losers here. Just best options for certain scenarios.
That’s why in this guide, I'll be comparing Remix and Next.js side-by-side, as you can see below.
(Click to open a larger version in a new tab).
But make sure to keep reading so you can see how I decided on these results!
I dissect each frameworks features, evaluate their performance, see how they compare in different use cases, as well as share resources for you to learn either of them ASAP. That way you can find the best option for yourself and decide which is the best choice for your projects.
So let’s take a look and find out which is best.
A little disclaimer before we start: As the resident Remix instructor here at Zero To Mastery, I am much more familiar with Remix than I am with Next.js, and what I say here will reflect that.
However, I have experience with both frameworks, and I promise to give my unbiased opinion of each of them. As I said up top, they each have their strengths and weaknesses, and I will address this fairly.
Also, we teach both frameworks here at ZTM, so we have no direct preference if you choose to learn Remix or Next.js.
All we care about is that you find the best framework for your needs.
With that out of the way, let’s get into our comparisons, so you can find the best option for yourself.
Remix and Next.js are both powerful, modern React frameworks designed to improve web development performance, make it more efficient, and more enjoyable.
They also each bring a set of features and conventions that can help developers write high-quality, scalable, and maintainable code.
Both of them are great. However, there are a few differences between them…
Released in 2021, Remix is the relatively new framework on the block.
Remix has managed to turn a lot of heads in the development community, mainly because it leverages the native built-in features of the web, while also providing a phenomenal development and user experience.
For example
Have you ever used the Shopify Shop app to make a purchase?
The app is fantastic, and it’s built on Remix!
Some notable characteristics of Remix include:
Next.js, on the other hand, has been a mainstay in the React ecosystem since 2016, giving it a 5 year head start over Remix.
By providing a blend of features like static site generation and server-side rendering, along with a well-established ecosystem, Next.js has firmly cemented its place as a go-to framework for many developers.
In fact, it’s the framework of choice for TikTok on its web app, Hulu, Twitch.tv, and other large-scale apps, websites, and SPAs.
Next.js stands out thanks to:
Now that we’ve gone through the mile high differences, let’s dive into each framework's performance metrics, side-by-side.
To run a fair comparison of each framework, I looked at the most important factors that would potentially affect your final decision:
(You can click any of these to jump to each comparison section).
Finally, where possible I also tried to highlight situations and conditions where each framework might struggle, as more often than not, these are the major differences that will affect your decision.
With all that said, let's get into each comparison.
Let’s look at load speed first, and how each framework handles both static and dynamic page content. This is an important yardstick because it directly impacts the user experience. Slow load times mean higher bounce rates or misclicks.
Most frameworks handle static content easily enough (images, CSS files, JavaScript), but they sometimes struggle with dynamic content that changes based on user interactions (search boxes).
Employing both Static Site Generation (SSG) and Server Side Rendering (SSR), Next.js provides efficient load times for both static and dynamic content.
With Incremental Static Regeneration (ISR), Next.js can also update static pages after they have been generated, providing an optimal blend of speed and dynamism.
However, because SSG doesn't scale well with dynamic pages, Next.js switched to client side data fetching from the user's browser to handle dynamic content, which can cause slightly slower load times.
It’s still fast - just not the fastest option if you’re working with a lot of dynamic content.
Even though it doesn't support traditional SSG, Remix enables fast initial load speed for static content by using HTTP’s caching capabilities. (We’ll discuss this more later on in this post).
While for dynamic content, it achieves quick load and navigation times with SSR and React hydration on the client.
According to tests ran by Remix:
Here you can see dynamic load time for 2 versions of the same site. One built on Remix, the other built with Next.js.
Remix might be the best option if:
Worst case scenario (Remix):
Next.js might be the best option if:
Worst case scenario (Next.js):
Here’s the thing: You can’t control the speed of the user’s network, and so no framework will give you an edge in that regard. Some people just have bad connections or bad services.
However, good frameworks can make it feel like a site or app is still loading fast, even if the network requests are slow.
Smart eh!
Both of these frameworks do this pretty well...
Next.js minimizes the size of the files that have to be downloaded for the app to run, which ensures quick load times even on mobile devices or slower connections.
This is due in part to its:
Remix also excels on this front in a couple of ways.
First of all, it encourages you to build your app in a way such that your main features work before the JavaScript has been downloaded. This means that users on slow connections only need to download the HTML and CSS first for the app to be usable.
For example
In the recipes app that we build in my Remix course, users can view and create recipes even when there’s no JavaScript on the page yet, meaning less wait time before page interaction. (Another important core web vital).
Take a look at the gif below. Notice how the app’s favicon turns into a spinner when we perform an action?
That’s because the JavaScript is still loading, but the user is not being held back from doing anything. They can still interact with the page while waiting.
Then, once the JavaScript is downloaded, Remix provides additional tools to build an optimistic UI, which creates a snappy experience for the user regardless of the device or connection speed.
Remix might be the best option if:
Worst case scenario (Remix):
Next.js might be the best option if:
Worst case scenario (Next.js):
Bad user experience can lead to higher bounce rates, loss of sales, customer support issues and more.
A framework can be great at everything else, but if it fails at this, it’s generally no good.
Next.js offers a smooth user experience, thanks to features like fast page loads, incremental static regeneration, and built-in image optimization.
It achieves this a few ways:
Remix is also exceptionally good at managing network requests, and it guarantees that the data on the page is always up-to-date as you navigate around due to the way it emulates native web browser behavior.
It also provides wonderful APIs for building pending and optimistic UI, allowing you to hide network latency from users, and making your apps feel very fast, even on slow network connections.
Remix might be the best option if:
Worst case scenario (Remix):
Next.js might be the best option if:
Worst case scenario (Next.js):
Error handling is an important factor when choosing a framework, because it determines how well your website or application can deal with problems.
Without proper error handling in place, small errors can cause the entire application to crash, leaving users frustrated and potentially abandoning the site or app. But by implementing robust error handling, you can provide users with helpful error messages, prevent crashes, and maintain the reliability and usability of your application.
In essence, caring about error handling is about creating a better experience for your users by handling unexpected situations effectively.
Sidenote: There are a fair few similarities here between these two frameworks - mainly because they are both built on React.
For instance, both frameworks allow you to handle errors through error boundaries just as you would in a regular React application, providing more granularity and control over the way errors are shown to your users.
This means that you can catch JavaScript errors within their child component tree, and stop it from breaking everything else.
For example
If we look at the recipes site example from my course, the ingredients field autosaves with JavaScript once you’re done typing.
However, if there’s an error, only the section of the page that displays the recipe breaks!
This means that the rest of the page is still intact, so you can navigate back to the recipe you were working on and try again.
Like I say though, this feature is in both frameworks, but they do have a few differences.
As well as the standard React error boundaries, Next.js also provides error pages out of the box, supports custom error pages, and has robust error handling during both build and runtime:
As well as that error boundary solution, Remix also offers robust error handling capabilities, including custom error routes and asynchronous error handling:
loaderError
and jsonError
for handling errors during data loading. This allows developers to implement error handling logic specific to data fetching and rendering processesRemix might be the best option if:
Worst case scenario (Remix):
Next.js might be the best option if:
Worst case scenario (Next.js):
Basically, if you want and need a simple setup, then use Remix. Just know you might struggle with complex error handling.
On the other side of the coin, Next.js is more complex to setup, but can offer more nuanced error handling.
When users interact with your site or app, they might input information, make changes, or trigger events that update data.
A framework that handles data mutations well makes it easier to manage these changes smoothly and efficiently.
However, if a framework doesn't handle these data mutations effectively, it could lead to errors, slow performance, or difficulty in keeping data consistent and up-to-date. This could result in a frustrating user experience and make it harder for developers to maintain and update the application over time.
So, caring about data mutations in a framework means choosing one that makes it simple and reliable to handle user interactions, update data, and keep your application running smoothly.
Let’s take a look at each framework and how they handle this.
Next.js handles data mutations through API routes, SWR, or third-party libraries.
Next.js also supports real-time updates, so that changes made on the server can be immediately reflected in the user interface.
Not only that, but it enables developers to show updates optimistically, making the user experience smoother by showing changes before confirming them with the server.
Remix re-introduces HTML forms for data mutations, which can provide a more declarative and easy-to-understand approach to managing data changes.
This allows you to use HTML forms as they are, or you can use Remix’s Form component, which emulates HTML form behavior with JavaScript, providing faster load times and an overall better user experience.
In my opinion, this is one of Remix’s best features.
Why? Well, HTML forms are very simple to reason about, so by emulating their behavior, Remix allows you to maintain that simple mental model, even when building complex interactions.
This means that Remix code is easy to read as a result.
For example
I currently work for a dev agency, and about a year ago, I worked on a dashboard UI for Mindbase.
The UI had some charts, tables, and dynamic filter and search options.
You might think that HTML forms would be too simplistic for a UI like that, but I found that wasn’t the case at all. With the way Remix emulates forms with JavaScript, we were able to provide a great dashboard experience for the users, and the code was super simple also!
Remix might be the best option if:
Worst case scenario (Remix):
Next.js might be the best option if:
Worst case scenario (Next.js):
Use Remix if you're focusing on server-side data mutations. Use Next.js if you're focusing on client-side data mutations.
Fast build times mean developers can iterate and make changes quickly, improving productivity and efficiency. It also means that users can experience updates and new features sooner, keeping them engaged and satisfied.
For example
Imagine something breaks during a key sales period like Black Friday.
It could be that the code to fix the issue is fairly simple to implement, but the build time could be the difference in minutes or even hours - losing your client sales.
Obviously this can be incredibly important, so let’s look at the two and see how they compare.
Spoiler alert: Both of them do very well in ideal conditions, with only slight performance differences and almost identical optimization features.
Where they mainly differ is in specific worst case scenarios where build time can be negatively affected. With that in mind, I’ve included both the pros and cons for each.
Next.js is designed to offer fast build times, meaning that when you make changes to your code and rebuild your project, it happens quickly. This allows developers to see their changes reflected almost immediately, speeding up the development process.
Next.js will also optimize the compilation process, which is the process of turning your source code into executable code. It does this by only recompiling the parts of your code that have changed, rather than recompiling everything from scratch each time you make a change.
It’s pretty genius really.
Finally, Next.js will also automatically optimize your project for performance during the build process.
It does things like code splitting, which means breaking your code into smaller, more manageable chunks to improve load times, and image optimization, which reduces the size of images to make your site load faster.
That being said, Next.js is not without its issues when it comes to specific situations.
If you have very large projects with very extensive codebases, complex dependencies, or numerous pages/components, then the initial build process can take longer due to the increased amount of code that needs to be compiled and optimized.
This can result in slower build times and may require developers to optimize their code or split their project into smaller, more manageable chunks to improve build performance.
Also, if a Next.js project relies heavily on dynamic data fetching, such as fetching data from external APIs or databases at build time using getStaticProps
or getServerSideProps
, then the build process may be slower. This is especially true if the data sources are large, or if the fetching process is resource-intensive.
This means that developers may need to optimize data fetching logic or implement caching strategies to improve build times.
Dependencies play a crucial role in the build process, and issues related to dependency management, such as outdated or conflicting dependencies, can also impact build times.
And finally, because Next.js also supports serverless functions for server-side logic, if a project heavily relies on serverless functions, especially for dynamic content generation or complex backend operations, it may affect build time.
Remix generally has faster build times than Next.js, especially as your project grows. This is due to the fact that build times in Remix are decoupled from your data, while in Next.js, they aren’t.
That being said, its optimization methods are pretty much identical.
When you make changes to your code in Remix and rebuild your project, it happens quickly. This allows developers to see their changes reflected almost immediately, speeding up the development process.
Just like with Next.js, Remix also optimizes the compilation process by only recompiling the parts of your code that have changed, rather than recompiling everything from scratch each time you make a change.
Also like Next.js, Remix will automatically optimize your project for performance during the build process to make your site load faster.
Again, the main differences between these two are where they struggle.
Remix uses a route-centric approach, where each route is associated with specific data loaders and rendering logic.
This is an intuitive and helpful feature when writing code, but it can mean that in projects with complex routing requirements or a large number of routes, configuring and optimizing routes may lead to longer build times.
Remix also encourages the use of data loaders for fetching data at build time or on-demand.
This means that if projects require extensive data fetching from external APIs or databases, especially if the data sources are large or the fetching process is resource-intensive, then it may impact build times.
Remix provides server-side rendering and serverless functions for executing server-side logic.
However, intensive server-side processing, such as complex data manipulation or extensive server-side rendering, may increase build times, particularly if the logic is not optimized or relies on external resources.
Similar to Next.js, managing dependencies in a Remix project is crucial for efficient build times. Outdated or conflicting dependencies, unnecessary packages, or inefficient usage of dependencies can impact build performance and increase build times.
While Remix does support static site generation, generating static pages for large websites or projects with complex data dependencies may result in longer build times.
Developers should carefully evaluate the usage of SSG and consider optimizing data fetching and rendering logic to improve build performance.
Remix might be the best option if:
Next.js might be the best option if:
Worst case scenario (Next.js):
User experience is incredibly important, but I feel like dev experience is right up there also!
Mainly:
All of these are important factors that hopefully, you have some say over when making the final choice of which framework to use in your project.
With that in mind, let’s look at the most common factors that can affect this.
Next.js boasts a well-defined developer experience with first-class TypeScript support, fast refresh, image optimization, and a file system-based router. It also provides a seamless developer experience that extends beyond the baseline React tooling.
The fact that it’s been around for 5 years longer than Remix, means that you’ll never have issues with a lack of support, assets or information.
In fact, there are over 6,000 Next.js packages on NPM, and 83,258 repositories for it on GitHub.
In my personal opinion, I think Remix really shines here - even though it’s a much younger framework.
As I mentioned before, Remix’s approach to data fetching and data mutations with forms drastically simplifies your mental model for how data flows through your app, eliminating the necessity for a state management library in most cases. It’s also extremely straightforward to display granular error messages.
As for the more common dev experience factors:
However, Remix is owned by Shopify, which is great for the long-term ecosystem and stability of the framework.
Remix is also built on top of React Router, the largest routing package for React apps. This means that the migration path from a React Router SPA to Remix is very smooth, and only getting better, with many React Router users migrating their apps to Remix, bringing even more people into the community.
Finally, Vite will soon be the default compiler for Remix, which opens developers up to the vast ecosystem of Vite plugins for their Remix apps
So the future is pretty good!
Next.js stands out with its mature ecosystem, extensive community support, and proven stability. Remix, on the other hand, shines with its ground-breaking features and is a strong contender that is already revolutionizing the way we build React applications.
Ultimately, the decision comes down to your project's requirements and which aspects you value most in a web development framework.
Remix might be the best option if:
Worst case scenario (Remix):
Next.js might be the best option if:
Worst case scenario (Next.js):
In simple terms, Remix is more restrictive but it allows you to build fast. Next.js has more flexibility for you to get things done, but it can be a little overwhelming with all the possible options.
By now you should have a good idea of the best framework to meet your specific needs. Just in case you're still not sure though, let me answer some common questions and scenarios, and then you can make your final decision.
Also, because both frameworks are capable of doing pretty much whatever you want, it's in their flaws where the differences really stand out.
With that in mind, I'll share scenarios where you might not want to use them also, so you can choose the best option.
E-commerce sites usually require dynamic content, impeccable SEO, and fast load times to keep customers engaged. In this context, both Remix and Next.js fare well due to their support for Server Side Rendering (SSR).
Next.js has been a popular choice for e-commerce due to its well-established ecosystem and robust community. It's also been proven to handle high loads, and its automatic optimization feature can be a boon for image-heavy product listings.
That being said, Remix is also a great choice for e-commerce sites.
Add in the fact that Remix is actually owned by Shopify, and Shopify has built their Hydrogen framework (which is specifically geared toward e-commerce sites) on top of Remix, and it’s definitely appealing.
Shopify is one of the best e-commerce platforms in the world, which is a good indication of how well Remix enables you to build e-commerce experiences.
Remix might be your best option for e-commerce sites if:
Worst case scenario:
Next.js might be your best option for e-commerce sites if:
Worst case scenario:
Both frameworks can handle e-commerce sites, but it's the flaws that will be the deciding factor. Remix prioritizes server-side rendering and a unified approach, but struggles with client-side, while Next.js offers flexibility in content generation and client-side interactions.
The best option will depend on your specific needs.
Blog content is usually static and both Remix and Next.js do well here, though they take different approaches with different tradeoffs.
Next.js supports a traditional SSG approach, which means the page content is generated at build time, resulting in rapid load times and excellent SEO. It also has an Incremental Static Regeneration (ISR) feature, allowing existing pages to be updated in the background without causing delays to the user.
Remix doesn't support SSG in the traditional sense, but you can provide a similar experience using HTTP caching and CDNs.
This means that if you put your Remix site behind a CDN, then for any page on your site, you can send a “Cache-Control” header telling the CDN to hold on to the page for a specified amount of time. This has the same effect as SSG, but with a few tradeoffs.
The nice thing about SSG is that you create all of your pages at build time, so when a user visits your site, there’s nothing for the server to do but send the HTML page, resulting in very fast page loads for the user.
When you don’t use SSG though, like Remix, you build a page when it is first visited by a user, so the initial page loads are a little slower.
However, if you use the Cache-Control header and a CDN, the page load is only slower for the first user to visit that page. Once a user has visited the page, it is now cached in the CDN, so subsequent users will get the cached HTML page, and their load time will be just as fast as if you had used SSG.
The nice thing about the SSR with Cache-Control approach is that you don’t have to generate your entire site every time you make a change to the content, like you do with SSG.
This means you can deploy changes to your site much faster, and with very little tradeoff in the load times for users. Users get the SSG experience but without you having to deal with any complicated build process.
Remix and Next.js both allow you to serve static html pages from a CDN, the difference is in how the html page gets there.
If you ask me, (I realize I'm slightly biased) Remix’s approach is better.
I personally don’t care for SSG because the tradeoffs it requires you to make in terms of build and deployment processes are not worth it to me.
Remix’s approach keeps your deployment process simple and allows you to quickly deploy changes to your site, and it only requires a very small performance hit for a small fraction of your users.
Remix might be the best option for your blog if:
Worst case scenario:
Next.js might be preferable for blogs if:
Worst case scenario:
For web applications, where real-time updates and interactivity are paramount, Remix's unique approach to data fetching is a game-changer.
Before Remix, a lot of web applications were built as single-page applications (SPAs), and the client would use tools like redux or react query (now tanstack query) to manage fetching and updating data on the server.
These tools are great, but they introduce a lot of complexity beyond the simple client-server model, where the server sends full HTML pages, and the client makes requests with HTML forms.
Remix mixes old and new approaches to data fetching by emulating the client-server model with JavaScript. This means that the data on your pages always stay up to date, but it doesn’t require nearly as much thought on your part. This enables you to build complicated web app experiences in a very simple way.
Both Remix and Next.js perform well across different use cases, but their performance characteristics may slightly vary depending on your exact needs and the specific nature of your project.
While Next.js has a proven track record and some unique features like ISR, Remix brings new ideas to the table, including its unique data fetching approach that could potentially revolutionize how we build interactive web applications.
Remix might be the best option for web applications if:
Worst case scenario:
Next.js might be preferable for web applications if:
Worst case scenario:
For beginners stepping into the world of React development, choosing a framework to learn can be a critical decision, and so if I were to recommend one, it would be Remix.
Hold off because I promise there’s a few good reasons why you should learn Remix (if you're a beginner).
Learning a new framework as a beginner isn't just about how easy it is to grasp, but also about what else it teaches you in the process.
Despite being relatively new, Remix focuses on aligning with the fundamental principles of the web.
Why care?
Well, as a beginner, this can be greatly beneficial as it encourages a deeper understanding of how the web works at the same time as learning Remix, rather than just learning how a specific framework works on its own.
It's a compound learning effect.
Also, Remix's innovative features such as its handling of data loading and mutations are a departure from conventional methods seen in older frameworks.
This means that you get to not only learn new ways to solve problems, but you’re also getting an early start with concepts that could become widely adopted in the future.
Another selling point of Remix is its comprehensive documentation. Sure, it’s still a work in progress, but it's remarkably detailed and covers everything from the basics to advanced features of the platform.
In fact, resources are constantly being developed by the community, which makes for a robust learning ecosystem.
That's not to say that Next.js is a poor choice for beginners.
It's a mature, well-documented framework with a strong community backing and a large number of learning resources. Its design principles, while different from Remix, are also valuable for a beginner.
Not only that, but there tends to be more job offers with Next.js as a requirement than Remix (at least at the moment).
Remix might be the best option for beginners to learn if:
On the opposite side of the coin...
Next.js might be preferable for beginners to learn if:
Basically if you want a simple approach that's more restrictive in how you can build (as you build to web specs), but also breaking new ideas, learn Remix.
And if you want a broader (but possibly more overwhelming) framework with more options, then learn Next.js.
I will say this though. If you're following a good course, you're going to only cover the most important content, and so Next.js won't be as overwhelming as if you're trying to learn everything on your own.
Phew, that was a huge post! If you’re overwhelmed with all the info, let’s do a quick recap.
As a reminder:
Remix
Next.js
Ultimately, the best choice depends on the specifics of your project and your personal preference as a developer. I highly recommend you go back through the most important sections for your project in this guide, and see which option best fits your needs.
Then, if you want to learn either framework ASAP, check out our courses on Zero To Mastery.
Even better?
As a Zero To Mastery academy member, you have access to both of these courses right away (as well as every other course in our academy).
Plus, as part of your membership, you'll get to join me, all our other instructors, and 1,000s of other people (some who are alumni mentors and others who are taking the same courses that you will be) in the ZTM Discord.
Ask questions, help others, or just network with other Web Developers and tech professionals.
What do you have to lose? Choose one and join today 😉.