Haven't heard of Remix, will give it a try. One thing that bugs me with Next.js is the missing data mutations part that Remix claims to address. When I setup my next.js project and was fetching data via getServerSideProps I was impressed. Until I realised there is zero support for mutating data. As soon as I need a single POST/PUT request, next.js support ends and you are back to writing your own fetch() code. It somewhat felt as if developers ended their day there, as you would definitely expect something that allows you to send data from the client to the server.
Remix's approach to fetching is unique and compelling for Rest APIs.
However, if you're working with a GraphQL API, you can eliminate all these much-mentioned fetch waterfall issues by using Relay as a client... Relay inspects the data needs of all your page's components and compiles them to a single page query. Relay also has a number of nice developer interfaces for common/annoying problems like pagination that I don't think are possible w/ Remix's approach.
This article is informative, but I think it misleadingly implies that you can't avoid waterfall fetches in Next (or that it only might be possible someday w/ React Server Components)... you can.
I started to use Remix and I love it, the nested routes / layouts is the most powerful feature for me. Also, the API is easier and cleaner than Next and the hooks to consume the data is a nice approach as well.
I agree. Part of what my team likes about next is that although it doesn’t get everything perfect, it’s generally close enough and otherwise often within the realm of customization when it counts.
The only exception might be the router. I’ve found it a little limited at times and there’s no way around it. This is one of remix’s apparent strengths, but it’s insanely comprehensive. I wonder if it might be too much in the other direction.
Thanks for this comment. It pushed me to take a closer look, and so far I'm really impressed. I'll definitely give this more of a chance. The Remix team has a solid grasp on the request waterfall and how to reliably optimize page loads. I have no doubt that Vercel will optimize this in Next as well, but as long as their router is so limited I don't see how they can compete on optimizing dynamic content. It'll be interested to see how it shakes out!
Simplification in this case means, it gets out of your way. The API surface is incredibly small. You have actually more flexibility than you do in Next.js with its proprietary methods.
Note that this is an effort largely driven by the React team, and Vercel is integrating support for the feature into Next. You're able to do this without Next:
