Remix vs Next.js

Next.js vs Remix, two frameworks that are very popular and have some very devoted fans in the developer community. Both are JavaScript frameworks for building web applications and are built on top of React. They offer features like server-side rendering, routing and bundle optimizations. However, they differ in their approach to these features and their overall philosophy and community support. Let’s compare the two.

Let’s start by going over a few key elements.

SSR vs SSG vs CSR

Server-Side Rendering (SSR), Static Site Generation (SSG), and Client-Side Rendering (CSR) are three different methods for rendering web pages.

CSR means generating HTML on the client-side using JavaScript, after the initial page load. This approach is commonly used for dynamic web applications that require frequent updates and real-time data. It allows for a more interactive user experience but can result in slower initial page load times. React, the library on which both Next.js and Remix are built, is known for its strong CSR capabilities.

SSR, on the other hand, involves generating HTML on the server-side and sending it to the client, where it is displayed in the user’s web browser. This method can provide faster page load times and improved search engine optimization (SEO) as search engines can index the content of the pages more easily. Both Remix and Next.js are known for their robust SSR capabilities, though Remix is even more optimal in this aspect.

SSG means generating HTML files at build-time, which can then be served statically to clients. This approach can provide even faster page load times than SSR, as there is no need to generate the page on the server for every request. Static sites are also more secure and scalable. The main downside to SSG is that while it can be a good option for small sites that don’t change often, it is usually quite tedious for sites with lots of pages with data that changes often.

Routing

Both Next.js and Remix utilize a file-based routing system for rendering pages. This means that each page is stored in a separate file and is associated with a route based on its file name. Ultimately, each page is rendered as a React component.

In Next.js, the files inside the /pages folder automatically become routes, thanks to their own router using the file system.

pages/index.js -> /
pages/products/index.ts -> /products
pages/products/create.ts -> /products/create

Remix uses React Router v6 internally and has a file system-based system for routing. In Remix, the routes are stored in a routes/ folder and have the same URLs as in Next.js.

app/routes/index.js -> /
aps/routes/products/index.ts -> /product
app/routes/products/create.ts -> /products/create

Data Loading

Both frameworks offer multiple ways to load data.

Next.js provides two options for data loading, depending on the type of page being built. The first option is getStaticProps, which fetches data at build time and provides it as the component props. This option is used for static site generation and incremental static regeneration if the revalidate interval is set.

export async function getStaticProps({ params }) {
  const productList = await getProductList();

  return {
    props: {
        productList,
        slug: params.slug
    }
  }
}

The second option is getServerSideProps (SSR) – it fetched data on the server-side at runtime and provides the returned data as the page’s component props.

export async function getServerSideProps(context) {
  return {
    props: {}, // will be passed to the page component as props
  }
}

Remix uses a different approach to load data compared to Next.js. It provides a loader function to use on each route file, which works on the server-side at runtime. Alternatively, on the page component, you can use the useLoaderData hook to gather this data.

Data Mutations

While Next.js offers a few ways to load data, there is no built-in way to perform mutations. This means that you would need to create a form, attach an onSubmit, prevent the default behavior, get the input values, then send the data using the Fetch API to an API route, and add a few states to handle the loading state, store any error, etc.

On the other hand, Remix offers a built-in Form component that allows you to decide if the method is GET or POST and set an action with a URL to send the data to. You can then put the inputs inside the form, and Remix takes care of sending the values from the form to the action with the correct method and keeps a loading state. It also aborts requests if the form is sent again, and more. The request can be sent to any route, not only resource routes. If the method is GET, Remix will run the loader function, and if the method is POST, it will run the action function. Additionally, if you need to send a form programmatically, you can use the useFetcher hook or useSubmit hook, which sends data on every keystroke or after a checkbox is clicked.

Styling

Next.js comes with styled-jsx and CSS Modules out of the box. Additional CSS libraries or frameworks can be added with some configuration or plugins.

In contrast, for a long time CSS in Remix relied on a DIY approach with <link> tags. In 2023, the Remix team brought several improvements and now provides ways to work with the most common ways to style your application. Behind unstable_ feature flags, one can now use TailwindCSS, PostCSS, CSS bundling, CSS Modules or Vanilla extract.

Image Optimization

Next.js has a built-in component called next/image that enables image optimization, lazy loading, size control, and integrates loaders. This component allows for automatic image optimization support.

In contrast, Remix has no built-in image optimization support but offers a way to import images and get a URL back. Alternatively, the img: prefix in the import path can be used to get the image URL and perform some simple transformations, retrieve multiple URLs to use in srcset, a placeholder URL, and change the quality.

Error Handling

While Next.js lets you define special pages for error handling, Remix allows you to export an ErrorBoundary component within any route module to handle specific route errors. If a route is nested, only the nested route will have its errors handled by the ErrorBoundary component, while the parent route will continue to function as normal.