Is Remix Better Than Next.js?

Remix specializes in server-side rendered websites and promises a better developer and user experience and faster load times with an innovative approach to routing. In the React ecosystem, Next.js has established itself as the technology for dynamic websites. Since the late 2021, Remix is a new contender from the makers of React Router. Let’s see an overview of Remix using a sample application and compare it to Next.js.

Installing and setting-up Remix

Remix can be installed using npm, as is common for JavaScript frameworks. You can simply create a new project using npx create-remix. In doing so, the script asks the user for preferences, such as the use of TypeScript or a preferred server implementation (Express, Vercel, Netlify, etc.), and creates a minimal project framework. Remix also offers more complex templates where pre-built stacks are preconfigured with database solution, integration and unit tests, deploy pipeline, and hosting provider. However, we want to focus less on these stacks and more on the core concepts of Remix.

Server-side rendering

Remix is meant for server-side rendered websites. But what does that actually mean? Rendering describes the process of an HTML document getting populated with content. A basic distinction is made between client-side and server-side rendering (Fig. 1).

Fig. 1: Overview of client-side and server-side rendering with hydration

For example, if you create a React single-page application with create-react-app and deploy it to a web host, an HTML document is downloaded when you visit the website. However, the content of this document is limited to references on styles and scripts needed to build the website. Constructing the HTML structures only occurs in the browser, which is why we call it a client-side rendered website (CSR). It’s important to know that usually, all CSR routes sites are defined by the same HTML file, which also means that for a crawler the same metadata is visible for all routes. This is bad in web stores, since different embeddings are not created for different product routes.

If the web server fills the HTML document with content before transmission, this is called server-side rendering (SSR). Since the documents are created dynamically, the aforementioned problem with metadata is eliminated. However, the website takes longer to respond because the server must first assemble the response and cannot simply copy it from memory as it would with a static host.

Between CSR and SSR, you can still find Static Site Generation (SSG). Here, all site routes are pre-rendered and the HTML documents of all routes are uploaded to the web host. This approach can be interesting if the site contains few static routes, such as a portfolio or documentation site. For a web shop with hundreds of products that can be edited on the fly, this approach isn’t suitable.

Solutions from Remix

Remix creates the server that serves the React application as a framework. When a route is invoked, the Remix server renders the HTML document before it is transmitted to the user. The browser can render the site immediately. JavaScript is executed in the background, effectively making the site a client-side single-page application. The step where the client does the rendering is called hydration. As a result, Remix provides the benefits of SSR, such as dynamic metadata and faster rendering of content in the browser, as well as the benefits of CSR, such as making changes to the site without reloading an HTML document.

One problem with server-side pre-rendered web pages with client-side hydration is often that the page has already been rendered for the user before hydration, but is not interactive yet (Fig. 1, right column). Remix solves this problem by building the data concept on HTML forms. More on that in the section "Data Flow and Hydration".

Routing in Remix

Remix uses the directory to define routes. All JavaScript module files stored under app/pages are interpreted by Remix as route components. The name of the file defines the route segments. For example, a module under app/pages/products.tsx defines the /products route. Subfolders can be created for deeper routes. Variables can be defined in the file or folder name with a $ sign. For example, a file defined under app/pages/products/$productId.tsx will be included in all products/* routes.

The dropped files export a common React component via the default export. Features provided by React - such as hooks - can also be used here. In addition to the default export, you can provide other optional exports that can be used to query data, define troubleshooting, and declare metadata. But more about that later.

An interesting feature of Remix routing is nesting. Remix assumes that websites are usually hierarchical. For example, all routes on a website have the same navigation bar, account settings all have a sub-navigation, or all product pages have a consistent layout. Therefore, the modules stored under app/pages do not define the entire routes, but only route segments, as Figure 2 shows. Here, a product website is shown assembled from three segments (root component, $product-Id.tsx, and $variantId.tsx), and how the called URL is mapped to the route components.

Fig. 2: Visualization of nested routing.

The nesting is enabled by an component provided by Remix. This can be included in the render function of a segment. When segments are assembled, the subsequent segments are included there (Fig. 3).

Fig. 3: Segments of a route are joined together

When rendering a route, Remix starts at the root under app/root.tsx and includes the next route segment in the component. The next segment is then included in the included component. This continues until the whole URL has been mapped.

The question may arise, how does routing work with index pages? For example, if you want to list all categories on the /categories route, the obvious thought would be to put that listing in the app/routes/categories.tsx. However, the problem is that more specific routes, like /categories/123, would also render this listing. Remix solves this problem by using index segments. A module named index.tsx can be created in the app/routes/categories folder. Remix will prefer this index segment if it is the last element of the path (Fig. 4).

Fig. 4: Mapping of index routes and regular routes in the file system and in the URL.

Individual segments are rendered in parallel and in isolation from each other, and are assembled once all segments are complete. Isolation means that data cannot be shared between route segments, which may cause them to be requested multiple times. However, the advantage of this strategy is if errors occur in one segment, you can guarantee that the other segments will continue to work. Remix builds the error recovery strategy on this. You can export a catchBoundary and an errorBoundary in a route segment.

Functions are React components, just like the default export. If there is an error...