See twin issue on the Rematch repo: Differences between Rematch and Redux Toolkit (rtk)
I feel it is only appropriate to ask the same here.
Would be really useful for people to understand the pro/cons and philosophy behind each.
I've been over the moon with RTK, but now we're asked to migrate to Rematch and it's hard to make a case because neither frameworks mention the other in the docs.
This may not be a proper issue alright, because I'm not sure product comparison should be part of the docs.
But I'm sure those interested will stumble upon this issue.
I don't think I need to "justify" this project's existence:
I'm happy to discuss differing tradeoffs and such, but I also don't see a need to spend time writing up comparisons with other tools in the docs, especially given that I have a ton of other docs work I'm currently trying to focus on.
(I will also note that Rematch does not have very much usage, overall, while Redux Toolkit's adoption is growing rapidly.)
But, if you'd like to know _why_ it exists and what problems it's trying to solve, please see:
I will say, I'm curious: why are you being asked to migrate to Rematch, specifically?
I'm gonna jump on this and add two points:
RTK is just redux.
You can take every single part out of RTK and use it side-by-side with any other redux-based library. RTK takes no shortcuts, modifications or assumptions over the redux core, but just offers a lot of helpers that help you get things along the way.
There's no under-the-hood bootstrapping stuff that will break things if you use createSlice with the pure redux createStore instead of RTK's configureStore. (Yes, createAsyncThunk requires you to have the thunk middleware enabled, but that's about it)
No auto-binding dispatchers that somehow mingles with what would be the job of a library like react-redux or reactive-react-redux.
RTK is not rematch. Also, it is not easy-peasy or one of the hundreds of other similar libraries that are out there. The purpose of RTK is to kind of contain that explosion of libraries, because if that would be going on with the speed it has in the past few years, you would never come from a project that was using rematch to another project using rematch.
Every single redux-related project you'd be working on in your career would be using a different state mangagement abstraction that you'd have to re-learn, because there are just too many of them and there's no real consent on which to use.
And, just like those two examples do, most of them are not really only helpers around the core redux, but they introduce completely new concepts that might directly conflict with concepts you were using in your last project, so coming from one to another might every time require you to unlearn old habits and even then send you into pitfalls that you were not aware to be library-specific.
The only way around that explosion of libraries is one officially recommended library.
Sure, there might be cases where it is really warranted to use one of the others, because of some kind of business requirement, but generally choosing one of them will steer you into a direction where you have to justify additional learning time for every future onboarded member of your team - for every single project. Personally, I'd say that "taste" or "one more fancy abstraction" is not one of them, especially as you can introduce those on top of RTK in your own code - while keeping the rest standard.
@markerikson That "justify" in the title is a copy-paste for the issue title in Rematch. Clearly neither need to justify anything.
What I really meant, and would like to establish, is the differences between the two in such way that someone can make an educated decision on why to pick that one or the other.
I also don't think you should be writing this. I was hoping for different people to chip in - like the (great) comment @phryneas left.
Most helpful comment
I'm gonna jump on this and add two points:
RTK is just redux.
You can take every single part out of RTK and use it side-by-side with any other redux-based library. RTK takes no shortcuts, modifications or assumptions over the redux core, but just offers a lot of helpers that help you get things along the way.
There's no under-the-hood bootstrapping stuff that will break things if you use
createSlicewith the pure reduxcreateStoreinstead of RTK'sconfigureStore. (Yes,createAsyncThunkrequires you to have the thunk middleware enabled, but that's about it)No auto-binding dispatchers that somehow mingles with what would be the job of a library like
react-reduxorreactive-react-redux.RTK is not
rematch. Also, it is noteasy-peasyor one of the hundreds of other similar libraries that are out there. The purpose of RTK is to kind of contain that explosion of libraries, because if that would be going on with the speed it has in the past few years, you would never come from a project that was usingrematchto another project usingrematch.Every single redux-related project you'd be working on in your career would be using a different state mangagement abstraction that you'd have to re-learn, because there are just too many of them and there's no real consent on which to use.
And, just like those two examples do, most of them are not really only helpers around the core
redux, but they introduce completely new concepts that might directly conflict with concepts you were using in your last project, so coming from one to another might every time require you to unlearn old habits and even then send you into pitfalls that you were not aware to be library-specific.The only way around that explosion of libraries is one officially recommended library.
Sure, there might be cases where it is really warranted to use one of the others, because of some kind of business requirement, but generally choosing one of them will steer you into a direction where you have to justify additional learning time for every future onboarded member of your team - for every single project. Personally, I'd say that "taste" or "one more fancy abstraction" is not one of them, especially as you can introduce those on top of RTK in your own code - while keeping the rest standard.