5 ms·

I believe as time passes, we are moving away from the simplicity that made React win. Flux, Redux, higher order components generate too much complexity most of

I believe as time passes, we are moving away from the simplicity that made React win. Flux, Redux, higher order components generate too much complexity most of the time. React used to be simple, it still is, but the ecosystem and the mentality has gotten needlessly complex.

danabramov 10y ago
You can use React without Flux/Redux if that works well for you. The “mentality” is just people solving their own problems in a way that makes sense to them, and sharing those solutions. As noted in the blog post, higher order components are not a React feature. And it is not related to Flux or Redux. It is just a thing you can do with components, like you can do it with functions. We think HOCs are a useful pattern so we explain it, but you don’t need to use it if you don’t get value from it. (We got a lot of value from using it.) That said if you have different solutions to the same problems that don’t suffer from the drawbacks of mixins, we’d love to hear them. This post is not there to force you to use HOCs. It’s for the people who had the same problems we experienced, tried to use mixins to fix them, and couldn‘t scale those solutions.
- zuck9 10y ago
  What I think OP refers to, is how there are so many different choices to do anything in the React ecosystem. It's cool that people share their work. But so many choices just cause decision fatigue. It's hard to have any kind of real-world usage from just React. You have to learn and use some kind of Flux, routing library, AJAX patterns for that Flux library, another library for <inputs> and <forms>, etc. If you want server-side rendering, server-side data persistence or user auth, which you will in real-world cases, you have even more things to connect. Also there aren't any free resources on the internet (that I could find) that teaches me how to put together a basic Twitter or Instagram clone using React + React ecosystem libs. No full-stack tutorials. Compared to Rails, React{ecosystem} is pretty hard to learn. Unless you're an experienced senior dev and understand all the different technologies deeply, you can't make any informed choice about what libraries to use. You just go and pick the most popular ones and later doubt your decision and think that you could be having an easier time if you had picked some other popular library more suited to your project. I guess most beginners just give up on React after trying a bunch of tutorials. I'm no Rails developer, but I guess even if you are a Rails developer with years of experience, you will find it frustrating to get started on React + ecosystem.
  - danabramov 10y ago
    I agree that “getting started” experience is far from optimal. We take this feedback to the heart and want to improve this in the future. But how is this relevant to the post about mixins?
    - zuck9 10y ago
      I see it went OT, sorry about that.
  - tptacek 10y ago
    You really don't need to learn some Flux to solve problems with React. React works fine without Flux, or really any formal data layer; you can comfortably use it simply as a really nice view library. I agree that people give up on React after tutorials that make them think about routing and Flux. It's a shame, because the core concept of React is incredibly simple, and anyone can pick it up in a couple hours. Flux is a useful, experience-based contribution and I'm happy to have it as an option. But it's heavily cargo-culted.
    - quantumhobbit 10y ago
      This, much more of this, please. I've been part of a small react project that was doing just fine without flux. Then the tech lead, a enterprise Java guy, decided we needed to use Flux because it was the "best practice". Problem was none of us understood Flux or how the project would benefit from it. It was pure cargo culting. Needless to say the whole thing became a huge mess as we spent all our time moving data to the store and back into the components. What is sad is that if the project had been allowed to evolve naturally, we might have ended up with a poor man's version of a Flux architecture, possibly even using Flux as a guide. Instead we had to force the project into a Flux pattern we didn't understand and wound up with a mess. Regardless, I have learned to associated the phrase "best practices" with some imminent cargo culting.
  - acemarke 10y ago
    Uh... on the contrary, there's a bunch of fairly in-depth tutorials out there. I have a number of them listed at [0] and at [1]. Also, I think a couple of the more commercial courses do that sort of thing as well. Wes Bos's Redux course builds a "Reduxstagram" app or something, Tyler McGinnis's "React.js Program" course builds up a couple specific apps, etc. [0] https://github.com/markerikson/react-redux-links/blob/master/react-tutorials.md#project-based-tutorials https://github.com/markerikson/react-redux-links/blob/master... [1] https://github.com/markerikson/react-redux-links/blob/master/redux-tutorials.md#project-based-tutorials https://github.com/markerikson/react-redux-links/blob/master...
