Next.js was created by Vercel six years ago back in 2016. But in those six years, its popularity has grown massively (along with the popularity of Vercel as a deployment option) and it has quickly become one of the most popular React frameworks. It has almost 100,000 stars on GitHub and millions of downloads every week on NPM.
Its popularity is due to how easy it is to use. To create a fully-working Next.js app all you need to do is run:
This gives you a fully functional isomorphic (capable of rendering both on the client and server) app. Additionally, it has a wide variety of features to extend its capabilities.
However, there are problems with Next.js that have revealed themselves as it has continued to age. The build process is not optimized, reducing developer experience, and it uses outdated standards. This is why frameworks like Remix have been created.
Remix is a newer framework created by the team behind react-router in 2021. It aims to solve many of the problems that Next.js had, including build speed, adoption of modern standards, and separation of client and server code. Due to being created by the people that created react-router, it also includes more advanced routing features like nested layouts. It has tens of thousands of downloads every week on NPM, but trails behind next quite significantly:
Which should you be using? That depends a lot on what you want to do, but here we’re going to compare the two as if we’re building a markdown-based blog, a common need for js frameworks. We’re going to compare Next.js and Remix across the following features:
- Ease of setup
- Build process and compilation speed
- Ecosystem support
- Markdown & MDX support
- Extendability
- Developer experience
- Deployment
Let’s get to it!
Ease of setup
Next.js and Remix both have really straightforward setup processes.
For Next.js, we run the command above:
To get a working skeleton app. But Next.js has a huge template library that you can use to add more functionality to your app from the start. To create a new app with any of these you just run the above command with the—example flag and the template URL:
So if you wanted to include tailwindcss into your app from the get-go, you run:
You can also use flags to support TypeScript, eslint, or NPM explicitly.
Remix also has an easy setup and plenty of configuration options. Setup is:
And again you can use a template:
Remix has stacks (such as the indie stack above) and a helpful setup flow where you can choose JavaScript or TypeScript and your deployment target, such as fly.io, Vercel, or Cloudflare (obviously the Next.js setup presumes a Vercel deployment).
As you can see, they’re both super easy to set up, so we’ll call this a tie.
Winner: Tie
Build process and compilation speed
The build process is how the framework transforms your code into something the browser understands.
When building a blog, you generally do not want to wait long to preview posts, especially when you did not change any code other than the post itself. Because of this, the build process is important.
If you were comparing Remix to a past version of Next.js like Next.js 11, this would easily be in Remix’s favor. Remix has its own bundler (which uses esbuild under the hood) optimized for ESM (ECMAScript Modules), whereas Next.js uses Webpack, a bundler known for its performance issues.
The problem with Webpack is that it was built before the standardization of ESM, a module system built for browsers, and has not adapted to it enough yet. While Webpack supports ESM, its architecture means it must bundle everything instead of utilizing ESM, even if you are running the app in development mode. On the other hand, Remix’s bundler is built for ESM.
However, Next.js has improved in this aspect. It has recently adopted the Rust-based compiler SWC (Speedy Web Compiler) instead of Babel, which significantly improved performance. Additionally, Vercel is working on creating a new bundler called Turbopack, which should replace Webpack in the future and will likely fix most or all of the performance issues present here.
However, as of Next.js 13, it is still in development and does not support building for production.
Another thing to note is that Remix’s bundler does not support HMR (Hot Module Refresh), which updates components in development mode without a page refresh, maintaining the state of the page.
Overall, Remix is currently ahead of Next.js when it comes to production and development compilation speeds. This could change very soon due to Turbopack appearing in Next.js 13.
Winner: Remix
Ecosystem support
Ecosystems are key for efficient building. If there is already a library that provides what you need, that is one less thing on your plate. If you are building a blog, you need CMS support, image support, featured post support, and so on. Remix’s ecosystem is growing, but Next.js’s is bigger by a large margin, simply due to its age and popularity.
As of publishing, there are only 180 packages on NPM tagged with remix, as opposed to 1217 packages tagged with nextjs. It is not even a contest. While this might change in a few years, currently, Next.js easily wins.
The caveat to this is the support for expansion that Shopify is going to bring to Remix. Shopify bought Remix in October 2022 and it is going to become an integral part of the Shopify ecosystem. This means that developing for Shopify means developing in and for Remix, so expect to see more remix-specific packages coming through and the ecosystem being built out with help from Shopify.
Winner: Next.js
Markdown & MDX
Markdown is the most popular way for developers to write long-form content (in fact, this article was drafted in Markdown), so it is crucial for a blog. Both frameworks support markdown and extensions such as MDX. However, there still are a few differences.
First, the setup process for MDX is a bit different between Next.js and Remix. To set up MDX in Next.js, you need to install their @next/mdx plugin and add it to your next.config.js. On the other hand, with Remix, MDX support is built in, although if you want it rendered dynamically rather than just being precompiled, you will need to use something like mdx-bundler.
Another difference is how they handle frontmatter. Frontmatter is data you put in a Markdown file that describes the file. For example, you might put in a title, tags, and the author name. The format Remix and Next.js use are pretty different. Remix uses a more standard frontmatter format, where you put YAML in between ---:
On the other hand, Next.js allows you to export an object using ESM. This is not the standard way of adding frontmatter in Markdown, but it might be more familiar to people used to JavaScript.
You can use YAML or TOML with Next.js, but it requires a separate frontmatter processor and a fair amount of setup to get it rendered. Overall, we have to give this point to Remix because you can use MDX without a plugin, and the frontmatter format is on point.
Winner: Remix
Extensibility
Extending the capability of a framework/build tool is very important for a project like a blog because you want it to be as easy as possible to write blog posts.
This might mean adding a plugin to automate some elements of creating a blog post or creating a new syntax feature to enable more concise implementations of certain things within a blog post. Unfortunately, while Next.js has good plugin support, Remix is lacking in this aspect.
Because Next.js uses Webpack, you can use any of the wide variety of Webpack plugins in a Next.js project. The Webpack configuration format can be complicated, but once you get the hang of it, you can do a lot. You can also add SWC plugins to customize the compilation itself, although SWC’s plugin support is experimental as of now. However, we have yet to see how plugin compatibility will be once Next.js migrates to Turbopack.
On the other hand, Remix’s bundler does not support plugins at all. You can still do quite a lot by adding separate scripts to run whenever you compile your project, but that is a lot less elegant.
Winner: Next.js
Developer experience
DX is more subjective, but there are still some universal differences.
Remix is less abstracted than Next.js, which can be good or bad depending on how you view it. On one hand, you might need to write more code, but due to Remix’s adherence to web standards, you might be more familiar with the methods to write that code. It also means that your code is potentially more reusable and more future-proof.
Remix also includes some helpful hooks like useFormAction. However, these do not impact overall ease of use much, because they are only applicable in specific cases and you can use a third-party library anyway.
Next.js has a lot of infrastructure set up to help you use the framework, which is a positive for the developer experience. The flip of this is that the framework is large, making it more difficult to understand from a cold start and as it tries to be all things to all people,
Basically, both have positives and negatives in their DX, so we’re making this a tie.
Winner: Tie
Deployment
Both Next.js and Remix have a variety of deployment options. With both, you can deploy to a Node server to run a traditional VM as well as edge serverless function platforms.
Next.js allows you to deploy to Node.js servers using next build, static HTML using next export, and you can use third-party plugins to deploy to popular serverless function providers. On the other hand, Remix has integrated tools to deploy to serverless targets and allows you to select them in the setup CLI.
However, Remix has one crucial limitation: You are unable to use Static Site Generation (SSG). That means you are unable to generate static HTML files to put on a file host, reducing the deployment options you have.
In this category, Next.js wins, because static site generation is an important feature, especially for websites like blogs (although Remix’s philosophy is that it is unnecessary).
Winner: Next.js
Comparison table
Conclusion
If you tallied up the comparison, you probably noticed Next.js was ahead in one more category than Remix. However, comparisons are never this simple, and a lot of it depends on your priorities. Here, we’re focusing on blog-building and Next.js is the better option for that. The static site generation it offers helps get the most performance out of a website, and we like the extensibility of Next.js.
However, If you prioritize adherence to web standards, Remix is a better choice. Also, if you are going to be building a site that can take full advantage of the server-side rendering Remix offers, like an ecommerce site, the choice is a much closer one.
But if you want the most well-known framework, Next.js is the option to choose. You can build the blog, the rest of the marketing site, the admin panel, and the entire application with Next.js
The takeaway from this article though is Remix is pushing Next.js, as Vercel themselves admit:
This competition is excellent for developers. It means that there is more choice, but also that each framework has to continue to improve to survive. As Lee Robinson says: Developers Win.
Learn more about the remix framework or how to hire a remix developer.
