Yesterday I published A First Look at Remix.run
Since then, I keep getting the question of "How is Remix different from Next.js" (which is a good question since they share "some" of the same ideas).
I've only been using Remix for a day or so, but I've been chatting with Michael and Ryan about it and can speak to what I know so far (and these answer will evolve over time). I also will evolve this answer based on the answers provided in this thread and that I see over time in other forms / discussion areas. (Disclaimer - this is my opinion!)
The differences
I think the main differentiators are here:
1. Nested routes
One large difference is how the routing works. Nested routes and params are supported in Remix, and "are a critical idea to understand in Remix" (according to the docs).
Using an Outlet from React Router Dom, you can build out a hierarchy of nested routes with a pretty simple to use API.
These nested routes are server-rendered, bringing to the table almost a hybrid of SPA and SSR that is completely new.
Routing (and the API behind it in general) also works a lot differently than with Next.js.
2. Complete control over the request from an SSR route
You have a lot of control over the data returned for a route – having full control over the responses (including sending cache control headers).
If you set cache headers on your responses, when the user visits the same route, it wont' even fetch the data, it'll use the cache. And if you put a CDN in front of your server, the server will rarely actually handle the requests because the CDN will have it cached.
Here is some info directly from their docs.
3. There is no SSG
Is it better / worse?
I really don't think the question is if it's better or worse.
I think the real answer is that it's different and IMO doesn't really serve the exact same use cases. To me, it's closer to a replacement for doing stuff like what Rails, Django, or Laravel does but using React and with more cache control and flexibility – almost like a hybrid between SPA and SSR?
It seems well suited for an app with highly dynamic data, especially for sites with a large number of pages.
More to come, but I look forward to hearing the discussion and evolving my opinion and answer!
Top comments (15)
Mannn, I was waiting for a post like this, I saw a comment regarding Nested Routing and thought it was pretty cool. The pattern I use nowadays with Next is to have a Layout component and a Provider (using the context API) component, the Layout will be responsible for (literally) the general layout and the Provider will be responsible for storing any state and it's pretty complex.
The more I read about it, the more I feel like Remix is trying to take a whole other approach to plug the holes in React. NextJS is/has been doing a great job for a long time so it's definitely cool to see how Remix turns out. IMHO they should at least opensource the docs, so folks don't have to literally pay $250 to know what Remix offers. I ranted about this in your previous post too, so I'm sorry if it's too much lol
PS: It's really awesome that you're doing this for the community though! Maybe turn it into a newsletter? I'd definitely subscribe
Thing to remember is that we're not done, this is a "Supporter Preview Releases" not a production ready product yet. It's more of a kickstarter. Public docs would be great for some, but would also attract people that would just distract and irritate. We have millions of OSS users, so we know what can happen with something new :P
We only expect a handful of our Remix development newsletter subscribers to buy right now. They've been hearing about it for a few months. When we release the 1.0 we'll have compelling demos, documentation, and a free evaluation period. But that's now what we need right now. We need a group of supporters to help us kick the tires.
I see, that makes me feel relieved. I got pretty excited yesterday after reading this post so I might buy a license for myself to take a look at all the fun stuff :)
Maybe there is concern that people will copy it too quickly. I mean the nested routing for one is older tech with a few improvements. There are other libraries doing similar things. It's possible that in a couple weeks we will see options to bring this sort of stuff into Next etc.
I agree re: docs. $250 is not a lot for some people, but a significant investment for others, so not really knowing what you're getting into will probably (imo) lead to even less sales for them.
A little context. The current release is a "Supporter Preview". We aren't trying to get large adoption and actually have a limit on the number of licenses. It's still too early to compare to Next.js I think.
But yeah, nested routes are a big part of it. Another focus of ours is being able to sneak into existing stacks and growing, rather than owning the app and deployment (Next apps are best on Vercel). After a couple more features are built, there will be more to talk about, but it's really too early to make solid distinctions.
I'd like to emphasize though, we're not "coming for Next", and we actually think Next is a great framework. Additionally, we're working with Vercel for a zero config deployment of Remix apps to Vercel.
Our target is the millions of React Router apps out there, not Next.
i like the boldness of their approach here. you don't NEED an SSG if you do caching right. the trick is to do caching right. Netlify bets against it, MJ and Ryan are betting for it.
Yeah I've been thinking more and more about this, but I think you've summed it up really well here.
Zoom back a bit and it's all just caching :-D
SSGs just say treat caching/data-invalidation as a build-time concern (like code changes) not as a run-time concern as then you're not dealing w/ bugs w/ caching in a production environment. It's safer and easier to update your data cache through a build process. This of course doesn't always scale but for small to medium sites it's very nice.
in next all you need to do is call
res.setHeader('Cache-Control', 's-maxage=60, stale-while-revalidate')to set the header.
Isn't this header native to Vercel though? Regardless, you can still accomplish this to a certain extent using a data fetching library like useSWR, no?
Ah interesting, thanks for this. I'll also update the post with more info directly from the docs to add more context around how to manage the response.
I've been so out of the loop. I assumed everyone had routing solutions like this already. This nested routing technique originated in Ember Router back in 2012 to the best of my knowledge. Since then Vue and Nuxt Router are based on this but I guess it makes sense it hasn't really come into the React ecosystem (except way back in React Router 1.0 I think). With a VDOM you can sort hand waive about the rerendering the top level of the page where you don't have that with reactive libraries that have to repay the creation cost.
I also didn't realize that other libraries weren't server rendering these nested routes. The real question though that I pose as someone who has been using these techniques in my libraries for years. Has remix solved the cascading data issue usually associated with these patterns. I guess from a server only perspective it's trivial, but on the client it means breaking apart the data and the component view code so that the view code can be code split but the data loading happens on the main chunk. Then it's just a matter of good render-as-you-fetch patterns.
I'm not here to solicit though, I'm just generally interested in learning about ReMix and it feels like a lot of things I would have assumed already existing in the React ecosystem are showing up here for the first time and that's exciting.
Great question about data and nested routes. We've done some smart optimizations around that (well, I think they're smart anyway!).
If the layout persists between route transitions, then the resources for those layouts are not refetched, only the changed routes resources are fetched.
Also, the data, code split route module, and styles are fetched in parallel. We don't need the module to know the data, because our server already knows the hierarchy.
I'm trying to wrap my head around use case. I'm not a developer; just a guy trying to build better websites for my own businesses. I became an SSG fan after being frustrated with my WP site that was slow and got hacked despite my efforts. I discovered Jekyll then Gatsby and Next.
That as background, I've discovered all of this JavaScript based SSG/SSR, etc. builders and love them. I've grokked enough JS over the years to understand the basics and I see the huge potential for others like me who are frustrated with those monolithic builders.
But, until yesterday, I believed that SSGs were the best alternative. After reading a lot and watching a handful of YT videos, I'm seeing Remix as a possible better solution.
So, for a small business or maybe a nonprofit organization that needs more than an online brochure website, but not a full blown highly dynamic web app for the business ... is Remix an appropriate option? Or is Next the better way to go?
Remix, what I've seen after discovering it 24 hours ago, looks better because it seems to require less deep level JS ... e.g., the getStaticPaths in Next screwed me up; I struggled to connect it to my Sanity backend. Remix seems to handle this in a more direct ("simpler" is the right word but it's close) way.
Thoughts?
And thanks for the article. It was a big help in my understanding Remix.