Replies: 10 comments 29 replies
-
|
It wouldn't make sense to keep 2 names for the same thing. People writing blog posts, making YouTube videos, etc. would always have to refer to both names for SEO. On the other hand, people searching for articles and videos would also always have to search for both names. And then you have 2 documentations, 2 websites, 2 repos with duplicated issues, etc. Only difference between Remix and React Router was the Vite plugin. React Router was a library, Remix was a framework, but React 19 can't be fully used if you don't have a framework to implement the RSC stuff. What should they do? Keep React Router incompatible with RSC? Convince React Router users to migrate to Remix and abandon the brand that took a whole decade for them to build? Let's be honest, there simply wasn't any path forward without its trade-offs. They took the pragmatic choice. The only downside from this choice is that for some time people will be confused (TBH, I don't understand why people find it so confusing), but it's a temporary problem affecting only Remix users (which is only a fraction compared to all React Router users) and that will fade away with time — while all other choices would be permanent source of problems.
That's certainly not the idea. There's rumor they'll reuse the Remix name in the future for a completely new thing. I'm particularly hoping it's a Rails-like backend framework, but no idea. |
Beta Was this translation helpful? Give feedback.
-
Yes and that is also really confusing. The ECMAScript name was an unfortunate result of trademark issues. Not at all like the Remix decision. Anyway, I understand what you're saying, but I disagree with your conclusion. I think the name matters. I think that telling people to migrate off Remix while also keeping that name around to possibly become something entirely different is confusing. I think at the very least, if the plan is to move people off Remix to react-router, then Remix should be ended. I think that the decision to sort of park the name to maybe reuse it for something entirely different later is even more unnecessary and not good for us users. |
Beta Was this translation helpful? Give feedback.
-
I mean, both are cases of a single thing having 2 names; of course, for very different reasons.
That's why the React Router name was the pragmatic choice. It's much more well known name. It would take them another decade to have any chance of making the Remix name as well known as the React Router name already is.
Particularly, I don't care if they release the new thing as "Remix v3", but I wouldn't be surprised if they decided to name it something else (Reverb? literally-everything? lol). |
Beta Was this translation helpful? Give feedback.
-
|
Another way to look at it is that Remix had its own, clear identity that was free of React Router's history and this allowed the Remix project to forge its own path and focus on the needs of Remix users. Now it's being swallowed by a much larger community that may have different needs and priorities. And it's causing some confusion in the process. But I can see how it's easier for the maintainers to do this and why they would want to prioritize a larger community over a smaller one. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, they wouldn't have the freedom to experiment all the new ideas if they didn't start a separate project. But many of the ideas were adopted by React itself, so there isn't a lot left to experiment regarding data and routing. Merging back into React Router means we still have what we like in Remix, but now in a much larger ecosystem, with many more people filling issues, contributing to its stability, building libraries around it, etc. |
Beta Was this translation helpful? Give feedback.
-
|
Well, its certainly possible to call it different names - Tanstack is doing this with router (library) and start (framework) They even explain it clearly here https://tanstack.com/router/latest/docs/framework/react/start/overview#router-or-start When RR team says "no breaking changes" it is not the case as users have to rename imports to nee @React-router scope and community have to rename packages.. |
Beta Was this translation helpful? Give feedback.
-
|
fwiw I think Remix is an amazing project and y'all did fantastic work and I'm thankful for that :) |
Beta Was this translation helpful? Give feedback.
-
|
I'm very confused now, should I use that codemod to give up remix completely right now? I don't think any project team would continue to use a framework that has an uncertain future, is being abandoned, and doesn't know when it will be picked up again. Unless the team has a clear roadmap for the future of Remix, which it doesn't seem to have at the moment, then it should be reasonable to assume there won't be a v3 anymore. And the fact that codemod can't solve anything except help us some simple replace job, with make lots errors. Going from remix to RR7 seems to require a lot of refactoring, but I don't even know which site to open if I want to look up references/docs. What a huge disaster. |
Beta Was this translation helpful? Give feedback.
-
People are not supposed to keep using Remix. Quite the opposite. The idea is exactly that, once you have all future flags enabled, change your imports to RR7. It's really that simple. There's literally nothing else besides this. The software is the same, just with a different name. It was called Remix, now it's called React Router. |
Beta Was this translation helpful? Give feedback.
-
|
I think we can all pretty much agree that both RR7 and Remix are excellent. And if they're already so similar, a merge makes sense. But! The problem is the suddenness, haste, and lack of transparency. The team gave us high expectations for Remix v3 from the middle of the year, and now this sudden betrayal is hurting the supporters of this hard-to-establish brand in some way, and it's not wise to deliberately ignore and underestimate this impact. |
Beta Was this translation helpful? Give feedback.
-
|
But it's really just a name change. Only the name "Remix v3" was abandoned. The thing that that name references wasn't. |
Beta Was this translation helpful? Give feedback.
-
|
It's not just the name / import change, configs and clis have changed as well! That said, I still like it and will continue using it, won't recommend it though, at least not until the dust settles. |
Beta Was this translation helpful? Give feedback.
-
Changing the name of the project implies renaming things like the CLI from
I'd rather not have a new file too, but this has no relation to the name change. It would just be called
True. OTOH, it's hard to improve something if you can't change what you need to change to improve it. 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
I migrated 5 od my smaller (10 routes) remix v2 apps to react router 7 in a matter of minutes. First migration took maybe 40min, next one was 15min. Will try and update another bigger app (40 routes) shortly, but I am pretty confident, it wont take more than 2 or 3h, because I used programatic routes instead of file based routing. I love what the Remix/React Router team is doing. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I’m a bit confused about this too. React Router has always been about providing solid routing solutions, but now it seems to be moving more towards a framework-style approach. Based on the name, I feel like React Router should stick to its core purpose—routing—and leave the framework stuff to Remix. What do you guys think about this direction? |
Beta Was this translation helpful? Give feedback.
-
|
If I understand correctly, that's not a possible direction in the paradigm of React v19 as only a framework can implement RSC. |
Beta Was this translation helpful? Give feedback.
-
|
Weighing in a bit late but I feel like this might really hurt discoverability and developer experience. But there wasn't really any competition doing things better so 🤷 Note: This is by no means a jab at the decisions which have been taken. Just feedback |
Beta Was this translation helpful? Give feedback.
-
|
This was caused by Remix and React Router being mostly similar things. In many occasions, the documentation of Remix would just point to the documentation of React Router because some features were just re-exports. Unifying them is actually the solution. |
Beta Was this translation helpful? Give feedback.
-
|
I understand your point of view. But the docs are by no means the only source of help. I think you had a tough decision to make and you made it. I don't think I agree with the decision but that's fine. I don't have the years of experience working on the repo that you guys do ;) |
Beta Was this translation helpful? Give feedback.
-
The same problem would happen with articles, etc. People using Remix would write articles that should be helpful to React Router users and vice-versa, but they'd not reach the 2 audiences because of the two different names. As a writer, you'd frequently have to include both "Remix" and "React Router" for SEO; as a reader, you'd frequently have to do each search with the 2 terms as well. Unifying into a single name will heal this, but it will take some time. Also worth mentioning React Router would probably not be able to adopt the new RSC paradigm introduced by React v19 without a compiler — and the lack of a compiler was essentially the only difference between React Router and Remix. PS: I'm not part of the team, just echoing what I can understand from their motivations. |
Beta Was this translation helpful? Give feedback.
-
|
First off, let's be honest. The path forward is set, so this is probably a moot discussion. But that said, I tend to agree with the frustrations and confusion around it. I can't help but feel like the wools being pulled over a bit... They needed to give CRA + RR users a bridge to modern React (or abandon that massive user base). I guess RR is too prevalent to deprecate in favor of Remix, so they went the other direction. As a Remix user, Remix is the modern React tool, so that is a little frustrating, but I get it. The React ecosystem changed since Remix became a thing, and that has implications on the future of RR, and it's users. But is mitigating the impact on RR users vs Remix users the full story? What makes me feel uneasy are the vague hints of what is to come for the "Remix" name. The team wants to release a new meta/fullstack framework for the modern era, continuing this ethos of the "Remix" product filling that role. In other words, as a Remix user, who adopted with the idea that I was on this team's flagship product, how could I not feel like this tool is being deprecated if it's merging into the legacy tool, and there is plans to release a new product under "Remix"? We don't know what they actually have planned for "Remix" and thats the exact problem. Maybe it's something I'd never want to use... or maybe it is going to be what I thought I'm building my app rewrite on now - the teams flagship full stack framework. I guess I just have to keep my head down and continue building my rewrite on a decade old Frankenstein library and hope we shouldn't have used NextJS way back when. |
Beta Was this translation helpful? Give feedback.
-
|
I think it would be cool if the new Remix were a Rails-like framework. It would still be something that complements React Router, including more cool stuff built around it. OTOH, if the new Remix is just a bunch of utility libraries, it will feel weird to me too. |
Beta Was this translation helpful? Give feedback.
-
|
Fwiw I'm currently picking a tech stack for greenfield dashboard project at our company, Remix would be my top choice, but now it's going to the bottom of the list. Reason: It's very difficult to explain to my team and managers what it is. The Remix site is very convincing and understandable for it's benefits over competitors, but now I have to tell stakeholders we'd actually be using Router 7, which succeeds Remix, but has a different name, but is actually the same thing, oh and yeah the website isn't as good, just look the Remix one. It's a mess. Obviously people will look at Next.js and say "I want that one". |
Beta Was this translation helpful? Give feedback.
-
|
The first and fourth options would mean abandoning a brand that took a decade to build. The Remix brand would probably never become as popular as RR already is given there are many competitors these days. With time, the differences between RR and Remix would accumulate and more RR users would start migrating to other solutions instead of Remix when they want to try RSC. RR would perish and Remix would probably never fill its position. The choice they made means RR, a decade-old piece of software, is now ready to be useful for another decade. It also means that the software we used to call Remix will have a lot more users. With more users, it will have more people battle-testing it, identifying edge cases, and submitting issues and PRs. |
Beta Was this translation helpful? Give feedback.
-
|
@gustavopch I'm glad you joined the discussion to give us an indirect idea of what the dev team thinks. But I don't understand why dev team is absent in this thread, as hiding behind you to avoid coming to this question that is difficult to answer by themself |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, good point, I'm giving my opinion as a user, so don't take it as any kind of semi-official answer. I don't think they're exactly "hiding behind me" because TBH, I don't even think they're aware of this discussion. 😅 I'd also like them to show up and give an official answer to either corroborate or correct my points — and also explain what's planned for Remix v3, which we know will exist as a "new thing". |
Beta Was this translation helpful? Give feedback.
-
|
@gustavopch Could have also kept ‘react-router’ for everything in browser runtime and instead of inventing @React-router scope use them under @remix-run, like @remix-run/vite-plugin. being a npm scope means it could also host things like multipart parser or reverb alongside vite plugin. this is exactly what tanstack router/start is doing. |
Beta Was this translation helpful? Give feedback.
-
|
@anon-ghub vanillajs will remain stable ;) https://github.com/quantuminformation/vanillajs-patterns |
Beta Was this translation helpful? Give feedback.
-
|
Remix is owned by Shopify now. I don't think they will easily give up that brand. For who too lazy to read, here is the main points:
|
Beta Was this translation helpful? Give feedback.
-
|
There's now an official blogpost about the future of Remix: https://remix.run/blog/wake-up-remix |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like a lot of work! May their path be free of bugs and other critters. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I get that all the functionality you want is now supported in react router v7, but I don't understand why this has to mean "abandoning" the Remix name and orphaning the ecosystem that has evolved around it?
It feels to me like this is going to generate a lot of unnecessary confusion that could be avoided by continuing to support the Remix name.
As someone who just recently adopted Remix v2, I feel so confused by this decision.
What's even more confusing is that the plan is to later return to the Remix name at some future date?
So you're asking Remix adopters to migrate
Remix -> React Router -> Remixat some future date? Or are you going to turn "Remix" into something else? It's a weird identify crisis.As mentioned in the blog post
Most of Remix was already a thin wrapper over React Router. So why not simply continue wrapping React Router with Remix for v3? If you're not actually ending the Remix project, wouldn't this make it less confusing when you eventually release the next iteration of Remix that is once again different from React Router?
TLDR; I feel like this decision isn't appreciating the value of the name "Remix" and the ecosystem and SEO that has evolved around that name and I as as a "Remix" user feel abandoned.
Beta Was this translation helpful? Give feedback.
All reactions