There are lots of frameworks built on top of React. Some of them are Next.js, Remix, Gatsby, Redwood, Blitz etc. Next.js has gained a lot of popularity because of the performance, developer experience and tight integration with deployment platforms that it offers. However recently, Remix has been heavily discussed and compared to Next.js as an alternative. Lots of programmers are using Next.js as a potential tool to build apps. Remix is being presented as another option, but developers need to know the comparison and why they would want to pick one over other. Hence here we came with a comparison of Remix vs Next.js. Let’s compare Remix and Next.js on the basis of various parameters.
Remix is built on top of standard Web APIs, whereas Next.js is built on Node APIs. With Remix you won’t have to learn as many extra abstractions over the web platform. You just need to learn useful concepts no matter what tool you decide to use later. Also, APIs, the core of Remix doesn’t rely on Node dependencies. As Remix doesn’t depend on Node, it is more portable to non-Node environments like Cloudflare Workers and Deno Deploy.
This will let you to run Remix on the edge easily. Running on the edge means server hosting your apps are distributed around world rather than being centralized in a single physical location. Whenever a user visits website, they are routed to the data center closest to them for fast response times.
Route is one of the most important parts of application because we are building a web application. In Next.js, they have their own router using the file system, hence you can create a pages folder and put files there,
pages/ index.js about.js Contact.js
These files are going to becomes pages inside the application, with below URLs.
- / (this is index) - /about - /contact
They also have useRouter hook to access data from router like search (query) params or methods such as reload or push to navigate to another URL.
In Remix, they use React Router v6 internally but they provide a file system based system, rather than pages Remix call them routes, but the general is similar.
routes/ index.js about.js Contact.js
Those files are going to become routes with same URLs as in Next. Main difference comes with the introduction of Layout Routes.
Most common requirement of user interfaces is to re-use a layout between two URLs, a common example is to keep header and footer on every page, however this can become more complicated. Amazing example of this is Discord, let’s analyze-
You can see four main areas-
Whenever you want to build this UI in Next.js, you need to create a file at pages/[serverId]/[channelId].tsx, get the data os each list and render a component like-
function Screen() { return ( <Layout> <Servers /> <Channels /> <Messages /> <Users /> </Layout> ) }
When the user navigate to another server or channel, according to the data loading strategy you used, you may need to get load everything again with the new channel or server. This is because Next doesn’t have support for layout routes, hence each page renders everything on the screens, including shared layouts between screens.
As opposed to Next.js, Remix has support for that, so in Remix we would make a file structure like this:
routes/ __layout.tsx __layout/ $serverId.tsx $serverId/ index.tsx $channelId.tsx $channelId/ index.tsx $thread.tsx
While you have more documents, this will assist you with keeping the code more coordinated and to make stacking information more improved.
When you have more files, this will help you to keep the code more organized and to make loading data more optimized.
_layout.tsx creates what Remix calls a Pathless Layout Route, this is a route component that works as a layout however without adding segments to the URL, hence you won’t see a /_layout in the ULR, and rather you will go directly to the /:serverId part.
$serverId.tsx creates a layout route with dynamic parameter serverId that can be used in server to load the route data.
Same for $channelId.tsx.
Index.tsx inside the $serverId folder will be used when user goes to /:serverId without a channel ID, there you can render something special or you can redirect to a channel, there you can render something special or we can redirect to a channel.
index.tsx in the $channelId folder would be rendered when the user is not in a particular thread, in such a case you can render the list of users of the channel.
Those files will generate the following routes:
/:serverId /:serverId/:channelId /:serverId/:channelId/:threadId
Now, every route file will be able to render parts of UI.
Aside of being able to have individual route files with their own data and UI, it has another benefit, if the user is on the URL /server-a/channel-a and navigates to /server-a/channel-b Remix knows that server ID didn’t changes and can get the channel data without touching server, hence you can avoid loading data you already have.
So to get the same behavior in Next.js, you should move your data loading to be completely client-side so the component can reuse data that it has, using something like SWR or React Query. Hence, this is a big performance advantage of using layout routes that you cannot get as easy and with the same UX in Next.
Know more