Latest status on rfr v/s rudy?

[jbhoot]

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.

[jayeshbhoot]

Thank you for such a swift and clear explanation!

I had already been wishing for some of rudy's features to be present in rfr, but kept away as rudy seemed to be in a state of flux.

Now I will certainly have a crack at rudy.

You may want to sticky your response somewhere like README.

[ScriptedAlchemy]

late to the party, but yeah - all the action is over here
https://github.com/respond-framework/rudy

[dlong500]

No pressure, but is there a general sense of when rudy will have an official release? All the recent dependency update commits here at RFR caught my attention and I'm still sort of waiting on rudy to mature before switching an older codebase from react-router v3.

[ScriptedAlchemy]

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

Been out for a while fam 😄

[ScriptedAlchemy]

I’m working on bigger things with webpack at the moment. Rudy is stable and used by several in prod. webpack/webpack#10352

[dlong500]

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

Been out for a while fam smile

I do know there is a repo for rudy, but everything there is tagged as a pre-release. By stable, do you mean that that the API won't be changing dramatically or that it is simply reliable. If it's ready for production, shouldn't the pre-release tag be removed? Sorry to pester. Just trying to get a clear picture before spend a bunch of time working on things.

[alexstanbury]

Perhaps the documentation for Rudy needs to be updated, on the main page it says 'The basic features work, but there are still bugs and some features are incomplete.'