Remix JS: what is it (vs Next JS)?

(And what is Remix vs Next JS?)

For some time now, if you've been reading a bit of news sources around React or Next JS, you'll have heard about the new rising star, the new fullstack framework, called Remix.

What is Remix, and what is it worth? Will it dethrone Next JS? Is it worth taking the time to learn? What is the difference between Remix and Next JS? So many questions!

And we'll explore them together. Let's take a deep breath and dive into the wonderful world of React fullstack frameworks.

At first glance, it could easily seem that Remix is just a variant of Next JS.

But in reality, even if there are similarities on the surface between Next JS and Remix, even if the two teams talk to each other and even get along well, there are also deep differences that deserve to be explored in detail.

To do this we will look at the issue in 3 parts:

• First of all, what are Remix and React for? Or to put it another way, what are their common strengths?
• Secondly, what are the particularities of Remix?
• And finally, what are the strengths and weaknesses of Remix versus Next JS that would make you choose one over the other?

What are Next JS and Remix for?

As you probably know, React is used - to simplify things - to transform a state into a user interface.

We have input data, a JS rendering function, and HTML output.

Offloading logic to the client side makes for a smoother user experience - since you don't have to go back and forth to the server for absolutely every state update.

But, on the other hand... client-side rendering makes it harder for search engine spiders to find the site.

To overcome this problem, there are solutions that propose to deport this logic on the server side for the initial rendering.

This is the principle of Next JS, which I already mentioned in a previous video. And Remix addresses the same problem in a similar way, with an initial rendering phase on the server side.

So you get the best of both worlds, with an initial rendering that is done server-side and optimised for SEO. Then later renderings that are done client-side on browsers, and therefore provide an optimal user experience.

But what does Remix bring? What is the need that NextJS does not address and that Remix does?

What are the particularities of Remix?

In a way, Remix takes advantage of the fact that it was born recently.

Remix builds on the new features of the latest versions of React.

More exactly, the direction React is taking, because Remix seems to have taken that direction even before React took it publicly.

(For the record I went into a bit more detail about what's new in React 18 in another video).

For example, the way Remix structures components is very similar to React server components. With a separation in the nomenclature between what is server domain and what is client domain.

The Remix team describes their solution as 4 things:

• a compiler
• an HTTP request handler
• a server framework
• a client framework

They even describe their solution as "a compiler for React Router". And I'm going to dwell on that phrase for a moment.

What does it mean in practice?

Before going any further, it's important to note that Remix is created by the React Router team.

And when you read their technical documentation they are obviously not neophytes, you can feel that they know React intimately.

They use React Router to bind a route, a URL basically, with a React component.

Each element of the route, of the path, is associated with a component.

For example, let's say we have a route /shop/classes/42

This route will be linked to a <Shop> component, in which there is a <Classes> component in which there is a <Class> component that will render the info for element 42.

(So a little aside, to be precise: Here I have copied the URL to the component nomenclature to make the example more readable. But in reality, in Remix as in Next JS, it's the file and folder nomenclature that makes the link, not the component nomenclature.)

Let's get back to the point.

The idea is that each component knows how to retrieve the information it needs to be displayed. But this is where the intelligence of Remix comes into play, and the fact that Remix is described as a compiler for React Router:

In our example shop with classes, we have a component within a component within a component, where each needs to retrieve some information to display itself.

If each component is responsible for retrieving its own information, we'll have a nice separation of responsibilities but also a big chain of successive network round trips.

The first component loads, retrieves its information, renders the second component, which loads and retrieves its information, and so on. In the end, it would be a chain that takes time.

So obviously, in a "classic" React, we're going to have a tendency to retrieve all the necessary information at the top of the chain and then bring it back down.

It's ugly, it doesn't really respect the "separation of concerns", the distribution of responsibilities. But at least... it works in a reasonable time.

In Remix, each component file has three parts (in the same file).

There is of course the rendering function of the component, in the classical way.

And then two optional data transfer functions.

• A function named "action" which is used to process on the server side the information sent by the client, for example the data of a form.
• a function named "loader", which is used to retrieve the data that the component needs to render; for example from the database or the file system

And so here, at rendering time, Remix will retrieve each of the loaders that correspond to the component tree of the called route, and will launch all the useful loads simultaneously.

That's why Remix is a compiler for React Router: the router is nested with the render chain.

And this is where we see the biggest difference between Next JS and Remix.

In Next JS you have to understand a whole mechanism with its own logic, between getStaticProps and getStaticPaths and getServerSideProps.

And these methods are causing some questions and confusion in the various forums and groups I have consulted. Questions that show that the role and context of these functions is not clear to everyone.

Remix, on the other hand, simplifies. Not at the technical level, but at the conceptual level.

Routing is built from the file tree. Data retrieval and submission are grouped with the components that submit them, not in a separate API folder. And by the way, form submission does not use specific code or methods but HTML standards.

This allows Remix to say that there is no n-th framework to learn, but simply normal and standard HTML form operations or basic JS functions.

That it is therefore a good investment in time to learn this framework, since it is not specific.

And that this is what allows Remix to work even in client environments where JavaScript is disabled.

But all these advantages come with some disadvantages.

For me, in the way I use it, one of the big advantages of Next JS is its ability to generate static HTML.

And this static HTML will then take on a dynamic behaviour thanks to React.

And unfortunately Remix doesn't allow that.

For my personal use case, today, Next JS does the job well, and Remix would not meet my needs. Maybe one day, but for the moment it is too young for that.

But on the other hand Remix is cleaner, more modern, better designed, with less specific functionality. AND it anticipates the new features of React.

Which means that today, if I'm asked which one to learn, I'd tend to recommend Remix, on average.

Even if it looks - it's true - a bit like "do as I say, not as I do".

And then, let's be honest, Next JS remains a very good choice. And the presence of a bit of competition can only encourage it to improve further.

In short, this is an exciting environment that is constantly evolving.

So if you want to keep learning, well, we'll see you in this next video.