6 ms·

Back when I was doing React, what pulled me in was that it WASN'T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in R

Back when I was doing React, what pulled me in was that it WASN'T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in React terms) that worked within a page, and were composable with other UI widgets. With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets, but while it was a lot of typing, it was all fairly easy, and if I wanted to change how an event was handled, it usually only involved a component and MAYBE the components immediately above or below it in the component tree. Data passed further than that was generally wrapped in objects and therefore didn't require code changes. Then introduce Redux and similar frameworks, and I totally lost interest. It's as if the entire React community forgot all the lessons they learned writing Python and C programs in college and went back to creating global state. What in the actual hell? I wrote a good amount of code in Redux, too--I worked on teams that used it--so this wasn't just pre-judgment. These frameworks add a huge amount of hidden global complexity just to avoid having to pass parameters to components, which is the simplest thing to do. And once you're doing that, you HAVE TO write an SPA, because any part of the page you want to be interactive gets pulled into Redux and your JS eventually eats the whole page. It's an infection. When writing JavaScript now, I sometimes end up rolling my own version of the component style. It's an effective design pattern for UI widgets. But it hasn't been worth it to use React for a while now because the tooling and tutorials are all too conflated with Redux and similarly awful tools. And on a team, there's always the worry that someone on your team will infect your code with Redux and it will grow and consume your entire site. It's a real shame.

k__ 8y ago
I don't think Redux is that big of a deal as you describe it. Many people just use setState. Since my last Redux project in 2015, I did many React and React-Native projects and not one of them used Redux.
- kerkeslager 8y ago
  You've been lucky then. I've worked on a few teams (I'm a freelancer) and even when they didn't add Redux, it's been something I've had to argue against.
  - k__ 8y ago
    sounds bad. I only did green-field projects where I was the only front-end dev.
WrtCdEvrydy 8y ago
Redux was the solution to server side rendering state. If you don't use redux, then keeping state synced with a server side rendered application because nearly impossible.
- kerkeslager 8y ago
  > Redux was the solution to server side rendering state. Could you explain what you mean by "server side rendering state"?
  - WrtCdEvrydy 8y ago
    Server side rendering mounts your application in the server and sends down html along with an initial state. The client receives this initial state and uses it with the html to glue together a working UI on the client. This removes the massive JS bloat into raw html and split JS for each component. Instead of sending 3MB of JS, you send only the JS needed to render the current page... and send additional JS as a user navigates through your website. Here's an example with Create React App: https://github.com/cereallarceny/cra-ssr https://github.com/cereallarceny/cra-ssr
    - kerkeslager 8y ago
      Okay, but that's an even worse idea than what I've seen Redux used for. Now you're splitting the UI between client and server in a completely custom way, that adds even more complexity. Worse, the performance is likely to be worse because now you're paying the bulk JS load cost of loading Redux AND the latency cost of loading small parts as you go: the worst of both worlds. I doubt this is what the Redux folks had in mind, but if it was, it's even worse than I thought.
      - s_y_n_t_a_x 8y ago
        Redux is tiny. And with HTTP2 it's better to send multiple small resources than one large payload, especially when it's JS which will lock up when parsing.
chosenbreed37 8y ago
> Then introduce Redux and similar frameworks, and I totally lost interest. It's as if the entire React community forgot all the lessons they learned writing Python and C programs in college and went back to creating global state. What in the actual hell? Fair point. But could it be possible that there are lots of people doing React that never went to college and never wrote Python or C programs?
- kerkeslager 8y ago
  That's true, and possibly the source of the problem.
- barbecue_sauce 8y ago
  Or people who went to college but not for Computer Science.
skosch 8y ago
I'm surprised you dislike Redux simply because it's a form of global state. Sure, global variables make debugging difficult when you don't know which function changed them where and when and why. But that doesn't happen if you keep your functions pure and only make changes from within reducers – at least that's my experience. (Boilerplate, yes, Redux adds that. But at least it's all in one place, and not scattered throughout your app.)
- jorgeleo 8y ago
  Anecdotical comment: While studying computer science, I almost fail a test because I used global variables. Since then I avoid them like the plage, and I get rashes when I see them. And I thank my teacher for knocking the bad habit out of me. So when I see global variables beyond the initialization of core objects, I take it as a bad code smell.
  - ghthor 8y ago
    Global variables are different from global state. Every program has global state, whether you like it or not. Global variables are a poor way to declare, mutate, and read global state.
    - kerkeslager 8y ago
      > Every program has global state Could you explain what you mean by this? My intuition here is that what you're saying is true in a trivial sense, but that most state CAN BE (and should be) local if you're breaking your programs into reasonable building blocks.
      - johannes1234321 8y ago
        You have information which has global nature, used in multiple sorts of the application. This could be, among other things - STDIN/STDOUT/STDERR file handles - static configuration - some parts of runtime configuration - application info (in a game maybe current score, current level, active players, ...) All that information exists only once and is needed in many parts.
