5 ms·

> I really do think if Redux hadn't been so concerned about being opinionated way back when, it'd be far better received today Can you clarify what you mean he

> I really do think if Redux hadn't been so concerned about being opinionated way back when, it'd be far better received today Can you clarify what you mean here? From my perspective as a Redux maintainer, most of the concerns I've seen expressed about Redux over the last few years really didn't focus on whether it was "opinionated" or not. It's been a combination of: - Not understanding the original intent behind Redux's design and the historical context that led to it being designed that way [0] - People being told they _had_ to use Redux with React, even when it really wasn't a good fit for their use case - The "incidental complexity" of common Redux usage patterns [1], most of which were due to the way the docs and tutorials showed things (writing `const ADD_TODO = "ADD_TODO"`, separate files for actions/constants/reducers, etc). - Changes in the ecosystem leading to other tools whose use cases overlapped with why you might have chosen to use Redux previously All that said, yeah, we've made a concerted effort in the last year or so to be much more opinionated about how you _ought_ to use Redux, based on how we've seen people use it. Those opinions are built into our new official Redux Toolkit package [0], which is now our recommended approach for writing Redux logic, and the Redux Style Guide docs page [1], which lists our guidance on best practices and patterns for using Redux. I also just published a brand-new "Redux Essentials" core docs tutorial [2], which teaches "how to use Redux, the right way", using our latest recommended tools and practices like Redux Toolkit and the React-Redux hooks API. We unfortunately can't wave a magic wand and get folks to update the seemingly endless parade of Medium tutorials and Youtube videos that show the older approaches to using Redux, but I'm hopeful that the emphasis on using RTK will make it a lot easier for folks to learn and use Redux going forward. [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/2019/10/redux-starter-kit-1.0/#dealing-with-complexity https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-... [2] https://redux-toolkit.js.org https://redux-toolkit.js.org [3] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide [4] https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co...

city41 6y ago
You certainly have more experience and context than me. But my experience with Redux over the years is there was so many ways to do it leading to a lot of uncertainty. Do you use a switch statement or something like redux-actions? Do you use the duck pattern, where do all these things live in the codebase? What package do you grab for async actions? Are actions 1:1 with DOM events, or are they more like a state machine? How do you compose reducers? Should you compose reducers? I think this led to a lot of confusion and uncertainty with Redux. "I'm using it, but I'm not sure I'm using it effectively." I think a lot of ineffective implementations caused a lot of developers to get a really bad taste. I can unfortunately say at my previous company, just mentioning Redux would make just about every developer cringe. I hated that. But I feel like a lot of what is making Redux more successful these days is the more opinionated releases like the toolkit and the new docs. Since they've only been around about a year now, I think it's reasonable to conclude that before their existence, Redux didn't have a strong opinion a new developer could lean on. It's similar to React, which also tries to avoid opinions. I can appreciate and understand that approach (for both React and Redux), but I do wonder would React be better if there was a stronger opinion on things like CSS, routing, state, etc? I don't mean to criticize. I love Redux and am very grateful for it. This is just how I experienced it over the years.
- acemarke 6y ago
  I certainly get where you're coming from, and agree that all of the questions you listed are things we didn't express opinions on previously and had to decide for yourself. Still, the bulk of the concerns I've seen over time fall into the categories I've listed - I just really don't remember seeing many comments from folks who were concerned that they "weren't using it effectively" as a particular pain point. Perhaps that was being felt, but expressed in different ways? (I definitely think a lot of people _haven't_ been using it effectively, but didn't necessarily realize it.) In any case, the highly positive response to RTK and the docs work tells me we're headed in the right direction. My next task is to rewrite the existing low-level "Basics/Advanced" tutorial sequence to remove outdated references, show simpler patterns, and improve explanations. I've got my notes on things I want to change here: https://github.com/reduxjs/redux/issues/3855 https://github.com/reduxjs/redux/issues/3855 If you or anyone else has any particular feedback on things you don't like with that existing tutorial or would like to see covered better, please comment and let me know!
weeksie 6y ago
Man I wish you’d quit spamming every redux thread with this stuff. You’re not solving any problems, you’re just promoting your framework.
- vosper 6y ago
  I don't think this comment is fair - acemarke does show up in virtually every Redux discussion on HN, but I've found his comments to be reasonable and helpful. I don't think labeling them as spam is justified. He makes an effort to address specific points, doesn't get defensive or angry, and seems to take criticism and feedback seriously. He has responded to my own critiques of Redux in a reasoned way. I think that if someone is going to express claims or opinions about a library on HN then we should be happy to see an expert response, rather than letting the discussion become one-sided. Sure, there could be a bias, but I think we all win by having both sides represented. Do we really want to discourage that?
  - weeksie 6y ago
    I see it as someone clout-chasing for their framework. A framework that promotes questionable practices. Framework developers and working engineers have diverging interests. The problem with his style is that he parades himself as an expert but he's emphatically not an expert. He's a guy with an agenda to push his open source framework. I understand where the bias toward politeness comes from, but that makes groups like HN susceptible to this kind of pretense to authority. He's actively making working developers' lives worse by promoting this stuff and it's frustrating. Perhaps I shouldn't give a shit.
    - acemarke 6y ago
      > The problem with his style is that he parades himself as an expert but he's emphatically not an expert Erm... I've been a Redux maintainer since mid-2016. I oversaw development of React-Redux v5 and v6, wrote v7 by myself, and directed development of the hooks API in v7.1 over the course of multiple 250+-comment issue threads. I've written the Redux FAQ, "Structuring Reducers" usage guide, the "Style Guide" best practices page, almost all of the Redux Toolkit docs, and the new 25K-word "Redux Essentials" real-world tutorial. I've written about 150K words of Redux-related blog posts, including tutorials, history, technical architecture, and best practices. I've given multiple conference talks on how Redux works and how to use it. Even if you don't agree with the approaches I'm recommending that folks use... if _I_ don't qualify as an "expert" on this topic, who _does_? :) If you have actual substantive technical arguments for other approaches we should be recommending, please feel free to open up an issue to discuss them. I'm genuinely always interested in ways we can make it easier for people to learn and use Redux.

