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:
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.
I submitted a feature request for a "transporter" function that would do exactly this. Didn't get much traction.
https://github.com/vercel/next.js/discussions/31136
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.
GraphQL comes with its own set of headaches though, especially if you're the person responsible for implementing the server.
Exactly.
Plus, if you're using something like Remix, you don't need an API layer anymore. The data goes from the query straight into the view.
I’ve been pretty deep into next js for a while. I’m excited to give Remix a try.
Very big fan of fly.io as well, they’re smart folks and I run every service I can on them.
The "pros" for nextjs seem believable, a non-bias piece /s
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.
remix talks about too much simplification. Too much simplification scares me.
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.
I spent a weekend playing around with Remix, and it didn't fail to deliver. I don't think you have anything to worry about.
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.
Glad to see someone not focused on frontend.
Frontends are incredibly bloated already and next.js embedding react in any page is a killer for static websites.
This is a frontend framework? It still uses React on the frontend?
Next is alpha-testing something which will allow for JS-free static sites, though they're generated using React on the server.
https://nextjs.org/blog/next-12#react-server-components
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:
https://reactjs.org/blog/2020/12/21/data-fetching-with-react...
It's early still, but I imagine this will be an established and well-supported feature by the end of the year.