Latest status on rfr v/s rudy?

Hi. I am using rfr in my project and loving it.

When combing through the issues, I often encounter mentions of rudy in this rfr repo. I am familiar with the basic concept here - rudy is supposed to be built on rfr and then enhanced.

However, it doesn’t seem finished. I repeatedly become confused as to whether something being talked about using the term rudy in the rfr repo is present in rfr or not.

And then looking for more details in the rudy repo, I came across the plans to build a whole framework (respond?) around rudy. This baffled me even more as I don’t want to jump into a complex routing solution. I would have not ditched react-router in the first place.

Could the developers clarify a few points?

• What is the recommendation on which one to use for a new project? rfr or rudy?
• If you recommend rudy, then does this repo already incorporate the features of rudy? I ask this because in several recent issues, solutions are provided with reference to rudy instead of rfr (in this rfr repo).
• Will rudy be expanded (or co-opted) into the respond framework? If so, I would rather make do with rfr.
• Anything else you would like to add.

All in all, a general clarity on the state of things is appreciated.

[hedgepigdaniel]

Hi, glad you asked. I’ve been working on Rudy for the last year or so - this is my take on it.

First up, the reason you see mixed messages about what repo rudy is in is because it was originally developed in this repo as a fork of rudy, and only later moved out into its own repo where it now lives.

In answer to your questions:

• What is the recommendation on which one to use for a new project? rfr or rudy?: Its hard to make a universal judgement that would apply to all users. For the most part, the Rudy API is a superset of the RFR API - and there are a number of significant new features in Rudy. Having said that, Rudy does not yet have consistent and up to date documentation, and has not had as much testing as RFR. If you’re prepared to occasionally read the source code, potentially contribute to the documentation, and especially if you’re already familiar with RFR, I’d recommend giving Rudy a go.
• If you recommend rudy, then does this repo already incorporate the features of rudy? I ask this because in several recent issues, solutions are provided with reference to rudy instead of rfr (in this rfr repo). No - RFR does not incorporate Rudy. See the (incomplete) list of changes from RFR linked from the Rudy README. Many of the recent issues made in this repo boil down to the lack of support in RFR for asynchronous middleware (I think that was the main trigger for the original refactor that led to Rudy in its current form). Apart from one exception (the thunk during SSR), it is not possible to delay anything in RFR. In Rudy it is the norm - everything is promises. I would say that’s the “killer feature”, but there’s plenty of other useful additions aswell.
• Will rudy be expanded (or co-opted) into the respond framework? If so, I would rather make do with rfr. No. I believe James and Zack are working on a wider framework called the respond-framework. It will depend on Rudy, but Rudy will still exist as a standalone library. So you are welcome to use Rudy as you would use RFR, without using the Respond Framework. At OpenLearning we are using Rudy in production and we are committed to maintaining it in its own right, and I know there are a few others also using it in production.

In case you’re confused that Rudy exists in a different repository - there are a few reasons. There was alot of confusion at the time about exactly what Rudy was, so moving it into a separate repo was an attempt to clarify the difference between the two projects. There was and is a need to maintain RFR (which has a large community of users), and also a need to finish off all the new features in Rudy without all the pressure and expectation that comes from calling it RFR 3.0. The idea is that RFR continues to be maintained with its current feature set, and users are free to migrate to Rudy when and if they feel it is stable/documented/whatever enough for them. Both projects were originally written by James, and @ScriptedAlchemy and I (along with various others) have worked on both since. So go for your life, do what works for you. If you have any issues/questions about Rudy please make an issue in the Rudy repo.

[ScriptedAlchemy]

https://github.com/respond-framework/rudy

Been out for a while fam 😄