People tend to push back against Redux because it asks the developer to invest more time upfront with some boilerplate code, and, more importantly, to recognize the functional programming patterns that Redux is based on.
As for boilerplate, I think people tend to overreact. I embrace boilerplate for the sake of good abstractions and clean architecture. Boilerplate can be your friend.
I don't know about others, but I spend way more time reading docs, thinking about how to solve hard problems, communicating ideas with my team, reviewing pull requests, and debugging errors... Boilerplate is just a mild annoyance in a vast sea of development work. I'm happy to do it if it means fewer hours spent on refactoring or debugging, or when it makes pull-requests seem more comprehensible.
As for understanding the FP concepts that Redux is based on, there really is no shortcut for learning fundamental principles of computer science & system design. There's no such thing as a library or framework that completely eliminates the need to think about abstraction layers like that. Developers should seek to level-up their understanding. Listen to talks on YouTube, read more articles, read books, do pair programming at work... whatever you have to do to learn. This stuff is considered "best practice" for a reason.
I want newcomers to succeed, and also avoid the mental overhead of building complex apps. But I'm not sure how realistic that is. Web programming is insanely complex nowadays. And all the tooling in the world can't change that. They only sweep complexity under the rug. And eventually you have to lift up the rug and deal with it. There's no way around that.
For non-trivial apps, Redux is a hugely beneficial tool. I suggest people use it, or at least something like it. They will be better off down the road.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
People tend to push back against Redux because it asks the developer to invest more time upfront with some boilerplate code, and, more importantly, to recognize the functional programming patterns that Redux is based on.
As for boilerplate, I think people tend to overreact. I embrace boilerplate for the sake of good abstractions and clean architecture. Boilerplate can be your friend.
I don't know about others, but I spend way more time reading docs, thinking about how to solve hard problems, communicating ideas with my team, reviewing pull requests, and debugging errors... Boilerplate is just a mild annoyance in a vast sea of development work. I'm happy to do it if it means fewer hours spent on refactoring or debugging, or when it makes pull-requests seem more comprehensible.
As for understanding the FP concepts that Redux is based on, there really is no shortcut for learning fundamental principles of computer science & system design. There's no such thing as a library or framework that completely eliminates the need to think about abstraction layers like that. Developers should seek to level-up their understanding. Listen to talks on YouTube, read more articles, read books, do pair programming at work... whatever you have to do to learn. This stuff is considered "best practice" for a reason.
I want newcomers to succeed, and also avoid the mental overhead of building complex apps. But I'm not sure how realistic that is. Web programming is insanely complex nowadays. And all the tooling in the world can't change that. They only sweep complexity under the rug. And eventually you have to lift up the rug and deal with it. There's no way around that.
For non-trivial apps, Redux is a hugely beneficial tool. I suggest people use it, or at least something like it. They will be better off down the road.