11 ms·

This isn't a solved problem. The React ecosystem has spent the last few years trying a model where the application layer separated from the view layer with a p

This isn't a solved problem. The React ecosystem has spent the last few years trying a model where the application layer separated from the view layer with a pure functional state management solution called Redux. The overwhelming response? People didn't like it. Decoupling systems is a trade-off. Pull your network requests out of your components and you have two bits of code that are easier to test. Indirectly, the component is still going to call that code, and it's up to you to manage the complexity of that indirection. Not every application needs separation of concerns, and in many, colocation of concerns reduces the cognitive burden, because you can reason about components in isolation. To me, that's a more powerful guarantee than a function being strictly pure.

swyx 5y ago
idk if “the overwhelming response” is people dont like Redux. some people are very vocal about their dislike, yes. But 1/3 of survey respondents use Redux despite other choices existing. theres a reason it won the Flux wars.
- codecurve 5y ago
  Maybe overwhelming was too strong, but I don't see many people getting excited about building new projects with Redux any more. Presumably some proportion of that 1/3 are stuck on Redux, unwillingly? I like (and use) Redux on a daily basis, and I don't think it's a sensible choice for lots of React apps. Maybe the overwhelming rejection that I've witnessed is people discovering that they used it for stuff they shouldn't have.
- azangru 5y ago
  > theres a reason it won the Flux wars. It won the Flux wars, but there are state management approaches based on paradigms other than flux. There's at least the model that Recoil/Jotai uses (atoms?), the model that MobX/Valtio uses (mutable observable state), the model based on state machines (XState), the model heavily using React context (Constate), etc.
notpachet 5y ago
Sorry, but I have stopped using "developers don't like this" as a measure of the technical quality of anything. A lot of developers like things that are pleasurable to them in the small, but harmful to the codebase in the aggregate, especially over years of maintenance cycles.
- arvinsim 5y ago
  Doesn't matter. Every developer will still be at the mercy of the whims of the majority unless you find your own niche.
  - notpachet 5y ago
    I'm writing this stuff to try and push back against the whims of that majority, because I think they're ill-founded. Just because a majority of people believe something to be good and true, doesn't automatically make it so. It still has to stand up to empirical evaluation on its own merits.
  - dgb23 5y ago
    Lowest common denominator.
- whakim 5y ago
  I'm not sure I agree with this. One of the elements of a well-designed system (whether we're talking about software libraries or anything else) is that the designer should reward people for doing what they like. If you design something where the correct approach cuts against people's natural inclinations, they'll just use something else. The correct answer is to design paradigms that make the right thing pleasurable.
  - notpachet 5y ago
    I agree that systems should be rewarding to the user. But there are rewards and there are rewards. There are short-term dopamine fix rewards, and then there are the rewards that you can only really appreciate after having invested some time and energy first. It's like fast food vs a lifetime of diet and exercise. The churn in the frontend ecosystem reminds me a lot of fad dieting: people have never really experienced working in a paradigm that enables them to stay healthy through regular diet and exercise over the long term, so they turn to the latest shiny gizmo hoping that this time it will be different.
notpachet 5y ago
I agree with your point that not every application needs this degree of separation of concerns. But the problem, in my experience, is that individual developers are not very good at knowing where that line is. And the line can move over time as the application grows. For any project that I'm responsible for, I don't feel comfortable designing around a paradigm unless there are some guard rails to prevent developers on my team from accidentally tying the code in knots. How enjoyable is this for the developers? Are they sprouting angel wings and playing the lyre as they write code in iambic pentameter? Probably not, no. They have less freedom of motion than if they were left to their own devices. This is a larger debate: where to fall on the spectrum between unadulterated developer bliss and having an application that is still maintainable in 5 years. I don't put much stock in developer bliss, but I do appreciate that the sword cuts both ways.
- catlifeonmars 5y ago
  I’m curious if the statement “happy developers create better systems” holds any weight.
