[QuadrupleA]

Everything a programmer does is "hand rolled" whether it's JS or JSX.

You'll still have to tackle those complex requirements and come up with a good design that organizes things and makes them manageable, whether you're using React and JS or just JS.

To say that a good design is just impossible with JS or that no other engineers could possibly understand the resulting code seems absurd.

Javascript is a Turing-complete language. It gives you a lot of design options. Your poor engineers will have to learn it to use React anyway so why would vanilla js necessarily be worse than js plus a giant framework?

[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.

[systemvoltage]

Building a doctor's appointment website with a form and a calendar widget? Use vanilla JS or jQuery.

Buidling the next Google Docs or Notion app? Use React/Angular, etc.

99% of the people that use React use it to build the former and then debate endlessly about their little teets and toots of JSX, Redux, Router library, etc. FFS, it is overkill and unnecessary. Simplify, go home on time and enjoy your the time with your family.

[Zababa]

> Buidling the next Google Docs or Notion app? Use React/Angular, etc.

Wouldn't the performance of Google Docs suffer too much by using React? If I remember correctly they're switching to canvas-based rendering. Same thing with VSCode, they don't use a framework. I'm not sure about Notion, as I don't use it much, but I've never been impressed by the performance too. I think your best bet for React/Angular is around "medium complexity", so a typical web app that isn't that complex.

[wk_end]

This is a content-free take. Swap in any methodology or design technique ("functions", "structured programming", "Unix pipes", "any higher-level programming language than raw assembly"...) and it would be just as meaningful. These are abstractions that help produce a good design to organize things and make them manageable.

[bayesian_horse]

React is quite a minimal framework (or not even a framework), actually. It's just that it has a huge following and takes some mind-bending to actually benefit from it.

[habibur]

Last time I checked, React itself was 150kb minified. OK for a 2mb page. Not ok for 20kb pages.

[bayesian_horse]

I'm not in the business of building 20kb pages.

Working with any significant backend API, loading any images, or even your own javascript functionality takes you over that limit easily.

And then there is caching and CDNs...

[joesb]

Why not? At that size, it takes less than your client can blink to load it.

[acdha]

If your client is an otherwise idle system with the latest browser, a fast wired connection, and the developers carefully monitor time to render.

In most cases, at least one of those is not true and the developers are using something like CRA so your site has a number of users who see tens of seconds of nothing while their Android phone downloads and runs a 1MB JS bundle. Bonus points if the marketing department has tossed in a tag manager which delays that even longer.

[brabel]

What you consider minimal, some consider a 100-lb gorilla.

[dragonwriter]

> What you consider minimal, some consider a 100-lb gorilla

A 100-lb gorilla is...quite minimal, actually.

[lioeters]

> Male gorillas of the Western lowland gorilla (Gorilla gorilla gorilla) subspecies have average weight up to 140 kg (310 pounds) while females have up to 90 kg (200 pounds).

https://gorillafacts.org/how-much-does-a-gorilla-weigh/

[bayesian_horse]

That's about the weight of a chimp.

[brabel]

I think in metric system :D