joshuacc 8y ago
> These frameworks add a huge amount of hidden global complexity just to avoid having to pass parameters to components, which is the simplest thing to do. Redux offers a few benefits: 1. Allows you to keep your global application state 100% predictable by treating it as a pure function of an event stream (dispatched actions). This makes it trivial to test. 2. Allows you to "time travel" the state of your store using the Redux dev tools by replaying/modifying the event stream. You can also set up QA folks to export their events so that developers can reproduce any bugs in the global state 100% reliably. 3. Allows you to access global state without explicitly passing down props from great-grandparent to great-grandchild. While I'm not a fan of using Redux for everything (it does have costs), you mentioned only the most minor benefit. If you only want #3, you would just use React's built in context API.
- MuffinFlavored 8y ago
  What are some "costs" you think it has?
  - mawburn 8y ago
    Redux definitely adds an extra layer of complexity to a project and a lot more boilerplate. That is what lead to Dan's famous blog post "You Might Not Need Redux" from 2016. https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
- kokokokoko 8y ago
  I have yet to see a long term project built with Redux that was maintainable. That seems to be the common denominator in React projects that do not survive technical debt accumulation. The issue with Redux is that it encourages side effects in components. After a while people are dispatching all over the place and you end up in a similar situation as you were with keeping track of JavaScript events. All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. If you can convince and enforce that all Redux activity only happens at the root component, you should be okay. But the reality is that once you have the discipline to only mutate state in your root component, then setState tends to be more than enough for anything but very large and complex interfaces. With that said this article has the author implementing their homebrew bespoke event system which is likely even worse. This was a very popular and much maligned anti-pattern during Angular 1.x days. This article is suggesting the absolute worst possible idea for maintenance. What kills the maintainability of React and similar frameworks is tracking down what component did what. Unfortunately, in real world examples, in my experience, Redux increases that issue and ultimately leads to a very difficult application to maintain long term.
palerdot 8y ago
Thinking of Redux as a 'detached state tree' that the whole app can subscribe too might give a better picture of some problems that it is solving. In React, when you lift state up and up, you mostly end up tracking lot of irrelevant state in the top most component which kind of weirdly manages lot of state just for their children. There are some genuine use cases of Redux by tracking the whole 'app state' in a detached way, safely update/transform them (with pure functions) and more importantly you could just subscribe for necessary data at any level. Context API is helpful, yes, but Redux (or MObX or any state management tool) is still helpful when done right.
- kerkeslager 8y ago
  > In React, when you lift state up and up, you mostly end up tracking lot of irrelevant state in the top most component which kind of weirdly manages lot of state just for their children. I'm not sure why you think the data is irrelevant, or why the component manages it "weirdly". I'll point out that these top components actually share a lot in common with Redux, except that they can be duplicated and composed with other components, if for example you decide to drop your top component inside of a larger application, and the toplevel components actually don't end up managing data they don't have to (LESS "irrelevant" data than Redux, perhaps?).
  - pault 8y ago
    > I'm not sure why you think the data is irrelevant I believe the GP meant "unrelated". Can you drop your top level component into another application with different children and still have it work? Can you move the child components to another view tree and still have them work? It seems like what you are describing is a top level component that is tightly coupled to its descendants with too many responsibilities. In the ideal react app architecture you should be able to take any component and move it anywhere else in the app and it should Just Work. This is the problem redux is supposed to solve, and I would argue that by enforcing an explicit pattern that most experienced react developers know, you will get closer to that ideal than if you have a variety of home grown solutions that vary from project to project (and even from developer to developer on the same project). "The Tyranny of Structurelessness" etc etc.