jswny 10y ago
I feel like React is shifting in the same direction as the JavaScript ecosystem at large, which is unnecessarily complex, disorganized, and fast-moving.
- danabramov 10y ago
  Can you help me understand where React is shifting into a complex direction? To me, it looks like we are no longer recommending a complex pattern that we specifically supported in code (mixins), and instead recommend a simpler pattern that “just works” in JavaScript (higher order functions/components). If anything, we are shifting to a simpler direction, and it worked better for us. We are sharing the lessons we learned in the hope that you might also find them helpful. Sorry if they’re not!
  - gedy 10y ago
    I think part of it is that not everyone is expert or familiar with functional programming (trained on OOP, etc) and it can feel overwhelming to many. "This is simpler - just another function" is somewhat subjective.
    - danabramov 10y ago
      I believe this is exactly why we explain this pattern in the blog post in detail instead of just saying “this is simpler—just another function!” We are trying to both deliver a library that helps people ship quality apps, share our learnings about what worked, and what didn’t, and educate the community about the patterns that we found useful in our experience.
      - gedy 10y ago
        I agree, mainly addressing the general vibe that React is complex - many folks have a gut knowledge of imperative that they lean on to make snap judgements about complexity, even when you explain it fairly clearly.
Touche 10y ago
That's because people are using it for real things now, not just as a jquery plugin replacement, and it turns out that ignoring hard things doesn't make them go away.
- shados 10y ago
  Yup. That's the point. The average frontend app really sucks. Error handling is poor, routing is bad, offline support is non-existent, it's buggy as hell, slow, etc. Now, not all apps need all of those things to be good, but they usually need some combination of those things. When you start making things "good", they're hard. Peanut Gallery Joe who learnt Rail and JavaScript over the summer jumping in this is not equipped to make a good app, and gets overwhelmed. Compared to writing "robust" applications in other ecosystems, the React world is really not that bad.
spicyj 10y ago
If simple things were possible before with React, then they still are, and that's not changing. You don't need Flux and Redux a lot of the time; in my experience they're overused and React component state is underused. I agree the community mentality of adding lots of complexity on top is a problem. We're working on improving this, but if you have ideas I'd be interested to hear them too.
- nathancahill 10y ago
  > "in my experience they're overused and React component state is underused" Thank you, I've felt the same way. A lot of projects take "ALL STATE MUST BE IN THE STORE" to an extreme.
  - sotojuan 10y ago
    Which is funny because you'll never hear that from Dan or any other authors.
    - nathancahill 10y ago
      ikr
  - eweise 10y ago
    IMO its no more trouble to put state in a redux store than in the component directly and doing so makes my components more consistent. I'm not a react guru though so maybe I'm missing something.
    - nathancahill 10y ago
      Eh, sometimes state isn't relevant outside of a component, so while you could put it in a store, it's possibly better to put it in the component. Single responsibility.
- brlewis 10y ago
  I bet React programmers who write a Mithril component or two would come back to React with more readiness to use component state. I don't have a plan for how you could use this idea to improve the community, though. As for the mentality of adding complexity -- are you sure that's a community problem? It seems a problem with programming in general. Advocates of adding complexity tend to be louder than advocates of using what's already there.
adamnemecek 10y ago
Check out cycle.js. I haven't learned it quite yet but the promises seem really interesting. It's a fully reactive framework unlike react which is reactive only in view.
- danabramov 10y ago
  Cycle is indeed interesting! React is not “fully reactive” by design, and does not plan to move further into the reactive direction. We think that React is well-positioned in the app to understand how to efficiently schedule work instead, which is something that would be harder for us to do with a reactive “push” approach. I think as time goes, it will be interesting to see how both Cycle and React evolve into different directions, and what different tradeoffs they might present and benefit from.
  - jessaustin 10y ago
    If you haven't looked at it in some time, Cycle.js has just really improved in the last month, an effort the devs are calling "diversity". Under the hood, that means RxJS is no longer a hard dependency, as a bunch of different reactive modules are now usable, including Staltz's new "xstream". Not having looked at Cycle in a few months, I'm not certain what all the particular changes have been, but I'm finding everything just seems simpler and more obvious. Admittedly, I am an RxJS novice, and some of the constructions I saw with that before just confused me.
    - adamnemecek 10y ago
      There has also been some perf work done recently it seems http://www.stefankrause.net/wp/?p=301 http://www.stefankrause.net/wp/?p=301 I have to look a little closer at the tests to be able to interpret the data but taking it on face value it seems like they are doing good work.
rimunroe 10y ago
Just a small point, but React has always had higher order components as long as I've been using it because they're just a subset of higher order functions. It's more of a feature of JavaScript than it is of React. Also, I've been encountering higher order components since I started on React two years ago I think. The definition of what constitutes a higher order component is very broad. I think that any render() method which returns a component would qualify.
softawre 10y ago
If you're building a simple app, keep it simple (but, do you even need React then?). If you're building Facebook, bring on the strong typing and design patterns that facilitate building large javascript applications.
smadge 10y ago
I think React is moving towards a simpler abstraction. There is nothing simpler than a function with the type Model -> View.
- bjz_ 10y ago
  Yup - trying out Elm makes you realize how much complexity is in the React + Redux stack that is not really needed...
