When remix.run is better than NextJS - Next vs Remix
TLDR: When you need to do data mutations without relying on running JS on the client side.
I first heard about Remix in a Fireship video. I didn’t pay much attention to it and ignored all the non-nextjs meta frameworks for React.
As of writing this, both Next and Remix are in a weird position. With Next, you can’t be sure to use the beta app directory or the traditional pages directory. For Remix, you can use the “v2” features by using specific flags in the config file (which are on by default).
Under usual requirements I always prefer NextJS. Still on the traditional pages directory, just to be safe.
But a project that required no JavaScript on the end client’s browser came up.
Remix turned out to be perfect for that and is in use for that project, the client is happy, and I’m happy.
Why not NextJS?
- Next is excellent for SSR and querying data without relying on the client. However, for mutations, you kind of have to use JS on the client.
- I tried to use API routes’ URLs in HTML form actions but it just doesn’t work.
Why Remix?
loader
&action
for each route is perfect for getting and setting data via traditional HTML forms.- I was able to build a fully functional react-based site without relying on client-side JS.
Final thoughts
I really didn’t want to do a No client-side JS project as I’m a JS dev. It felt counterintuitive to use traditional forms and sessions with modern JS frameworks. Anyway, I had to do it and Remix made it fun.
I used Zustand for global stage management (I could use it with .getState()
in the loader
and action
functions).
Remix is good, you should try it.