4 ms·

The massive amount of great tooling and debugging for React is a strength not a weakness. If people are overwhelmed by React I feel it is likely because: 1. t

The massive amount of great tooling and debugging for React is a strength not a weakness. If people are overwhelmed by React I feel it is likely because: 1. they haven't yet grokked the implications of how re-rendering every single time changes how they have to store the state of their app. (von neumman) 2. related to that, the choice of how to store that state and dispatch to a backend is not baked into React 3. it is harder to build an app up slowly because you have to have a rough idea of what the structure of your app state looks like ahead of time. So, you're forced to actually know more about your UI, UX, and design before you implement it. It takes longer to implement but once it is done, it's done and easy to improve upon - it's not fragile. For hacking something together it might not be the way to go. But for a well thought out implementation of an app which interacts a lot with it's backend, I think it's the only way to go now. I also feel like people will be missing the React wave at their peril. We're on the verge of being able to cleanly abstract out an applications delivery mechanism whether its native, mobile, or web. That is because of things like React and ReactNative and it's immutable render-every-time approach.

capkutay 11y ago
I think people try to get started with react and they jump to the boilerplates that are 'production ready'. Those boilerplates include routers, frameworks to bind routers to state, frameworks for server-side rendering, some new ES7 syntactic sugar, a bleeding edge module bundler like Webpack...the list goes on. They may or may not be a great combination of frameworks, but each has their own learning overhead. So people confuse learning react or learning redux with learning how to use every single framework shipped in the common react boilerplates. It can take weeks of studying or learning enough about those frameworks to understand how they all work. React itself is moving along at a healthy pace. Popular frameworks around react change about every week which causes this fatigue that OP speaks of. The most important thing IMO is learning the core concepts behind react, flux, redux, react-router, and worry about product client/server rendering and module bundling later.
ilostmykeys 11y ago
I was going say the same thing, a little differently. Only other comment is around having to know your entire app start up front. If you break up your app into micro apps each of which implement a given feature of your site then it's much easier to handle that way.
wpietri 11y ago
> So, you're forced to actually know more about your UI, UX, and design before you implement it. I hope that's not accurate, because if it is, it's an enormous step backward. Good software is always about novelty. (The non-novel parts should become libraries, frameworks, services, etc.) Building novel things requires a lot of exploratory work. And exploratory work goes best when your cost of change is low, which means keeping your batch size as small as possible. Anything that forces you to know more means larger batch sizes and higher risks of failure. Most of the improvements in software methods over the last 20 years are related to smaller batch sizes and easier exploration of a problem domain. I'd hate to think React is pushing against that trend.
- mbrock 11y ago
  It's not. You can change stuff and build stuff incrementally just fine.

capkutay 11y ago

I think people try to get started with react and they jump to the boilerplates that are 'production ready'. Those boilerplates include routers, frameworks to bind routers to state, frameworks for server-side rendering, some new ES7 syntactic sugar, a bleeding edge module bundler like Webpack...the list goes on. They may or may not be a great combination of frameworks, but each has their own learning overhead. So people confuse learning react or learning redux with learning how to use every single framework shipped in the common react boilerplates. It can take weeks of studying or learning enough about those frameworks to understand how they all work. React itself is moving along at a healthy pace. Popular frameworks around react change about every week which causes this fatigue that OP speaks of. The most important thing IMO is learning the core concepts behind react, flux, redux, react-router, and worry about product client/server rendering and module bundling later.

ilostmykeys 11y ago

I was going say the same thing, a little differently. Only other comment is around having to know your entire app start up front. If you break up your app into micro apps each of which implement a given feature of your site then it's much easier to handle that way.

wpietri 11y ago

> So, you're forced to actually know more about your UI, UX, and design before you implement it. I hope that's not accurate, because if it is, it's an enormous step backward. Good software is always about novelty. (The non-novel parts should become libraries, frameworks, services, etc.) Building novel things requires a lot of exploratory work. And exploratory work goes best when your cost of change is low, which means keeping your batch size as small as possible. Anything that forces you to know more means larger batch sizes and higher risks of failure. Most of the improvements in software methods over the last 20 years are related to smaller batch sizes and easier exploration of a problem domain. I'd hate to think React is pushing against that trend.

mbrock 11y ago
It's not. You can change stuff and build stuff incrementally just fine.