city41 6y ago

You certainly have more experience and context than me. But my experience with Redux over the years is there was so many ways to do it leading to a lot of uncertainty. Do you use a switch statement or something like redux-actions? Do you use the duck pattern, where do all these things live in the codebase? What package do you grab for async actions? Are actions 1:1 with DOM events, or are they more like a state machine? How do you compose reducers? Should you compose reducers? I think this led to a lot of confusion and uncertainty with Redux. "I'm using it, but I'm not sure I'm using it effectively." I think a lot of ineffective implementations caused a lot of developers to get a really bad taste. I can unfortunately say at my previous company, just mentioning Redux would make just about every developer cringe. I hated that. But I feel like a lot of what is making Redux more successful these days is the more opinionated releases like the toolkit and the new docs. Since they've only been around about a year now, I think it's reasonable to conclude that before their existence, Redux didn't have a strong opinion a new developer could lean on. It's similar to React, which also tries to avoid opinions. I can appreciate and understand that approach (for both React and Redux), but I do wonder would React be better if there was a stronger opinion on things like CSS, routing, state, etc? I don't mean to criticize. I love Redux and am very grateful for it. This is just how I experienced it over the years.

acemarke 6y ago
I certainly get where you're coming from, and agree that all of the questions you listed are things we didn't express opinions on previously and had to decide for yourself. Still, the bulk of the concerns I've seen over time fall into the categories I've listed - I just really don't remember seeing many comments from folks who were concerned that they "weren't using it effectively" as a particular pain point. Perhaps that was being felt, but expressed in different ways? (I definitely think a lot of people _haven't_ been using it effectively, but didn't necessarily realize it.) In any case, the highly positive response to RTK and the docs work tells me we're headed in the right direction. My next task is to rewrite the existing low-level "Basics/Advanced" tutorial sequence to remove outdated references, show simpler patterns, and improve explanations. I've got my notes on things I want to change here: https://github.com/reduxjs/redux/issues/3855 https://github.com/reduxjs/redux/issues/3855 If you or anyone else has any particular feedback on things you don't like with that existing tutorial or would like to see covered better, please comment and let me know!

weeksie 6y ago

Man I wish you’d quit spamming every redux thread with this stuff. You’re not solving any problems, you’re just promoting your framework.

vosper 6y ago
I don't think this comment is fair - acemarke does show up in virtually every Redux discussion on HN, but I've found his comments to be reasonable and helpful. I don't think labeling them as spam is justified. He makes an effort to address specific points, doesn't get defensive or angry, and seems to take criticism and feedback seriously. He has responded to my own critiques of Redux in a reasoned way. I think that if someone is going to express claims or opinions about a library on HN then we should be happy to see an expert response, rather than letting the discussion become one-sided. Sure, there could be a bias, but I think we all win by having both sides represented. Do we really want to discourage that?
- weeksie 6y ago
  I see it as someone clout-chasing for their framework. A framework that promotes questionable practices. Framework developers and working engineers have diverging interests. The problem with his style is that he parades himself as an expert but he's emphatically not an expert. He's a guy with an agenda to push his open source framework. I understand where the bias toward politeness comes from, but that makes groups like HN susceptible to this kind of pretense to authority. He's actively making working developers' lives worse by promoting this stuff and it's frustrating. Perhaps I shouldn't give a shit.
  - acemarke 6y ago
    > The problem with his style is that he parades himself as an expert but he's emphatically not an expert Erm... I've been a Redux maintainer since mid-2016. I oversaw development of React-Redux v5 and v6, wrote v7 by myself, and directed development of the hooks API in v7.1 over the course of multiple 250+-comment issue threads. I've written the Redux FAQ, "Structuring Reducers" usage guide, the "Style Guide" best practices page, almost all of the Redux Toolkit docs, and the new 25K-word "Redux Essentials" real-world tutorial. I've written about 150K words of Redux-related blog posts, including tutorials, history, technical architecture, and best practices. I've given multiple conference talks on how Redux works and how to use it. Even if you don't agree with the approaches I'm recommending that folks use... if _I_ don't qualify as an "expert" on this topic, who _does_? :) If you have actual substantive technical arguments for other approaches we should be recommending, please feel free to open up an issue to discuss them. I'm genuinely always interested in ways we can make it easier for people to learn and use Redux.