acemarke 5y ago
Hi, I'm a Redux maintainer. I've written extensively about the fact that A) Redux _has_ been overused, B) that many of the complaints were really more about the standard code patterns needed and the "boilerplate" involved, and that C) "modern Redux" with our official Redux Toolkit package and the React-Redux hooks API has solved those "boilerplate" concerns. Redux is still by far the most widely used state management tool with React apps (my estimates are around 45-50% of React apps use Redux), and we try to give clear guidance in our docs on when it does and doesn't make sense to use Redux. FWIW, we get highly positive feedback on a daily basis from users who tell us how much they love using Redux Toolkit. Resources: - https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet... - https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff... - https://blog.isquaredsoftware.com/2021/05/state-of-redux-may-2021/ https://blog.isquaredsoftware.com/2021/05/state-of-redux-may... - https://blog.isquaredsoftware.com/2021/05/learn-modern-redux-livestream/ https://blog.isquaredsoftware.com/2021/05/learn-modern-redux... - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... - https://redux.js.org/tutorials/index https://redux.js.org/tutorials/index - https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu...
- deleted 5y ago
  [deleted]
- Lhiw 5y ago
  Has redux fixed its broken implementation of event sourcing and cqrs yet or is it still encouraging people to execute side effects in reducers?
- what_is_orcas 5y ago
  I'll add to that: I love redux and most of the complaints or concerns that I've heard about using redux (from a few teams) have been misunderstandings of how to integrate redux into an existing application or an application design. I think this has mostly come from junior-level folks (independent of title, there are a lot of non-junior devs who can't integrate new patterns into their "senior" level understanding of code, but I digress) and folks who don't work on the front end much (or ever). I was one of those folks until I started a side-project that used redux and I had to implement it in a greenfield project and had the liberty to refactor as I progressed and my mental-model "updated" to integrate the new framework.
zaksingh 5y ago
A big challenge with the React ecosystem is that it's the first technology many new developers work with. They don't have a frame of reference for what alternative approaches exist, and therefore 'best practices' are taken on faith and followed blindly until their nuances can be learned through experience. That's not a bad thing (and it's better than the alternative of not caring for design patterns whatsoever). It's part of the learning process, and since there are so many beginner developers who are using React, their perspective is much 'louder' than in other dev ecosystems. You can see this in the absurd amount of introductory-level React content posted to Medium, DevTo, Twitter, etc. This has bred a very strong 'follow-the-leader' culture where, when the one person is the room who _does_ know what they're talking about makes a statement, others will repeat it verbatim without understanding its nuances due to a lack of experience/context. Redux suffered heavily from this. New React devs in 2017 were faced with mountains of tutorials which all used Redux. Many of these tutorials were written by other newbies. Your mental model of React dev was then shaped around Redux. Therefore you would put everything you could into the Redux store, which is a bad idea -- you usually don't need form state in there, for example. Then some React thought-leaders saw this problem and inadvertently created a counter-movement by raising how Redux was overkill for some use cases, which was misconstrued as 'you shouldn't use redux _at all_'. The pendulum has been swinging back and forth ever since. Yes, not every application needs separation of concerns. But some definitely do. It's not black and white, and that unfortunately means there's no definable 'best practice' that can be tweeted or blogged about and followed blindly -- it just has to be learned from experience.
- codecurve 5y ago
  I would go one step further and say that the counter-movement is the visible effect of newcomers discovering that separation of concerns was a bad decision for the simple apps they were building. Or maybe more accurately, discovering that it's often simpler to separate by concern at the component level, than at the app level. We all ride the pendulum until we find the shade of grey which works best for us.
- anchpop 5y ago
  > Therefore you would put everything you could into the Redux store, which is a bad idea -- you usually don't need form state in there, for example. Why's that? IME it is usually simplest to just put everything in redux. For example, if you have a form under some kind of tab navigation thing, you'd ideally want the form state to be preserved even when they tab out and then back in. Putting it in redux means you don't really have to think about it
toinbis 5y ago
Am wondering what react community thinks of DDD. I've been reading "blue" DDD book (by Eric Evans) and "red" book (by Vaugh Vernon) and that was a completely "my whole life was a lie" type of experience and relief at the same time. It's just so great to have the principles of who to structure the code. It, by definition makes, your codebase structure meaningful. Because it's structured according to some common knowledge, not your random thoughts at the time you were writing code. I was surprised to find so little DDD react sample codebases. Let's say for backend there is huge amount of samples, i.e. https://github.com/kgrzybek/modular-monolith-with-ddd https://github.com/kgrzybek/modular-monolith-with-ddd . For react/frontend I have bookmarked only https://github.com/talyssonoc/react-redux-ddd/tree/master/src https://github.com/talyssonoc/react-redux-ddd/tree/master/sr... and few more, but those others does not meet the optional criteria i like really much - at the highest (or at app) level all codebase need to have folders app, domain, infra and ui. Simple rule, but simplifies life a lot. So my question is - is DDD for some reasons not very applicable for app frontend development. Or it just never became popular. Or maybe DDD is popular amongst react developers, just I am not aware of this. Many thanks for any ideas and comments!

