7 ms·

One of the best examples of this complexity inflation problem I always see is the Redux pattern in frontends. This pattern comes with a lot of overhead, a lot o

by andix 4y ago

One of the best examples of this complexity inflation problem I always see is the Redux pattern in frontends. This pattern comes with a lot of overhead, a lot of things that need to line up (Actions, Reducers, Actioncreators, Selectors, ...). And most of the time the applications that use it are completely trivial. If you remove Redux, half of the code is gone, it's faster and easier to understand and extend.

davedx 4y ago
To be fair most front-end projects have abandoned redux now. It was for sure boilerplate hell.
- andix 4y ago
  Tell that to European corporations. Angular + NgRx/NGXS is the de-facto gold standard there.
  - dmix 4y ago
    What were they using before?
  - wildrhythms 4y ago
    I think Observables are much simpler to grok than some hundreds-line multi-file combined reducer/actions amalgamation.
    - andix 4y ago
      I think React hooks are so much easier to write than observables. It provides similar functionality to observables, but without the added complexity.
- arcturus17 4y ago
  I've been doing some research recently and it continues to be by far the most popular state management framework for React. The fact that there are alternatives doesn't mean that most projects have abandoned it.
  - soft_dev_person 4y ago
    Do these metrics count "no framework" as an option? With hooks, context and separation of concerns, most apps can live very well without any "state management framework" at all.
  - meindnoch 4y ago
    Has it occurred to you that maybe “state management” is not something you need a framework for?
    - Jasp3r 4y ago
      Tell me you're not making complex webapps without telling you're not making complex webapps
      - idlewan 4y ago
        The publish-subscribe/observer/mediator pattern is perfectly fine for state management, and doesn't need a framework. At most, a small-ish library, but you can also re-implement it yourself quite easily. Reading your comment, I have the impression you took it as "there shouldn't be any state management necessary", instead of "state management doesn't need a framework" sense.
        ketzo 4y ago
        "State management is complex, so we used a framework to make things easier." "Why use a widely popular, well-documented, battle-tested framework? Just have one of your senior devs build something over the weekend. This will definitely reduce complexity." Like... I get what you're saying. But "build your own" is not a default answer for an extremely complicated software engineering topic (which, yes, state management is!)
        acemarke 4y ago
        FWIW, Redux literally _is_ a pub-sub/observer pattern implementation :) And the Redux core library _is_ extremely small. But, that led to the community building hundreds of addon libraries for the same sets of use cases, which is what led us to build our official Redux Toolkit package to simplify standard Redux usage patterns.
- acemarke 4y ago
  Redux is still by _far_ the most widely used state management library in React apps. By my estimates, around 35-40% of all React apps use Redux, and that's far more than any other state library in the ecosystem: - https://blog.isquaredsoftware.com/2022/07/npm-package-market-share-estimates/ https://blog.isquaredsoftware.com/2022/07/npm-package-market...
  - player2121 4y ago
    True but not for new projects. Legacy software has quite a long life span.
- spaceman_2020 4y ago
  What are people using now? Good old context?
  - dsego 4y ago
    Things like react-query for syncing with server state (which can be most state in web apps) are getting popular, or smaller hook-oriented stores, like zustand, jotai or recoil for true client-side state.
    - spaceman_2020 4y ago
      Second time today that someone has mentioned React-query to me. Sign that I need to look that up finally
- hbrn 4y ago
  What's interesting is why was it so widely accepted in the first place. It's not like boilerplate reveals itself at later stages, it's right there from the beginning. I think it tells a lot about the state of the industry.
ilrwbwrkhv 4y ago
All this complexity is actually a counter reaction to frontend developers not being considered to be real developers. They went overboard trying to prove that they are.
- andix 4y ago
  I think there is some truth in that thought. If they spend some of their energy into learning a backend technology, this would be much better spent effort. From my experience frontend-only developers are often very limited in their programming skills. Frontend development has its own complicated challenges, but usually the programming part is quite trivial compared to backend. And a lot of logic inside frontends would be better off in the backend (Full Stack developer speaking here).
- booleandilemma 4y ago
  See: microfrontends
- wellanyway 4y ago
  Savage, but a very interesting take.
