[savanaly]

It's all about scaling of complexity and number of engineers working on the project. No doubt hand rolled js is better when you only have to do the one thing you mentioned and you're the only person who has to read or write the code.

What happens when it's one of hundreds of checkboxes on the site? When they all do slightly different things depending on user sku, product page, file type, file permissions, god knows what else. And when one experiment flag is on or how about this other one? Then i18n? Then what about the fact that after you write this line countless other engineers will see and modify it in the future, it's not just you writing and maintaining it? These are the problems that my company (and, I assume, Publicis Sapient with 20,000 employees according to Google) have to consider when choosing whether to hand roll JS or use a framework.

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

[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

[simonw]

Then you can switch to something like React. But most projects won't ever get close to the level of complexity you are describing.

Meanwhile I have seen SO MANY sites that use full React for a contact form with two fields on it.

[arcturus17]

You don't need to get close to that level of complexity for React to become useful.

> Meanwhile I have seen SO MANY sites that use full React for a contact form with two fields on it.

I agree that the contact form you describe would be dead-easy to do vanilla. Maybe throw in Parcel if you want to write ES6.

However, while I suspect some people may use React in this case because it's all they know, others may do it because they are literally faster in React - they have a workflow that can see them code and deploy such a website to Netlify or Heroku or whatever in 10 minutes.

[hajile]

Preact to render the view and a dozen lines to handle the submission and data in a closure are still likely an easier solution than vanilla JS.

[joesb]

Which is fine if your company and teams use React a lot.

Why introduce inconsistency in everyone's workflow just because this specific page is a simple contact form?

The fact that it is just a simple contact form is exactly why you should use the same tools and workflow that everyone in your team has already been using.

Write what other people knows so you don't have to be the one maintaining it.