Merging Remix and React Router | Hacker News Reader

Merging Remix and React Router

remix.run

107 points0xedb75 comments

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.

I'm sure the React Router/Remix guys are smart, but I don't get the impression that they actually build and maintain real world websites, and the closest they get is a month or two of consulting. They've always been extremely hostile to anything resembling stability, and extremely unreceptive of anyone calling out how unproductive this is.

> extremely hostile to anything resembling stability

Remix has one of the best stars/issue ratios I've ever seen in a large project. They have 27k stars for 228 issues (118 stars/issue). Meanwhile next.js has 121k stars for 2678 issues (45 stars/issue).

Remix also has a robust future flag system to ensure nothing breaks during transitions. https://github.com/remix-run/remix/issues/4598

For larger changes (like the controversial flat routes), they even maintain the old feature so you don't have to upgrade. https://www.npmjs.com/package/@remix-run/v1-route-convention

I don't think the evidence supports your assertion.

I want to preface this by saying I don't have a dog in this fight. Not a big react fan in general although I write it for work, and have no opinions on specific routers or 3rd-party state libraries being better or worse than others.

With that out of the way, where is the research showing that this is a good indicator of software reliability? Highly starred projects are left unfinished and abandoned all the time. The thread above goes into details about upgrade challenges. So it seems stars are maybe not such a good indicator of reliability. What about using a star to issue ratio? I've personally seen multiple projects with 10k+ stars that hide their bug reports in the discussions tab. Terraform has a much worse ratio, but would you describe it as much less reliable?

Show me the research.

I agree that stars alone don't equate to reliability, which is why I used (the very much imperfect, but better) stars/issue as part of the evidence.

While I'm unaware of research supporting stars/issue, it's a useful rule-of-thumb at the extremes. With React (318), if something isn't working, your code is almost certainly wrong. With Bun (24), if something isn't working, it's likely Bun (sorry, Jarred).

The assertion the Remix creators are "extremely hostile to anything resembling stability" should place Remix at the lowest extreme, but that isn't so.

If you use a metric or rule-of-thumb for evaluating reliability, I'm curious to hear it.

Gotcha so that is sort of a precursor to a deeper inquiry it sounds like. I'm concerned it sounds like there may be a strong bias in favor of popularity. Maybe that is less of an issue for developers already shopping within a specific stack/philosophy though.

I tend to try and ignore stars, because I've been burned by popular and unpopular projects alike. They also seem to be gamed at times. For an initial evaluation of something I might actually use I look at who the owners are, when the project was last updated, and explore the issue tracker (including closed tickets). That is usually enough to identify projects with major problems. If they pass the initial audit, then the process continues.

I haven’t used Remix, but I regret choosing react-router due to frequent major version upgrades.

Those breaking changes were especially painful in React Native apps. Thankfully there are some good alternatives now.

Would you mind sharing what are they?

You could take a look at these:

https://tanstack.com/router/latest

https://github.com/molefrog/wouter/

Wouter is great, I recommend.

Take one more sir.

...and completely changing how everything works on each major version change.

If you are happy with one version you can just stick to it?

You don't have to update your phone and laptop every year, even if you are made to feel so.

You do have to upgrade. At some point incompatibilities between libraries arise, and if neglected for too long at some point it becomes impossible to update everything. Keeping dependencies up to date is an important part of software maintenance.

In our case we wanted to upgrade another dependency (react-admin) which necessitated a react-router upgrade, which we used throughout the rest of our application, so it was a reasonable amount of work and sticking to the old one was not an option.

I wish this were true. In the modern JavaScript ecosystem you either pin everything or pin nothing.

I don't think issues are a good measurement for popular repos. Majority of them are just basic skill issues and inability to read 2 pages of docs.

Especially next community seems to be full of people who don't seem to know anything about web development complaining because they don't know how cookies work or something...

This is a weird metric.

Stars don't mean usage.

Remix has 21,375 downloads per week according to npm. Next has 6,562,587.

The remix package is no longer used[1]. Remix's central package is @remix-run/router[2], which has 5,627,846 downloads per week.

[1] https://github.com/remix-run/remix/pull/9433 [2] https://www.npmjs.com/package/@remix-run/router

Using “star / issue ratio” is a basis for your point is just an indicator that you’re too deep into the JS ecosystem. It reads into weird GitHub metrics to a unique degree.

Hey I star projects just as a way of bookmarking them..

I can already imagine these comments will be screenshot and mocked at by the React Router/Remix author in Twitter :)

You’ve hit the nail on the head. The JS ecosystem has this problem generally, but Remix is particularly bad with it. It’s like people don’t spend the time experiencing the problems they’re seeking to fix before parachuting in and “fixing” them with their framework or library or whatever. You can’t expect people to build good, reliable software with your framework without knowing how to actually build good, reliable software yourself.

