4 ms·

The React ecosystem has been trying very hard for a long time to enable developers to write code that is objectively bad, vis-a-vis colocation of concerns all i

The React ecosystem has been trying very hard for a long time to enable developers to write code that is objectively bad, vis-a-vis colocation of concerns all in a single bigass, hard-to-understand function. Hooks were last straw for me, but the trend began before that. React components should be simple stream transformers, nothing more. Accept props as input, produce deterministic HTML as output. All that other crap? Calling the API, massaging the data, business logic? That belongs somewhere else, outside of your component.

andix 3y ago
What you're proposing sounds nice in theory. But interactive UI code is always kind of a mess. In my experience react is a very good middle ground. And nobody is forcing react developers to mix too many responsibilities into one component.
- notpachet 3y ago
  Nobody's forcing them, no. But often there isn't anyone preventing them, either. React happily hands these developers enough rope to hang themselves. To be clear: I don't mind React per se. Some of the best UI codebases I've worked in were React -- they just had a very strict separation of concerns and one-directional data flow via something like MobX or Redux. All the business logic was kept separate from the UI. But that's not fashionable these days.
  - andix 3y ago
    I have to say that I've seen Redux being abused until insanity (and probably misunderstood) much more often than hooks. And much harder to clean up that mess, because it's a centralized mess. The hook mess is usually decentralized and can be improved incrementally. What kind of frontend stack would you recommend that enforces keeping some meaningful separation of concern, without limiting productivity?
    - notpachet 3y ago
      I will concede your point about horrible Redux codebases. I think I've tried to push that dark era out of my mind. Without limiting productivity, I have no idea. I think you have to limit productivity along some axis or other, otherwise your codebase just turns to quicksand.

andix 3y ago

What you're proposing sounds nice in theory. But interactive UI code is always kind of a mess. In my experience react is a very good middle ground. And nobody is forcing react developers to mix too many responsibilities into one component.

notpachet 3y ago
Nobody's forcing them, no. But often there isn't anyone preventing them, either. React happily hands these developers enough rope to hang themselves. To be clear: I don't mind React per se. Some of the best UI codebases I've worked in were React -- they just had a very strict separation of concerns and one-directional data flow via something like MobX or Redux. All the business logic was kept separate from the UI. But that's not fashionable these days.
- andix 3y ago
  I have to say that I've seen Redux being abused until insanity (and probably misunderstood) much more often than hooks. And much harder to clean up that mess, because it's a centralized mess. The hook mess is usually decentralized and can be improved incrementally. What kind of frontend stack would you recommend that enforces keeping some meaningful separation of concern, without limiting productivity?
  - notpachet 3y ago
    I will concede your point about horrible Redux codebases. I think I've tried to push that dark era out of my mind. Without limiting productivity, I have no idea. I think you have to limit productivity along some axis or other, otherwise your codebase just turns to quicksand.