swyx 5y ago

idk if “the overwhelming response” is people dont like Redux. some people are very vocal about their dislike, yes. But 1/3 of survey respondents use Redux despite other choices existing. theres a reason it won the Flux wars.

codecurve 5y ago
Maybe overwhelming was too strong, but I don't see many people getting excited about building new projects with Redux any more. Presumably some proportion of that 1/3 are stuck on Redux, unwillingly? I like (and use) Redux on a daily basis, and I don't think it's a sensible choice for lots of React apps. Maybe the overwhelming rejection that I've witnessed is people discovering that they used it for stuff they shouldn't have.
azangru 5y ago
> theres a reason it won the Flux wars. It won the Flux wars, but there are state management approaches based on paradigms other than flux. There's at least the model that Recoil/Jotai uses (atoms?), the model that MobX/Valtio uses (mutable observable state), the model based on state machines (XState), the model heavily using React context (Constate), etc.

notpachet 5y ago

Sorry, but I have stopped using "developers don't like this" as a measure of the technical quality of anything. A lot of developers like things that are pleasurable to them in the small, but harmful to the codebase in the aggregate, especially over years of maintenance cycles.

arvinsim 5y ago
Doesn't matter. Every developer will still be at the mercy of the whims of the majority unless you find your own niche.
- notpachet 5y ago
  I'm writing this stuff to try and push back against the whims of that majority, because I think they're ill-founded. Just because a majority of people believe something to be good and true, doesn't automatically make it so. It still has to stand up to empirical evaluation on its own merits.
- dgb23 5y ago
  Lowest common denominator.
whakim 5y ago
I'm not sure I agree with this. One of the elements of a well-designed system (whether we're talking about software libraries or anything else) is that the designer should reward people for doing what they like. If you design something where the correct approach cuts against people's natural inclinations, they'll just use something else. The correct answer is to design paradigms that make the right thing pleasurable.
- notpachet 5y ago
  I agree that systems should be rewarding to the user. But there are rewards and there are rewards. There are short-term dopamine fix rewards, and then there are the rewards that you can only really appreciate after having invested some time and energy first. It's like fast food vs a lifetime of diet and exercise. The churn in the frontend ecosystem reminds me a lot of fad dieting: people have never really experienced working in a paradigm that enables them to stay healthy through regular diet and exercise over the long term, so they turn to the latest shiny gizmo hoping that this time it will be different.

notpachet 5y ago

I agree with your point that not every application needs this degree of separation of concerns. But the problem, in my experience, is that individual developers are not very good at knowing where that line is. And the line can move over time as the application grows. For any project that I'm responsible for, I don't feel comfortable designing around a paradigm unless there are some guard rails to prevent developers on my team from accidentally tying the code in knots. How enjoyable is this for the developers? Are they sprouting angel wings and playing the lyre as they write code in iambic pentameter? Probably not, no. They have less freedom of motion than if they were left to their own devices. This is a larger debate: where to fall on the spectrum between unadulterated developer bliss and having an application that is still maintainable in 5 years. I don't put much stock in developer bliss, but I do appreciate that the sword cuts both ways.

catlifeonmars 5y ago
I’m curious if the statement “happy developers create better systems” holds any weight.

acemarke 5y ago

Hi, I'm a Redux maintainer. I've written extensively about the fact that A) Redux _has_ been overused, B) that many of the complaints were really more about the standard code patterns needed and the "boilerplate" involved, and that C) "modern Redux" with our official Redux Toolkit package and the React-Redux hooks API has solved those "boilerplate" concerns. Redux is still by far the most widely used state management tool with React apps (my estimates are around 45-50% of React apps use Redux), and we try to give clear guidance in our docs on when it does and doesn't make sense to use Redux. FWIW, we get highly positive feedback on a daily basis from users who tell us how much they love using Redux Toolkit. Resources: - https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet... - https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff... - https://blog.isquaredsoftware.com/2021/05/state-of-redux-may-2021/ https://blog.isquaredsoftware.com/2021/05/state-of-redux-may... - https://blog.isquaredsoftware.com/2021/05/learn-modern-redux-livestream/ https://blog.isquaredsoftware.com/2021/05/learn-modern-redux... - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... - https://redux.js.org/tutorials/index https://redux.js.org/tutorials/index - https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu...