mojuba 4y ago
Same for MVC/MVVM and Co specifically on mobile. These things were created to teach beginners a few important concepts, mainly separation of concerns. MVC/MVVM work well on toy sample projects with 2-3 pages but can ruin a larger project. Somehow wherever I'm seeing MVVM applied there's also messy, buggy, impenetrable code around it. I don't think it's a coincidence.
- mpweiher 4y ago
  MVVM: yes, in most cases. There are some cases where it's a godsend, but most of the uses I have seen are ... not entirely sane. But MVC? That's pretty minimal in terms of what you're going to do anyway if you have functionality (model) and will be interacting with it (view). Controllers are often misunderstood, and in the case of Apple massively misapplied (Massive View Controllers).
  - marcosdumay 4y ago
    It doesn't help that there are dozens of different definitions of MVC running around. The very clearly uses one that is different from yours. The thing is that, whatever definition you use, you should have almost all of your code in one of those layers, a small minority on another, and shouldn't even remember exactly how to change the other (unless you start many projects). If that's not the case, your code architecture is working against you.
  - jim180 4y ago
    Agreed on that controllers are often misunderstood. I saw them to become both: a view and a model at the same time. :(
    - mpweiher 4y ago
      What's important to realise is that the elements in MVC are roles not entities. So for example Views in Cocoa actually fulfil both the View and (largely) the Controller role. Which is why ViewControllers confused me greatly when they came out. Like they confuse most of the Apple-ecosystem code out there these days. While I do understand how they got there, that doesn't make it better...
acemarke 4y ago
Hi, I'm a Redux maintainer. I'll definitely agree that Redux _has_ been overused. But it's also worth understanding _why_ Redux was created in the first place and why it got so popular. As a brief recap: the first major wave of JS MVC frameworks had major flaws. Angular's dirty checking didn't scale and was impossible to debug. Backbone's event-based system led to events ricocheting around the app with no way to trace what would happen when a given value changed. Additionally, manual DOM manipulation made it hard to manage ongoing changes to the UI over time. This led to Facebook designing React to let devs write encapsulated components with predictable output and behavior, but React didn't have a solution for larger global state. Facebook later announced a "Flux Architecture" concept that tried to make larger app state updates predictable through centralization. The React community ran with this idea and produced dozens of Flux-inspired libraries. Redux took the ideas from several of those Flux libraries, and applied Functional Programming principles, with the goal of making it easier to understand when, where, why, and how your state is being updated and changing over time. The community then adopted Redux because A) it was the best of all the Flux implementations, B) it _did_ address the issues people were running into around state management, C) it was designed to work well with React, and D) it also incidentally helped work around limitations in React's original Context API. (I've talked about the original intent and purpose extensively in my blog posts and conference talks [0] [1].) After that, yes, Redux _did_ get shoved into many applications that didn't need it, in the same way that React has been used for many sites that didn't necessarily require that setup. So, we've always recommended that people actually take the time to evaluate the specific problems they need to solve in their app, and make an informed decision on whether Redux is an appropriate solution for those problems [2]. Beyond that, we've specifically designed and built our official Redux Toolkit package [3] [4] to eliminate the old "boilerplate" concerns. "Modern Redux" with Redux Toolkit and React-Redux hooks is _much_ easier to learn and use than the original Redux patterns, and we get highly positive feedback on a daily basis from folks who enjoy using RTK. We also built an "RTK Query" data fetching and caching API [5], as data fetching is the most common thing that apps need to do today. [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://blog.isquaredsoftware.com/series/presentations https://blog.isquaredsoftware.com/series/presentations [2] https://redux.js.org/tutorials/essentials/part-1-overview-concepts#when-should-i-use-redux https://redux.js.org/tutorials/essentials/part-1-overview-co... [3] https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today [4] https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/ https://blog.isquaredsoftware.com/2022/06/presentations-mode... [5] https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview
JoeyJoJoJr 4y ago
The problem has always been immutable state. JavaScript doesn’t have ergonomic constructs to handle immutable state very well. IMO, immutability shouldn’t even be enforced by the view rendering layer. Immutability in React is enforced to cater to the needs of React’s implementation, and not the needs of the developer. It should be a choice by the developer whether or not they store their state in immutable data structures. Hooks are marketed as a means to make React into more of a framework, but the reality is that they are an attempt to smooth over the problems surrounding immutable state. Solid js also doesn’t solve this problem, even if it has more ergonomic ways of dealing with the problem. Digging deeper, it seems to me that attempting to subvert the standard behaviour of the DOM will always produce a leaky abstraction, and it negates the benefits of working on a standardised platform.

by andix 4y ago

davedx 4y ago

To be fair most front-end projects have abandoned redux now. It was for sure boilerplate hell.

andix 4y ago
Tell that to European corporations. Angular + NgRx/NGXS is the de-facto gold standard there.
- dmix 4y ago
  What were they using before?
- wildrhythms 4y ago
  I think Observables are much simpler to grok than some hundreds-line multi-file combined reducer/actions amalgamation.
  - andix 4y ago
    I think React hooks are so much easier to write than observables. It provides similar functionality to observables, but without the added complexity.
arcturus17 4y ago
I've been doing some research recently and it continues to be by far the most popular state management framework for React. The fact that there are alternatives doesn't mean that most projects have abandoned it.
- soft_dev_person 4y ago
  Do these metrics count "no framework" as an option? With hooks, context and separation of concerns, most apps can live very well without any "state management framework" at all.
- meindnoch 4y ago
  Has it occurred to you that maybe “state management” is not something you need a framework for?
  - Jasp3r 4y ago
    Tell me you're not making complex webapps without telling you're not making complex webapps
    - idlewan 4y ago
      The publish-subscribe/observer/mediator pattern is perfectly fine for state management, and doesn't need a framework. At most, a small-ish library, but you can also re-implement it yourself quite easily. Reading your comment, I have the impression you took it as "there shouldn't be any state management necessary", instead of "state management doesn't need a framework" sense.
      - ketzo 4y ago
        "State management is complex, so we used a framework to make things easier." "Why use a widely popular, well-documented, battle-tested framework? Just have one of your senior devs build something over the weekend. This will definitely reduce complexity." Like... I get what you're saying. But "build your own" is not a default answer for an extremely complicated software engineering topic (which, yes, state management is!)
      - acemarke 4y ago
        FWIW, Redux literally _is_ a pub-sub/observer pattern implementation :) And the Redux core library _is_ extremely small. But, that led to the community building hundreds of addon libraries for the same sets of use cases, which is what led us to build our official Redux Toolkit package to simplify standard Redux usage patterns.
acemarke 4y ago
Redux is still by _far_ the most widely used state management library in React apps. By my estimates, around 35-40% of all React apps use Redux, and that's far more than any other state library in the ecosystem: - https://blog.isquaredsoftware.com/2022/07/npm-package-market-share-estimates/ https://blog.isquaredsoftware.com/2022/07/npm-package-market...
- player2121 4y ago
  True but not for new projects. Legacy software has quite a long life span.
spaceman_2020 4y ago
What are people using now? Good old context?
- dsego 4y ago
  Things like react-query for syncing with server state (which can be most state in web apps) are getting popular, or smaller hook-oriented stores, like zustand, jotai or recoil for true client-side state.
  - spaceman_2020 4y ago
    Second time today that someone has mentioned React-query to me. Sign that I need to look that up finally
hbrn 4y ago
What's interesting is why was it so widely accepted in the first place. It's not like boilerplate reveals itself at later stages, it's right there from the beginning. I think it tells a lot about the state of the industry.

ilrwbwrkhv 4y ago

All this complexity is actually a counter reaction to frontend developers not being considered to be real developers. They went overboard trying to prove that they are.

andix 4y ago
I think there is some truth in that thought. If they spend some of their energy into learning a backend technology, this would be much better spent effort. From my experience frontend-only developers are often very limited in their programming skills. Frontend development has its own complicated challenges, but usually the programming part is quite trivial compared to backend. And a lot of logic inside frontends would be better off in the backend (Full Stack developer speaking here).
booleandilemma 4y ago
See: microfrontends
wellanyway 4y ago
Savage, but a very interesting take.

mojuba 4y ago

Same for MVC/MVVM and Co specifically on mobile. These things were created to teach beginners a few important concepts, mainly separation of concerns. MVC/MVVM work well on toy sample projects with 2-3 pages but can ruin a larger project. Somehow wherever I'm seeing MVVM applied there's also messy, buggy, impenetrable code around it. I don't think it's a coincidence.

mpweiher 4y ago
MVVM: yes, in most cases. There are some cases where it's a godsend, but most of the uses I have seen are ... not entirely sane. But MVC? That's pretty minimal in terms of what you're going to do anyway if you have functionality (model) and will be interacting with it (view). Controllers are often misunderstood, and in the case of Apple massively misapplied (Massive View Controllers).
- marcosdumay 4y ago
  It doesn't help that there are dozens of different definitions of MVC running around. The very clearly uses one that is different from yours. The thing is that, whatever definition you use, you should have almost all of your code in one of those layers, a small minority on another, and shouldn't even remember exactly how to change the other (unless you start many projects). If that's not the case, your code architecture is working against you.
- jim180 4y ago
  Agreed on that controllers are often misunderstood. I saw them to become both: a view and a model at the same time. :(
  - mpweiher 4y ago
    What's important to realise is that the elements in MVC are roles not entities. So for example Views in Cocoa actually fulfil both the View and (largely) the Controller role. Which is why ViewControllers confused me greatly when they came out. Like they confuse most of the Apple-ecosystem code out there these days. While I do understand how they got there, that doesn't make it better...

acemarke 4y ago

Hi, I'm a Redux maintainer. I'll definitely agree that Redux _has_ been overused. But it's also worth understanding _why_ Redux was created in the first place and why it got so popular. As a brief recap: the first major wave of JS MVC frameworks had major flaws. Angular's dirty checking didn't scale and was impossible to debug. Backbone's event-based system led to events ricocheting around the app with no way to trace what would happen when a given value changed. Additionally, manual DOM manipulation made it hard to manage ongoing changes to the UI over time. This led to Facebook designing React to let devs write encapsulated components with predictable output and behavior, but React didn't have a solution for larger global state. Facebook later announced a "Flux Architecture" concept that tried to make larger app state updates predictable through centralization. The React community ran with this idea and produced dozens of Flux-inspired libraries. Redux took the ideas from several of those Flux libraries, and applied Functional Programming principles, with the goal of making it easier to understand when, where, why, and how your state is being updated and changing over time. The community then adopted Redux because A) it was the best of all the Flux implementations, B) it _did_ address the issues people were running into around state management, C) it was designed to work well with React, and D) it also incidentally helped work around limitations in React's original Context API. (I've talked about the original intent and purpose extensively in my blog posts and conference talks [0] [1].) After that, yes, Redux _did_ get shoved into many applications that didn't need it, in the same way that React has been used for many sites that didn't necessarily require that setup. So, we've always recommended that people actually take the time to evaluate the specific problems they need to solve in their app, and make an informed decision on whether Redux is an appropriate solution for those problems [2]. Beyond that, we've specifically designed and built our official Redux Toolkit package [3] [4] to eliminate the old "boilerplate" concerns. "Modern Redux" with Redux Toolkit and React-Redux hooks is _much_ easier to learn and use than the original Redux patterns, and we get highly positive feedback on a daily basis from folks who enjoy using RTK. We also built an "RTK Query" data fetching and caching API [5], as data fetching is the most common thing that apps need to do today. [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://blog.isquaredsoftware.com/series/presentations https://blog.isquaredsoftware.com/series/presentations [2] https://redux.js.org/tutorials/essentials/part-1-overview-concepts#when-should-i-use-redux https://redux.js.org/tutorials/essentials/part-1-overview-co... [3] https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today [4] https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/ https://blog.isquaredsoftware.com/2022/06/presentations-mode... [5] https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview

JoeyJoJoJr 4y ago

The problem has always been immutable state. JavaScript doesn’t have ergonomic constructs to handle immutable state very well. IMO, immutability shouldn’t even be enforced by the view rendering layer. Immutability in React is enforced to cater to the needs of React’s implementation, and not the needs of the developer. It should be a choice by the developer whether or not they store their state in immutable data structures. Hooks are marketed as a means to make React into more of a framework, but the reality is that they are an attempt to smooth over the problems surrounding immutable state. Solid js also doesn’t solve this problem, even if it has more ergonomic ways of dealing with the problem. Digging deeper, it seems to me that attempting to subvert the standard behaviour of the DOM will always produce a leaky abstraction, and it negates the benefits of working on a standardised platform.