8 ms·

Merging Remix and React Router

107 points by 0xedb 2y ago

CSSer 2y ago
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.
Cu3PO42 2y ago
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. 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.
- blovescoffee 2y ago
  Agreed. We're evaluating remix at work to use on a rewrite project and this seems like it will make it harder to adopt - and harder to cast as an alternative to next.js
  - zackify 2y ago
    It’s just a global find and replace after the update though.
peter_l_downs 2y ago
Fwiw I recently started using wouter (https://github.com/molefrog/wouter https://github.com/molefrog/wouter) 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/)
- nsonha 2y ago
  I think what react-router tries to solve is esentialy navigating without re-rendering layout partials
- floydnoel 2y ago
  Cool to see some alternatives around! I didn't like React Router's bloat either, and wrote my own. Besides having no dependencies, my router also focuses on making it easy to handle common SEO requirements like generating a sitemap or handling open graph tags. Routerino: https://github.com/nerds-with-keyboards/routerino https://github.com/nerds-with-keyboards/routerino
a_random_canuck 2y ago
I feel like this announcement could use a more clear summary of the key point at the top. 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?
- jeffwiederkehr 2y ago
  I have the same question/confusion. I'm not sure what the benefit is of merging the projects? I get they are very close feature wise but why physically combine and make Remix features an opt in vite plugin vs just keeping the projects separate repos?
  - dcre 2y ago
    Remix is already essentially a Vite plugin + React Router. That change was started at least 9 months ago and went stable 3 months ago. https://remix.run/blog/remix-heart-vite https://remix.run/blog/remix-heart-vite https://remix.run/blog/remix-vite-stable https://remix.run/blog/remix-vite-stable At this point the separation between the two projects is seeming more and more like a lot of rigmarole for nothing. Imagine running two projects that are 90% the same, and every time you change one you have to make a release and update the other, etc etc.
lazlo_kovacs 2y ago
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. 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. Did the Vercel people manage to execute a psyop on Remix? This doesn't feel like the move.
- azemetre 2y ago
  I don't know if you're aware but the authors of both libraries (react router, remix) are the same two core developers. I do find their open source libraries a good juxtaposition of engineering philosophy for the tanstack ecosystem. Tanstack seems to favor making things modular over time so it's easier to create bindings in other libraries while also increasing the enhancements whereas it feels like Ryan Florence and Michael Jackson prefer to get features out faster even if it means throwing away previous code. I feel like I'd still be using tanstack/router, tanstack/table, and tanstack/query in 2030 compared to even react itself.
  - lazlo_kovacs 2y ago
    Yes, I'm well aware. To be honest I was pleasantly surprised with Remix because of my negative experiences with React Router. But now it seems like they've gone back to churn and cheery messages claiming that this is the best iteration, just please ignore the last 4 attempts.
    - mirthflat83 2y ago
      I feel the exact same way.
- gedy 2y ago
  > 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. Yeah I hate to be negative, but honestly I was a lot less excited about Remix once I found out was react-router team. While serving a useful need and I appreciate their work, using react-router in a large production app (MPA) was series of frustrating updates and rewrites once we needed to update (we did not have luxury of just leaving old code as is). The iterative churn and rethinking of design scared us off from Remix for the time being.
PaulHoule 2y ago
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. 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. 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.
fish55 2y ago
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.
- ryandvm 2y ago
  I've been writing code for 20+ years and I did not recognize a single product you mentioned. I am so glad I got off the front end treadmill. If you need me I'll be over here writing APIs using the same stack I was using 5 years ago.
  - halfmatthalfcat 2y ago
    So brave. Thank you for your contribution.
  - drawfloat 2y ago
    You don’t need to know every Astro and Remix, but not even knowing what Vite and Next are as a FEer in 2024 is not exactly something to shout about. If you don’t need to, fine, but also understand it just sounds ignorant given their size and many years of news around them.
    - deleted 2y ago
      [deleted]
  - deleted 2y ago
    [deleted]
  - throwaway11460 2y ago
    I still use the same tools I used when I started with React 10 years ago. You don't need to get on the treadmill, you chose that.
franciscop 2y ago
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: https://crossroad.page/ https://crossroad.page/
pier25 2y ago
Didn't Shopify buy Remix?
- 0xblinq 2y ago
  yes https://remix.run/blog/remixing-shopify https://remix.run/blog/remixing-shopify
- dbbk 2y ago
  This is in the article
0xblinq 2y ago
Yet another mess, once again. 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. 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. NPM should show download metrics by version (as packagist does for PHP packages). I'm convinced this will prove it. But hey, this works. Now they have more downloads than Next so let's use this instead. (BTW, Remix was still a better option than Next in my opinion, but that's a super low bar)
- dcre 2y ago
  npm does show last 7 days download metrics by version! https://www.npmjs.com/package/react-router-dom?activeTab=versions https://www.npmjs.com/package/react-router-dom?activeTab=ver... As it happens, I was curious about the same thing last year and wrote a script you can run in the browser console to add them up, and it does prove something: react-router-dom v6 5820458 v5 3274886 v4 275081 react-router v6 5993187 v5 3366625 v4 302549 v3 156121 v2 25726 v1 8448 v0 2447 Code here: versionsHeader = Array.from(document.querySelectorAll("h3")).find( (h3) => h3.textContent === "Version History", ); // requires a second .nextElementSibling for react-router // because of the deprecated versions checkbox versions = versionsHeader ? versionsHeader.nextElementSibling : null; nums = Array.from(versions.children) .slice(1) .map((el) => [ el.children[0].textContent, parseInt(el.children[2].textContent.replace(/,/g, ""), 10), ]); for (const v of [6, 5, 4]) { const sum = nums .filter((c) => c[0].startsWith(`${v}.`)) .map((c) => c[1]) .reduce((a, b) => a + b, 0); console.log(`v${v}`, sum); }
  - theplatman 2y ago
    I would say it’s a bad sign that 40-50% of the user base is already one version behind as you’re releasing v7. This comparison ignores reach router, which was the other replacement for react router by that same team before they abandoned it for remix. That still has 600k downloads so now you’re nearly at 50:50. There’s a reason why many front end devs have stayed away react router and the associated libraries since 2016/2017 because this team has lost a lot of good will for the number of times they’ve done major overhauls of their projects.
bilalq 2y ago
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. 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. 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.
wokwokwok 2y ago
> 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. Mmm. 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. 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 merge it to the popular one people will not notice and we can just pretend we only have one popular package? Maybe we should just merge all the packages in npm into one package called 'all'. That would be soooo popular, great victory! 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 :| > and now Remix and React Router are basically the same thing Mm. That's not how I would describe the difference between a server side framework and a client side one. [1] - https://remix.run/docs/en/main/guides/spa-mode https://remix.run/docs/en/main/guides/spa-mode
- dcre 2y ago
  The difference in popularity is more like 40x, which makes your theory obviously correct, and it also makes it a no-brainer for the devs. The server-side aspect is opt-in and someone currently using react router v6 (with v7 future flags on) will not need to make any code changes when upgrading to v7. How could a new server magically appear in your application?
- tjosepo 2y ago
  > it feels like a bait and switch to turn a client side library into a server side framework And I think that's exactly what the React ecosystem needs right now. There has been a growing split between client-side React and server-side React, with most existing React applications being client-side with no easy path to server-side that didn't involve a full app rewrite in Next.js or Remix. The new React Router Vite plugin is that easy path to server-side React that people were looking for. If you're using React Router (like most client-side applications do), you're already 90% of the way there.
randomdev3 2y ago
While Remix seems a bit more reasonable than some other js frameworks, they all share the same problem: fundamental architecture. 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. But no, just throw views,data, io, auth checks etc. everywhere and hope it builds.
- BillyTheKing 2y ago
  what's wrong with Remix's fundamental architecture? I mean.. I generally also think that the overall state of the JS ecosystem is broken, but that's due to JS tooling modules vs commonJS etc (hope bun fixes all that). But as a backend-dev who primarily writes Go I round remix easy and simple to pick up and get started with when I had to use it this year.
clivestaples 2y ago
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.
c-hendricks 2y ago
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. https://github.com/remix-run/react-router/discussions/10288 https://github.com/remix-run/react-router/discussions/10288
jakubmazanec 2y ago
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.
gardenhedge 2y ago
So is React Router a framework? Confusing.

107 points by 0xedb 2y ago

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.

Cu3PO42 2y ago

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. 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.

blovescoffee 2y ago
Agreed. We're evaluating remix at work to use on a rewrite project and this seems like it will make it harder to adopt - and harder to cast as an alternative to next.js
- zackify 2y ago
  It’s just a global find and replace after the update though.

peter_l_downs 2y ago

Fwiw I recently started using wouter (https://github.com/molefrog/wouter https://github.com/molefrog/wouter) 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/)

nsonha 2y ago
I think what react-router tries to solve is esentialy navigating without re-rendering layout partials
floydnoel 2y ago
Cool to see some alternatives around! I didn't like React Router's bloat either, and wrote my own. Besides having no dependencies, my router also focuses on making it easy to handle common SEO requirements like generating a sitemap or handling open graph tags. Routerino: https://github.com/nerds-with-keyboards/routerino https://github.com/nerds-with-keyboards/routerino

a_random_canuck 2y ago

I feel like this announcement could use a more clear summary of the key point at the top. 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?

jeffwiederkehr 2y ago
I have the same question/confusion. I'm not sure what the benefit is of merging the projects? I get they are very close feature wise but why physically combine and make Remix features an opt in vite plugin vs just keeping the projects separate repos?
- dcre 2y ago
  Remix is already essentially a Vite plugin + React Router. That change was started at least 9 months ago and went stable 3 months ago. https://remix.run/blog/remix-heart-vite https://remix.run/blog/remix-heart-vite https://remix.run/blog/remix-vite-stable https://remix.run/blog/remix-vite-stable At this point the separation between the two projects is seeming more and more like a lot of rigmarole for nothing. Imagine running two projects that are 90% the same, and every time you change one you have to make a release and update the other, etc etc.

lazlo_kovacs 2y ago

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. 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. Did the Vercel people manage to execute a psyop on Remix? This doesn't feel like the move.

azemetre 2y ago
I don't know if you're aware but the authors of both libraries (react router, remix) are the same two core developers. I do find their open source libraries a good juxtaposition of engineering philosophy for the tanstack ecosystem. Tanstack seems to favor making things modular over time so it's easier to create bindings in other libraries while also increasing the enhancements whereas it feels like Ryan Florence and Michael Jackson prefer to get features out faster even if it means throwing away previous code. I feel like I'd still be using tanstack/router, tanstack/table, and tanstack/query in 2030 compared to even react itself.
- lazlo_kovacs 2y ago
  Yes, I'm well aware. To be honest I was pleasantly surprised with Remix because of my negative experiences with React Router. But now it seems like they've gone back to churn and cheery messages claiming that this is the best iteration, just please ignore the last 4 attempts.
  - mirthflat83 2y ago
    I feel the exact same way.
gedy 2y ago
> 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. Yeah I hate to be negative, but honestly I was a lot less excited about Remix once I found out was react-router team. While serving a useful need and I appreciate their work, using react-router in a large production app (MPA) was series of frustrating updates and rewrites once we needed to update (we did not have luxury of just leaving old code as is). The iterative churn and rethinking of design scared us off from Remix for the time being.

PaulHoule 2y ago

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. 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. 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.

fish55 2y ago

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.

ryandvm 2y ago
I've been writing code for 20+ years and I did not recognize a single product you mentioned. I am so glad I got off the front end treadmill. If you need me I'll be over here writing APIs using the same stack I was using 5 years ago.
- halfmatthalfcat 2y ago
  So brave. Thank you for your contribution.
- drawfloat 2y ago
  You don’t need to know every Astro and Remix, but not even knowing what Vite and Next are as a FEer in 2024 is not exactly something to shout about. If you don’t need to, fine, but also understand it just sounds ignorant given their size and many years of news around them.
  - deleted 2y ago
    [deleted]
- deleted 2y ago
  [deleted]
- throwaway11460 2y ago
  I still use the same tools I used when I started with React 10 years ago. You don't need to get on the treadmill, you chose that.

franciscop 2y ago

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: https://crossroad.page/ https://crossroad.page/

pier25 2y ago

Didn't Shopify buy Remix?

0xblinq 2y ago
yes https://remix.run/blog/remixing-shopify https://remix.run/blog/remixing-shopify
dbbk 2y ago
This is in the article

0xblinq 2y ago

Yet another mess, once again. 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. 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. NPM should show download metrics by version (as packagist does for PHP packages). I'm convinced this will prove it. But hey, this works. Now they have more downloads than Next so let's use this instead. (BTW, Remix was still a better option than Next in my opinion, but that's a super low bar)

dcre 2y ago
npm does show last 7 days download metrics by version! https://www.npmjs.com/package/react-router-dom?activeTab=versions https://www.npmjs.com/package/react-router-dom?activeTab=ver... As it happens, I was curious about the same thing last year and wrote a script you can run in the browser console to add them up, and it does prove something: react-router-dom v6 5820458 v5 3274886 v4 275081 react-router v6 5993187 v5 3366625 v4 302549 v3 156121 v2 25726 v1 8448 v0 2447 Code here: versionsHeader = Array.from(document.querySelectorAll("h3")).find( (h3) => h3.textContent === "Version History", ); // requires a second .nextElementSibling for react-router // because of the deprecated versions checkbox versions = versionsHeader ? versionsHeader.nextElementSibling : null; nums = Array.from(versions.children) .slice(1) .map((el) => [ el.children[0].textContent, parseInt(el.children[2].textContent.replace(/,/g, ""), 10), ]); for (const v of [6, 5, 4]) { const sum = nums .filter((c) => c[0].startsWith(`${v}.`)) .map((c) => c[1]) .reduce((a, b) => a + b, 0); console.log(`v${v}`, sum); }
- theplatman 2y ago
  I would say it’s a bad sign that 40-50% of the user base is already one version behind as you’re releasing v7. This comparison ignores reach router, which was the other replacement for react router by that same team before they abandoned it for remix. That still has 600k downloads so now you’re nearly at 50:50. There’s a reason why many front end devs have stayed away react router and the associated libraries since 2016/2017 because this team has lost a lot of good will for the number of times they’ve done major overhauls of their projects.

bilalq 2y ago

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. 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. 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.

wokwokwok 2y ago

> 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. Mmm. 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. 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 merge it to the popular one people will not notice and we can just pretend we only have one popular package? Maybe we should just merge all the packages in npm into one package called 'all'. That would be soooo popular, great victory! 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 :| > and now Remix and React Router are basically the same thing Mm. That's not how I would describe the difference between a server side framework and a client side one. [1] - https://remix.run/docs/en/main/guides/spa-mode https://remix.run/docs/en/main/guides/spa-mode

dcre 2y ago
The difference in popularity is more like 40x, which makes your theory obviously correct, and it also makes it a no-brainer for the devs. The server-side aspect is opt-in and someone currently using react router v6 (with v7 future flags on) will not need to make any code changes when upgrading to v7. How could a new server magically appear in your application?
tjosepo 2y ago
> it feels like a bait and switch to turn a client side library into a server side framework And I think that's exactly what the React ecosystem needs right now. There has been a growing split between client-side React and server-side React, with most existing React applications being client-side with no easy path to server-side that didn't involve a full app rewrite in Next.js or Remix. The new React Router Vite plugin is that easy path to server-side React that people were looking for. If you're using React Router (like most client-side applications do), you're already 90% of the way there.

randomdev3 2y ago

While Remix seems a bit more reasonable than some other js frameworks, they all share the same problem: fundamental architecture. 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. But no, just throw views,data, io, auth checks etc. everywhere and hope it builds.

BillyTheKing 2y ago
what's wrong with Remix's fundamental architecture? I mean.. I generally also think that the overall state of the JS ecosystem is broken, but that's due to JS tooling modules vs commonJS etc (hope bun fixes all that). But as a backend-dev who primarily writes Go I round remix easy and simple to pick up and get started with when I had to use it this year.

clivestaples 2y ago

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.

c-hendricks 2y ago

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. https://github.com/remix-run/react-router/discussions/10288 https://github.com/remix-run/react-router/discussions/10288

jakubmazanec 2y ago

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.

gardenhedge 2y ago

So is React Router a framework? Confusing.