Isn't Remix owned by Shopify? I'm fairly certain Remix is used on some of the Shopify platform / admin pages, that's a fairly large and well-used real world website being maintained in Remix

Ryan did mention this in his talk at React Conf.

Shopify has had issues adopting Remix because their existing front-end codebases are massive and they couldn't afford to rewrite them to use Remix.

That's actually the whole motivation behind turning Remix into a bundler plugin. With a bundler plugin, you can incrementally migrate parts of your existing application to use the features of Remix without having to rewrite all of it.

They also have been weirdly money focused. Such as moving the react router package to an org called react training. The quintessential routing library of react being sold like that left a bad taste in my mouth. Combined with reacts incredibly poor api, it turned me off react forever. Svelte and vue are both much better.

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.

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.

I feel the exact same way.

I too was put off Remix because of react-router, it actually looks pretty good but I was holding off to see if they rewrote the entire thing in The future, and they did!

One of my biggest problems with router was not only the constant api changes but the docs being unsearchable because you are never sure which version people are talking about, making all discourse about it a waste of time.

We await the outcome of the react framework wars, I still think react is wrong requiring frameworks to supplement its framework.

Remix is just react router with a build system. They replaced the build part with Vite. So the core contribution to the community here is just react router.

If you watch the react conf video by Ryan it explains it all well.

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

This is all about download counts and who's more popular. That's it.

Glad I am not alone in thinking react router has always been a disaster. Jumped ship ages ago to Vue - this was partly the reason - and I find vue router to be pretty great.

And the router aren't even that good, loads of functions have no useful docs.

You just hope someone has asked it on SO.

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.

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

It’s just a global find and replace after the update though.

Fwiw I recently started using 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/)

I think what react-router tries to solve is esentialy navigating without re-rendering layout partials

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

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.

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?

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?

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

> 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

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?

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

Now I appreciate the forward-thinking mode of the comment. That being said, the comment makes a lot of glaring assumptions - such as:

a) most teams/apps/projects want to switch to using server-side react (?)

b) the reason they haven't switched is not because a) but because it involves a full re-write of their code (??)

c) vite plugin would be an easy path to server-side react (??)

d) this easy path is what people were looking for

e) that somehow, all the teams out there that wanted to switch their project to server-side react, but thought they couldn't, just simply didn't realize they were 90% of the way there

I'm not really sure where to start, but let me explain some of the reasons a lot of teams / apps / people use the client-side only version of react / <insert favorite routing library>:

1. it allows teams that are pretty much front-end only, to mainain their autonomy

2. it allows people to maintain a clear split of responsibilities

3. a lot of front-end teams have no experience running server-side stuff in production

4. a lot of teams would not really benefit from server-side react - or the main benefits would be neglegable performance benefits, which might not even be perceived at all

5. a lot of people / teams have a backend-team that uses a completely different stack / programming languages - so they would not even be able to help or assist when things go badly when there are issues - or help with training the front-end people to deal with server side configuration/deployment/issues/node.js stuff (as much as we all want to pretend server-side react is not actually a node.js app, it is)

6. there's also a lot of people that just have a philosophical point of view that there should be a clear distinction between front-end and backend - and that these things should remain very clearly separated.

Now, I know these are not unsolvable - and some might be based on some misunderstanding and/or arguably wrong opinions/takes - there is a way for every team to get into some middle ground - eg. treat the server side react as kind of a front-end server or like a caching layer - but the topic is nuanced enough that it's impossible to give a concise solution in a single comment.

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

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/

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.

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.

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.

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.

So brave. Thank you for your contribution.

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.

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.

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.

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.

So is React Router a framework? Confusing.

Didn't Shopify buy Remix?

yes https://remix.run/blog/remixing-shopify

This is in the article

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)

npm does show last 7 days download metrics by version!

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);
  }

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.

Why is it bad sign? It means the old versions are pretty good and people are still using them. It's very hard for me to imagine a library used at this absolutely massive, mind-boggling scale that doesn't have a long tail of legacy support.

On top of that people are very much still moving to v6. When I checked last August it was about 50-50 v6 vs the rest, now it's 60-40, and in absolute terms that delta is far more than the total number of Reach downloads.

> It means the old versions are pretty good and people are still using them

That's a very optimistic view of the situation.

It’s really frustrating how the remix/react router maintainers refuse to examine how their major version changes have caused pain for tons of developers out there.

There’s a reason why this feedback keeps coming up again and again.

I think the fact that the team chose the React Router name tells me they don’t understand how tainted the name is for a lot of experienced front end devs.

And moving forward it’s going to be even harder to search for issues when you stumble on a problem because the names of Remix/React Router have been polluted over the years.

Hey! But those sweet download stats! Now it’s bigger than next and that’s the only thing that matters.

Reply on news.ycombinator.com