deleted 5y ago
[deleted]
Lhiw 5y ago
Has redux fixed its broken implementation of event sourcing and cqrs yet or is it still encouraging people to execute side effects in reducers?
what_is_orcas 5y ago
I'll add to that: I love redux and most of the complaints or concerns that I've heard about using redux (from a few teams) have been misunderstandings of how to integrate redux into an existing application or an application design. I think this has mostly come from junior-level folks (independent of title, there are a lot of non-junior devs who can't integrate new patterns into their "senior" level understanding of code, but I digress) and folks who don't work on the front end much (or ever). I was one of those folks until I started a side-project that used redux and I had to implement it in a greenfield project and had the liberty to refactor as I progressed and my mental-model "updated" to integrate the new framework.

zaksingh 5y ago

A big challenge with the React ecosystem is that it's the first technology many new developers work with. They don't have a frame of reference for what alternative approaches exist, and therefore 'best practices' are taken on faith and followed blindly until their nuances can be learned through experience. That's not a bad thing (and it's better than the alternative of not caring for design patterns whatsoever). It's part of the learning process, and since there are so many beginner developers who are using React, their perspective is much 'louder' than in other dev ecosystems. You can see this in the absurd amount of introductory-level React content posted to Medium, DevTo, Twitter, etc. This has bred a very strong 'follow-the-leader' culture where, when the one person is the room who _does_ know what they're talking about makes a statement, others will repeat it verbatim without understanding its nuances due to a lack of experience/context. Redux suffered heavily from this. New React devs in 2017 were faced with mountains of tutorials which all used Redux. Many of these tutorials were written by other newbies. Your mental model of React dev was then shaped around Redux. Therefore you would put everything you could into the Redux store, which is a bad idea -- you usually don't need form state in there, for example. Then some React thought-leaders saw this problem and inadvertently created a counter-movement by raising how Redux was overkill for some use cases, which was misconstrued as 'you shouldn't use redux _at all_'. The pendulum has been swinging back and forth ever since. Yes, not every application needs separation of concerns. But some definitely do. It's not black and white, and that unfortunately means there's no definable 'best practice' that can be tweeted or blogged about and followed blindly -- it just has to be learned from experience.

codecurve 5y ago
I would go one step further and say that the counter-movement is the visible effect of newcomers discovering that separation of concerns was a bad decision for the simple apps they were building. Or maybe more accurately, discovering that it's often simpler to separate by concern at the component level, than at the app level. We all ride the pendulum until we find the shade of grey which works best for us.
anchpop 5y ago
> Therefore you would put everything you could into the Redux store, which is a bad idea -- you usually don't need form state in there, for example. Why's that? IME it is usually simplest to just put everything in redux. For example, if you have a form under some kind of tab navigation thing, you'd ideally want the form state to be preserved even when they tab out and then back in. Putting it in redux means you don't really have to think about it

toinbis 5y ago

Am wondering what react community thinks of DDD. I've been reading "blue" DDD book (by Eric Evans) and "red" book (by Vaugh Vernon) and that was a completely "my whole life was a lie" type of experience and relief at the same time. It's just so great to have the principles of who to structure the code. It, by definition makes, your codebase structure meaningful. Because it's structured according to some common knowledge, not your random thoughts at the time you were writing code. I was surprised to find so little DDD react sample codebases. Let's say for backend there is huge amount of samples, i.e. https://github.com/kgrzybek/modular-monolith-with-ddd https://github.com/kgrzybek/modular-monolith-with-ddd . For react/frontend I have bookmarked only https://github.com/talyssonoc/react-redux-ddd/tree/master/src https://github.com/talyssonoc/react-redux-ddd/tree/master/sr... and few more, but those others does not meet the optional criteria i like really much - at the highest (or at app) level all codebase need to have folders app, domain, infra and ui. Simple rule, but simplifies life a lot. So my question is - is DDD for some reasons not very applicable for app frontend development. Or it just never became popular. Or maybe DDD is popular amongst react developers, just I am not aware of this. Many thanks for any ideas and comments!