I never understood the appeal of React Router, the simplest library to get rewritten 5+ times, each time forcing their users to learn a new way of doing routing. It never worked that well either in my experience. The authors seemed addicted to churn and complexity.<p>I do enjoy Remix though. It works well and the various stacks help you get started pretty quickly. So why take the framework that's well respected and loved, and combine it with the library that's known for its churn? That seems like a lose-lose. You create yet another change for people still on React Router and lose the Remix brand.<p>Did the Vercel people manage to execute a psyop on Remix? This doesn't feel like the move.
As someone who has used react-router before and is currently evaluating Remix for a different project, I didn't realize just how thin that layer has become. I suppose there's a ton of features in react-router I never touched.<p>From a marketing perspective, I'm not sure if it's genius or insane. It's going to get a lot of people on the platform currently called Remix, but I also feel like Remix has built a strong brand and not having a project that uses it explicitly feels ... suboptimal.
Fwiw I recently started using wouter (<a href="https://github.com/molefrog/wouter">https://github.com/molefrog/wouter</a>) and it works great for me, I'm not sure why react-router is so big and has so many other features. I took a look at it but didn't understand it and wouter seems to be working fine for my simple needs (go to different pages, link between them, parse params/)
I think this is a good direction for Remix and makes me more inclined to start using it in the future. There'll no doubt be some people left confused by the branding changes, but in the long run, it's probably a good move.<p>I used to use react-router many years ago, but I eventually got fed up with the breaking changes and switched to wouter for most projects. It's much simpler and I rarely have to think about it.<p>Remix was interesting. but since I also had native mobile apps using the same backend as my webapps, I just wasn't interested in running a whole other backend in between the webapp and my API. SSG and some SSR capabilities easily deployed to a serverless runtime would be nice, but I'm completely uninterested in RSC or a server runtime for my webapps at all. When Remix SPA mode was announced, I was intrigued, but couldn't really see what Remix did for me beyond what I already had setup with Vite + Wouter.
I feel like this announcement could use a more clear summary of the key point at the top.<p>It sounds like Remix will be discontinued and anyone using it will need to upgrade to React Router? Is that not going to be super super confusing?
> Remix is specifically designed to run in any JavaScript environment so that you own your stack. It is expected many —if not most— production apps will have their own server.<p>Mmm.<p>I'm know that technically remix supports static builds (1), but it feels like a bait and switch to turn a client side library into a server side framework.<p>Am I cynical in think perhaps there were two projects and one of them was more popular than the other (like, 2x more popular say...), so maybe if we take the unpopular package <i>merge it to the popular one</i> people will not notice and we can just pretend we only have one popular package?<p>Maybe we should just merge all the packages in npm into one package called 'all'. That would be soooo popular, great victory!<p>I'm joking; but taking this to the extreme makes the point; this is unabashed and unwanted bloat for people who just wanted react router; if people wanted remix, they would use remix. If you don't want to maintain two packages, don't; but this is a bit :|<p>> and now Remix and React Router are basically the same thing<p>Mm. That's not how I would describe the difference between a <i>server side framework</i> and a <i>client side one</i>.<p>[1] - <a href="https://remix.run/docs/en/main/guides/spa-mode" rel="nofollow">https://remix.run/docs/en/main/guides/spa-mode</a>
We still can't upgrade past v5 because our apps do "unconventional" things like ... have a stable list of full-pathed routes that are type checked, while v6's child routes don't support full-paths.<p><a href="https://github.com/remix-run/react-router/discussions/10288">https://github.com/remix-run/react-router/discussions/10288</a>
If you want a tiny (90+% smaller) React Router alternative that is stable and works nicely with hooks, while having a similar syntax, please try my own Crossroad:<p><a href="https://crossroad.page/" rel="nofollow">https://crossroad.page/</a>
If you've already changed your build system to Vite (a breaking change to any app started before Vite), and opted in to all current "future flags" (breaking changes), and multiple forthcoming future flags before 7.0, then you will have no breaking changes. And let's not forget its history, including the previous merge with Remix. The only lib moving even faster is Next. Both are highly focused on PR at the expense of accuracy and good faith.
While Remix seems a bit more reasonable than some other js frameworks, they all share the same problem: fundamental architecture.<p>What's even weirder is that they could copy the structure from dozens of other frameworks, some of which are nearly 20 years old now, which have solved pretty much every possible problem already.<p>But no, just throw views,data, io, auth checks etc. everywhere and hope it builds.
It’s funny because I dropped in on their Discord today for help debugging an app and there was a lively discussion I joined in to get their attention.<p>Looking at it closely I think the latest version of the react-router is
better than previous ones, I upgraded the particular app I was working on because it is busted anyway and not very big but I can think of two or three other apps using RR I maintain that I am not going to upgrade any time soon, particularly some of those use class based components which won’t do the best with the current hook API anyway.<p>I see the appeal of the matching client-server environment it is a dream the web industry has been pursuing since 1998 or so but we already have a server and don’t need a new one.
My guess is that Remix is not getting the traction they expect and want to leverage React Router's installed base. I often see Next.js in job opportunities but rarely see Remix. Ryan's announcement demo was good.
Remix is a great framework and I recommended it over Next.js. Also, pay no attention to all the haters here, it's just the usual anti-React HN mindset.
Cool to see this going smoothly. The only thing I’m scratching my head about is “RSC (soon)”. That’s a big question mark that I would’ve liked to see more info on in this announcement. Things like “use client” and “use server” are have implications for actions and loaders.
Yet another mess, once again.<p>All of this just so that they can brag that their framework has more stars/downloads than Next.js, because there's no other reason to do this than to "show" who's more popular.<p>And while it's true react-router has a shitload of downloads, most of those downloads are for really old versions, because people can't update due to all the constant rewrites and changes of APIs. I've seen this at 3 companies already, nobody is using the latest versions.<p>NPM should show download metrics by version (as packagist does for PHP packages). I'm convinced this will prove it.<p>But hey, this works. Now they have more downloads than Next so let's use this instead.<p>(BTW, Remix was still a better option than Next in my opinion, but that's a super low bar)