kingdomcome50 8y ago
I have to let you in on a big secret. State has always been global. Have you ever worked on an application backed by an RDBMS? Redux simply moves state. It doesn’t expose it any more than a database.
- WorldMaker 8y ago
  I've found that explaining Redux as an in-memory database/ORM helps a lot of colleagues get over the hump of what Redux is for and why people often feel a need for it.

k__ 8y ago

I don't think Redux is that big of a deal as you describe it. Many people just use setState. Since my last Redux project in 2015, I did many React and React-Native projects and not one of them used Redux.

kerkeslager 8y ago
You've been lucky then. I've worked on a few teams (I'm a freelancer) and even when they didn't add Redux, it's been something I've had to argue against.
- k__ 8y ago
  sounds bad. I only did green-field projects where I was the only front-end dev.

WrtCdEvrydy 8y ago

Redux was the solution to server side rendering state. If you don't use redux, then keeping state synced with a server side rendered application because nearly impossible.

kerkeslager 8y ago
> Redux was the solution to server side rendering state. Could you explain what you mean by "server side rendering state"?
- WrtCdEvrydy 8y ago
  Server side rendering mounts your application in the server and sends down html along with an initial state. The client receives this initial state and uses it with the html to glue together a working UI on the client. This removes the massive JS bloat into raw html and split JS for each component. Instead of sending 3MB of JS, you send only the JS needed to render the current page... and send additional JS as a user navigates through your website. Here's an example with Create React App: https://github.com/cereallarceny/cra-ssr https://github.com/cereallarceny/cra-ssr
  - kerkeslager 8y ago
    Okay, but that's an even worse idea than what I've seen Redux used for. Now you're splitting the UI between client and server in a completely custom way, that adds even more complexity. Worse, the performance is likely to be worse because now you're paying the bulk JS load cost of loading Redux AND the latency cost of loading small parts as you go: the worst of both worlds. I doubt this is what the Redux folks had in mind, but if it was, it's even worse than I thought.
    - s_y_n_t_a_x 8y ago
      Redux is tiny. And with HTTP2 it's better to send multiple small resources than one large payload, especially when it's JS which will lock up when parsing.

chosenbreed37 8y ago

> Then introduce Redux and similar frameworks, and I totally lost interest. It's as if the entire React community forgot all the lessons they learned writing Python and C programs in college and went back to creating global state. What in the actual hell? Fair point. But could it be possible that there are lots of people doing React that never went to college and never wrote Python or C programs?

kerkeslager 8y ago
That's true, and possibly the source of the problem.
barbecue_sauce 8y ago
Or people who went to college but not for Computer Science.

skosch 8y ago

I'm surprised you dislike Redux simply because it's a form of global state. Sure, global variables make debugging difficult when you don't know which function changed them where and when and why. But that doesn't happen if you keep your functions pure and only make changes from within reducers – at least that's my experience. (Boilerplate, yes, Redux adds that. But at least it's all in one place, and not scattered throughout your app.)

jorgeleo 8y ago
Anecdotical comment: While studying computer science, I almost fail a test because I used global variables. Since then I avoid them like the plage, and I get rashes when I see them. And I thank my teacher for knocking the bad habit out of me. So when I see global variables beyond the initialization of core objects, I take it as a bad code smell.
- ghthor 8y ago
  Global variables are different from global state. Every program has global state, whether you like it or not. Global variables are a poor way to declare, mutate, and read global state.
  - kerkeslager 8y ago
    > Every program has global state Could you explain what you mean by this? My intuition here is that what you're saying is true in a trivial sense, but that most state CAN BE (and should be) local if you're breaking your programs into reasonable building blocks.
    - johannes1234321 8y ago
      You have information which has global nature, used in multiple sorts of the application. This could be, among other things - STDIN/STDOUT/STDERR file handles - static configuration - some parts of runtime configuration - application info (in a game maybe current score, current level, active players, ...) All that information exists only once and is needed in many parts.

