[csande17]

I once worked at a place that thought like the grandparent comment. "We're gonna have a huge app with lots of different UI variations. Let's use React. Then it will be super maintainable and scalable!" And then it turned out that if your plan to write maintainable code starts and ends at "use React", you will end up writing code that is not maintainable, and your framework will not save you, and in fact you will be fighting framework-induced bugs and performance issues on top of the problems caused by your total inability to design computer programs. The pace of software development at your company will grind to a halt, you will accept this as the only possible state of affairs (we're following all the best practices by using React!), and your company will limp along for a while and then go out of business.

[bayesian_horse]

It's more about the programmers than the underlying technology. But with react (and redux etc) very smart and experienced people have already put some thought into things like maintainability, and your chances of achieving success from the shoulders of these giants are higher than by starting from scratch.

Unless you don't need to reach that high.

[csande17]

I don't think that's really true. React doesn't give you less problems, it just gives you different problems that aren't as immediately visible because you haven't learned to look for them yet. For example, if you're used to thinking that every page of a web app can be tested individually, you won't notice bugs in single-page apps that only happen when using specific links to arrive on pages in a specific order.

[bayesian_horse]

React only gives you tools to reduce your problems.

In the case of single page apps, preventing you from shooting yourself in the foot is outside its scope.

What you are describing sounds more like a general problem in state management, and you'll have that with any framework. A common way to avoid such things in React applications is with Redux.

Unfortunately, even those advanced tools need to be learned and applied.

[csande17]

As used in practice, React has you replace one set of tools with another set of tools. React likes to "own" parts of the DOM tree and crashes or otherwise misbehaves if anything else touches them -- and the way people generally adopt React is by making it "own" larger and larger portions of the page until it "owns" everything on the page. (Or by writing the app so that React "owns" the whole DOM tree from the start.)

And when you use it that way, the way that everyone who has ever used React uses React, it can indeed cause problems of its own! Half the time, the only reason people build single-page apps is because they've destroyed their page-load performance by using heavy JavaScript frameworks! If you make a big nested component hierarchy, and then it turns out you need a component to affect something nine levels below it in the component hierarchy, and you have to modify all the intervening components or rig up a Context provider or something, that is a problem that has been caused by React's design! If you put a piece of state in Redux, and then it turns out you need to access it in a place that does not have easy access to the Redux store object, that is a problem that has been caused by Redux's design!

You can say "ah they just haven't learned to use the tools properly", but then we're back to noticing that anyone capable of using React to write good code doesn't need to use React to write good code.

[bayesian_horse]

I've used react for years now and never had those problems. I've used components managed by other libraries and React didn't crash.

There are tons of ways to access state in a redux store elegantly from anywhere in a javascript application. Yes, if you think that is the difficult part, you are clearly doing it wrong...

And please don't write single page applications when you don't know why you need one... There are plenty of reasons why SPAs can provide a better user experience. If you do it right.