bschwindHN 10y ago
Take a look at Reagent (ClojureScript library) for a breath of fresh air and simplicity.
macspoofing 10y ago
>I believe as time passes, we are moving away from the simplicity that made React win. Because every framework will handle small simple use-cases beautifully. When you include a codebase with thousands of lines of code, co-developed by many people, you can see where the pain points are.

danabramov 10y ago

You can use React without Flux/Redux if that works well for you. The “mentality” is just people solving their own problems in a way that makes sense to them, and sharing those solutions. As noted in the blog post, higher order components are not a React feature. And it is not related to Flux or Redux. It is just a thing you can do with components, like you can do it with functions. We think HOCs are a useful pattern so we explain it, but you don’t need to use it if you don’t get value from it. (We got a lot of value from using it.) That said if you have different solutions to the same problems that don’t suffer from the drawbacks of mixins, we’d love to hear them. This post is not there to force you to use HOCs. It’s for the people who had the same problems we experienced, tried to use mixins to fix them, and couldn‘t scale those solutions.

zuck9 10y ago
What I think OP refers to, is how there are so many different choices to do anything in the React ecosystem. It's cool that people share their work. But so many choices just cause decision fatigue. It's hard to have any kind of real-world usage from just React. You have to learn and use some kind of Flux, routing library, AJAX patterns for that Flux library, another library for <inputs> and <forms>, etc. If you want server-side rendering, server-side data persistence or user auth, which you will in real-world cases, you have even more things to connect. Also there aren't any free resources on the internet (that I could find) that teaches me how to put together a basic Twitter or Instagram clone using React + React ecosystem libs. No full-stack tutorials. Compared to Rails, React{ecosystem} is pretty hard to learn. Unless you're an experienced senior dev and understand all the different technologies deeply, you can't make any informed choice about what libraries to use. You just go and pick the most popular ones and later doubt your decision and think that you could be having an easier time if you had picked some other popular library more suited to your project. I guess most beginners just give up on React after trying a bunch of tutorials. I'm no Rails developer, but I guess even if you are a Rails developer with years of experience, you will find it frustrating to get started on React + ecosystem.
- danabramov 10y ago
  I agree that “getting started” experience is far from optimal. We take this feedback to the heart and want to improve this in the future. But how is this relevant to the post about mixins?
  - zuck9 10y ago
    I see it went OT, sorry about that.
- tptacek 10y ago
  You really don't need to learn some Flux to solve problems with React. React works fine without Flux, or really any formal data layer; you can comfortably use it simply as a really nice view library. I agree that people give up on React after tutorials that make them think about routing and Flux. It's a shame, because the core concept of React is incredibly simple, and anyone can pick it up in a couple hours. Flux is a useful, experience-based contribution and I'm happy to have it as an option. But it's heavily cargo-culted.
  - quantumhobbit 10y ago
    This, much more of this, please. I've been part of a small react project that was doing just fine without flux. Then the tech lead, a enterprise Java guy, decided we needed to use Flux because it was the "best practice". Problem was none of us understood Flux or how the project would benefit from it. It was pure cargo culting. Needless to say the whole thing became a huge mess as we spent all our time moving data to the store and back into the components. What is sad is that if the project had been allowed to evolve naturally, we might have ended up with a poor man's version of a Flux architecture, possibly even using Flux as a guide. Instead we had to force the project into a Flux pattern we didn't understand and wound up with a mess. Regardless, I have learned to associated the phrase "best practices" with some imminent cargo culting.
- acemarke 10y ago
  Uh... on the contrary, there's a bunch of fairly in-depth tutorials out there. I have a number of them listed at [0] and at [1]. Also, I think a couple of the more commercial courses do that sort of thing as well. Wes Bos's Redux course builds a "Reduxstagram" app or something, Tyler McGinnis's "React.js Program" course builds up a couple specific apps, etc. [0] https://github.com/markerikson/react-redux-links/blob/master/react-tutorials.md#project-based-tutorials https://github.com/markerikson/react-redux-links/blob/master... [1] https://github.com/markerikson/react-redux-links/blob/master/redux-tutorials.md#project-based-tutorials https://github.com/markerikson/react-redux-links/blob/master...

jswny 10y ago

I feel like React is shifting in the same direction as the JavaScript ecosystem at large, which is unnecessarily complex, disorganized, and fast-moving.

danabramov 10y ago
Can you help me understand where React is shifting into a complex direction? To me, it looks like we are no longer recommending a complex pattern that we specifically supported in code (mixins), and instead recommend a simpler pattern that “just works” in JavaScript (higher order functions/components). If anything, we are shifting to a simpler direction, and it worked better for us. We are sharing the lessons we learned in the hope that you might also find them helpful. Sorry if they’re not!
- gedy 10y ago
  I think part of it is that not everyone is expert or familiar with functional programming (trained on OOP, etc) and it can feel overwhelming to many. "This is simpler - just another function" is somewhat subjective.
  - danabramov 10y ago
    I believe this is exactly why we explain this pattern in the blog post in detail instead of just saying “this is simpler—just another function!” We are trying to both deliver a library that helps people ship quality apps, share our learnings about what worked, and what didn’t, and educate the community about the patterns that we found useful in our experience.
    - gedy 10y ago
      I agree, mainly addressing the general vibe that React is complex - many folks have a gut knowledge of imperative that they lean on to make snap judgements about complexity, even when you explain it fairly clearly.