joshuacc 8y ago

> These frameworks add a huge amount of hidden global complexity just to avoid having to pass parameters to components, which is the simplest thing to do. Redux offers a few benefits: 1. Allows you to keep your global application state 100% predictable by treating it as a pure function of an event stream (dispatched actions). This makes it trivial to test. 2. Allows you to "time travel" the state of your store using the Redux dev tools by replaying/modifying the event stream. You can also set up QA folks to export their events so that developers can reproduce any bugs in the global state 100% reliably. 3. Allows you to access global state without explicitly passing down props from great-grandparent to great-grandchild. While I'm not a fan of using Redux for everything (it does have costs), you mentioned only the most minor benefit. If you only want #3, you would just use React's built in context API.

MuffinFlavored 8y ago
What are some "costs" you think it has?
- mawburn 8y ago
  Redux definitely adds an extra layer of complexity to a project and a lot more boilerplate. That is what lead to Dan's famous blog post "You Might Not Need Redux" from 2016. https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
kokokokoko 8y ago
I have yet to see a long term project built with Redux that was maintainable. That seems to be the common denominator in React projects that do not survive technical debt accumulation. The issue with Redux is that it encourages side effects in components. After a while people are dispatching all over the place and you end up in a similar situation as you were with keeping track of JavaScript events. All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. If you can convince and enforce that all Redux activity only happens at the root component, you should be okay. But the reality is that once you have the discipline to only mutate state in your root component, then setState tends to be more than enough for anything but very large and complex interfaces. With that said this article has the author implementing their homebrew bespoke event system which is likely even worse. This was a very popular and much maligned anti-pattern during Angular 1.x days. This article is suggesting the absolute worst possible idea for maintenance. What kills the maintainability of React and similar frameworks is tracking down what component did what. Unfortunately, in real world examples, in my experience, Redux increases that issue and ultimately leads to a very difficult application to maintain long term.

palerdot 8y ago

Thinking of Redux as a 'detached state tree' that the whole app can subscribe too might give a better picture of some problems that it is solving. In React, when you lift state up and up, you mostly end up tracking lot of irrelevant state in the top most component which kind of weirdly manages lot of state just for their children. There are some genuine use cases of Redux by tracking the whole 'app state' in a detached way, safely update/transform them (with pure functions) and more importantly you could just subscribe for necessary data at any level. Context API is helpful, yes, but Redux (or MObX or any state management tool) is still helpful when done right.

kerkeslager 8y ago
> In React, when you lift state up and up, you mostly end up tracking lot of irrelevant state in the top most component which kind of weirdly manages lot of state just for their children. I'm not sure why you think the data is irrelevant, or why the component manages it "weirdly". I'll point out that these top components actually share a lot in common with Redux, except that they can be duplicated and composed with other components, if for example you decide to drop your top component inside of a larger application, and the toplevel components actually don't end up managing data they don't have to (LESS "irrelevant" data than Redux, perhaps?).
- pault 8y ago
  > I'm not sure why you think the data is irrelevant I believe the GP meant "unrelated". Can you drop your top level component into another application with different children and still have it work? Can you move the child components to another view tree and still have them work? It seems like what you are describing is a top level component that is tightly coupled to its descendants with too many responsibilities. In the ideal react app architecture you should be able to take any component and move it anywhere else in the app and it should Just Work. This is the problem redux is supposed to solve, and I would argue that by enforcing an explicit pattern that most experienced react developers know, you will get closer to that ideal than if you have a variety of home grown solutions that vary from project to project (and even from developer to developer on the same project). "The Tyranny of Structurelessness" etc etc.

kingdomcome50 8y ago

I have to let you in on a big secret. State has always been global. Have you ever worked on an application backed by an RDBMS? Redux simply moves state. It doesn’t expose it any more than a database.

WorldMaker 8y ago
I've found that explaining Redux as an in-memory database/ORM helps a lot of colleagues get over the hump of what Redux is for and why people often feel a need for it.