4 ms·

There's unfortunately a thin line between cargo-culting and attempting to follow the mainstream. As developers we can't all be building tools. We choose tools

There's unfortunately a thin line between cargo-culting and attempting to follow the mainstream. As developers we can't all be building tools. We choose tools that others build for us, so that we can get our job done. Soemtimes I'm interested in going "one layer down" and build tools, but it's almost always a distraction; we want off-the-shelf products like React and Redux. We need to pick stable tools that promise some sort of longevity. We also need to pick tools where best practices and idioms have been established. To do this we have to trust someone else's opinion and try to gauge which solutions have the best prospects. This means not just evaluating software based on its own technological merits, but also listening to what "the community"/"the industry" seems to be rallying around; you don't want to be stuck using a library that nobody is maintaining, just as you don't want to be stuck using something that's just badly designed. When we started using React, there was no state management framework available, and everything was handled somewhat ad-hoc. Then Facebook described Flux, and we realized they were onto something, so we started using their patterns, with some simplifications where theirs seemed overly complicated. Then Redux came along and seemed like a better way to do things. At each point there was uncertainty about what best practices and "idiomatic" solutions would turn out to be, because the technology was immature. I don't think anyone was cargo-culting. It was just that a lot of people were busy trying to create things, and when there isn't clear guidance, and the alternative is going back to Backbone or jQuery or something, then you just forge ahead, trying to do fit the pieces together.

allover 8y ago
But if you looked at the official React docs the answer was always 'setState' and embracing components, that was the whole promise of React to begin with. Not once did the React team/docs ever say you needed Flux to build a React app. All of those answers you got were cargo-culted from the community. Can you really look at where the community is, the perception that still exists that React+Redux is necessary, projects like redux-form (that now admit Redux was a poor fit for forms) and honestly say no cargo-culting happened? Sympathy for 'attempting to follow the mainstream' though, I understand that. Personally I stuck with Backbone for years longer than most, avoiding the Angular/Ember wars, and the early days of React+Flux til the React ecosystem had matured a little, before jumping over to React at which point it was clearer that Flux/Redux were being misused.
- atombender 8y ago
  Can we blame all the bloggers who take upon themselves to explain what the best practices is? Absolutely. There are also projects (like React Forms and React Router) that clearly led down a path of confusion. But it's hard to blame the developers who read those blogs and try to figure out what they should be doing. I never got the impression, even from the start, that setState() was a good solution, by the way. But it's not like the React authors were completely sure of where the right design was, either. Flux, for example, as it was originally described, appears completely overdesigned at this point. The good design is to be found in Relay and GraphQL.
  - allover 8y ago
    > Can we blame all the bloggers who take upon themselves to explain what the best practices is? It's not really about blaming bloggers. It's really on software team leads and senior engineers to not just follow blog posts blindly. They should be pushing back on bad advice like redux-all-the-things, because to a senior software engineer the tradeoffs of something like Redux should be fairly obvious. > The good design is to be found in Relay and GraphQL. Nah again, good example to question what you read/hear. GraphQL is great from a front-end point of view but complex to implement in the backend, so it really depends on your use-case whether that backend complexity is worthwhile.
- jakelazaroff 8y ago
  The official docs originally described React as "the V in MVC" [1], so the assumption about needing another layer to handle state and business logic didn't come from nowhere. The claim isn't that there's no cargo cult around the React ecosystem — but not everyone writing React code is approaching it with experience, which means they try to pick up best practices from other people. That's not "cargo culting"; it's a reasonable thing to do when you have to solve a problem you don't know how to solve! Ultimately, people aren't being "tricked" into using these tools. They proliferate because they solve real problems people have, and a lot of people would rather work with a popular and well-documented solution (with known advantages and drawbacks) than trying to forge their own path and seeing how it goes. [1] https://github.com/facebook/react/pull/7012 https://github.com/facebook/react/pull/7012
bananadonkey 8y ago
As one of a small group of maintainers of the build tools of our most complex app, I can concur with this. Yesterday I spent 4 hours fixing a single build/parse issue between dev and prod. I also spent just 1 hour completing multiple RFCs in another app built with create-react-app using redux/connect as a purely syntactic-sugar state propagation layer. I love the complexity and feeling of fulfillment for triumphing in the former scenario, but it is definitely much more of a distraction than anything else.

allover 8y ago

But if you looked at the official React docs the answer was always 'setState' and embracing components, that was the whole promise of React to begin with. Not once did the React team/docs ever say you needed Flux to build a React app. All of those answers you got were cargo-culted from the community. Can you really look at where the community is, the perception that still exists that React+Redux is necessary, projects like redux-form (that now admit Redux was a poor fit for forms) and honestly say no cargo-culting happened? Sympathy for 'attempting to follow the mainstream' though, I understand that. Personally I stuck with Backbone for years longer than most, avoiding the Angular/Ember wars, and the early days of React+Flux til the React ecosystem had matured a little, before jumping over to React at which point it was clearer that Flux/Redux were being misused.

atombender 8y ago
Can we blame all the bloggers who take upon themselves to explain what the best practices is? Absolutely. There are also projects (like React Forms and React Router) that clearly led down a path of confusion. But it's hard to blame the developers who read those blogs and try to figure out what they should be doing. I never got the impression, even from the start, that setState() was a good solution, by the way. But it's not like the React authors were completely sure of where the right design was, either. Flux, for example, as it was originally described, appears completely overdesigned at this point. The good design is to be found in Relay and GraphQL.
- allover 8y ago
  > Can we blame all the bloggers who take upon themselves to explain what the best practices is? It's not really about blaming bloggers. It's really on software team leads and senior engineers to not just follow blog posts blindly. They should be pushing back on bad advice like redux-all-the-things, because to a senior software engineer the tradeoffs of something like Redux should be fairly obvious. > The good design is to be found in Relay and GraphQL. Nah again, good example to question what you read/hear. GraphQL is great from a front-end point of view but complex to implement in the backend, so it really depends on your use-case whether that backend complexity is worthwhile.
jakelazaroff 8y ago
The official docs originally described React as "the V in MVC" [1], so the assumption about needing another layer to handle state and business logic didn't come from nowhere. The claim isn't that there's no cargo cult around the React ecosystem — but not everyone writing React code is approaching it with experience, which means they try to pick up best practices from other people. That's not "cargo culting"; it's a reasonable thing to do when you have to solve a problem you don't know how to solve! Ultimately, people aren't being "tricked" into using these tools. They proliferate because they solve real problems people have, and a lot of people would rather work with a popular and well-documented solution (with known advantages and drawbacks) than trying to forge their own path and seeing how it goes. [1] https://github.com/facebook/react/pull/7012 https://github.com/facebook/react/pull/7012

bananadonkey 8y ago

As one of a small group of maintainers of the build tools of our most complex app, I can concur with this. Yesterday I spent 4 hours fixing a single build/parse issue between dev and prod. I also spent just 1 hour completing multiple RFCs in another app built with create-react-app using redux/connect as a purely syntactic-sugar state propagation layer. I love the complexity and feeling of fulfillment for triumphing in the former scenario, but it is definitely much more of a distraction than anything else.