Touche 10y ago

That's because people are using it for real things now, not just as a jquery plugin replacement, and it turns out that ignoring hard things doesn't make them go away.

shados 10y ago
Yup. That's the point. The average frontend app really sucks. Error handling is poor, routing is bad, offline support is non-existent, it's buggy as hell, slow, etc. Now, not all apps need all of those things to be good, but they usually need some combination of those things. When you start making things "good", they're hard. Peanut Gallery Joe who learnt Rail and JavaScript over the summer jumping in this is not equipped to make a good app, and gets overwhelmed. Compared to writing "robust" applications in other ecosystems, the React world is really not that bad.

spicyj 10y ago

If simple things were possible before with React, then they still are, and that's not changing. You don't need Flux and Redux a lot of the time; in my experience they're overused and React component state is underused. I agree the community mentality of adding lots of complexity on top is a problem. We're working on improving this, but if you have ideas I'd be interested to hear them too.

nathancahill 10y ago
> "in my experience they're overused and React component state is underused" Thank you, I've felt the same way. A lot of projects take "ALL STATE MUST BE IN THE STORE" to an extreme.
- sotojuan 10y ago
  Which is funny because you'll never hear that from Dan or any other authors.
  - nathancahill 10y ago
    ikr
- eweise 10y ago
  IMO its no more trouble to put state in a redux store than in the component directly and doing so makes my components more consistent. I'm not a react guru though so maybe I'm missing something.
  - nathancahill 10y ago
    Eh, sometimes state isn't relevant outside of a component, so while you could put it in a store, it's possibly better to put it in the component. Single responsibility.
brlewis 10y ago
I bet React programmers who write a Mithril component or two would come back to React with more readiness to use component state. I don't have a plan for how you could use this idea to improve the community, though. As for the mentality of adding complexity -- are you sure that's a community problem? It seems a problem with programming in general. Advocates of adding complexity tend to be louder than advocates of using what's already there.

adamnemecek 10y ago

Check out cycle.js. I haven't learned it quite yet but the promises seem really interesting. It's a fully reactive framework unlike react which is reactive only in view.

danabramov 10y ago
Cycle is indeed interesting! React is not “fully reactive” by design, and does not plan to move further into the reactive direction. We think that React is well-positioned in the app to understand how to efficiently schedule work instead, which is something that would be harder for us to do with a reactive “push” approach. I think as time goes, it will be interesting to see how both Cycle and React evolve into different directions, and what different tradeoffs they might present and benefit from.
- jessaustin 10y ago
  If you haven't looked at it in some time, Cycle.js has just really improved in the last month, an effort the devs are calling "diversity". Under the hood, that means RxJS is no longer a hard dependency, as a bunch of different reactive modules are now usable, including Staltz's new "xstream". Not having looked at Cycle in a few months, I'm not certain what all the particular changes have been, but I'm finding everything just seems simpler and more obvious. Admittedly, I am an RxJS novice, and some of the constructions I saw with that before just confused me.
  - adamnemecek 10y ago
    There has also been some perf work done recently it seems http://www.stefankrause.net/wp/?p=301 http://www.stefankrause.net/wp/?p=301 I have to look a little closer at the tests to be able to interpret the data but taking it on face value it seems like they are doing good work.

rimunroe 10y ago

Just a small point, but React has always had higher order components as long as I've been using it because they're just a subset of higher order functions. It's more of a feature of JavaScript than it is of React. Also, I've been encountering higher order components since I started on React two years ago I think. The definition of what constitutes a higher order component is very broad. I think that any render() method which returns a component would qualify.

softawre 10y ago

If you're building a simple app, keep it simple (but, do you even need React then?). If you're building Facebook, bring on the strong typing and design patterns that facilitate building large javascript applications.

smadge 10y ago

I think React is moving towards a simpler abstraction. There is nothing simpler than a function with the type Model -> View.

bjz_ 10y ago
Yup - trying out Elm makes you realize how much complexity is in the React + Redux stack that is not really needed...

bschwindHN 10y ago

Take a look at Reagent (ClojureScript library) for a breath of fresh air and simplicity.

macspoofing 10y ago

>I believe as time passes, we are moving away from the simplicity that made React win. Because every framework will handle small simple use-cases beautifully. When you include a codebase with thousands of lines of code, co-developed by many people, you can see where the pain points are.