[SquareWheel]

I would say that it is structured complexity. Modifying a reactive variable is more complex than editing the DOM directly, true, but it minimizes the number of sources of truth. The developer no longer has to worry about keeping the on-page elements and JS variables in sync; that happens automatically.

Managing just your application's state, while letting some template logic know where to embed that info into the app, scales far better.

If you measure complexity strictly by the amount of code running, then a React or Vue app will likely be more complex. If you consider just the actual application logic, it's usually far simpler. This is especially true if you utilize components, which lend themselves well to rapid development with fewer side effects.

[alerighi]

The complexity is the infrastructure you need to build an application with a JS framework, versus just including the libraries that you needed in script tags and done. Do we really need a build system for JS? Probably to make something as complex as Google Docs that is an application that runs in the browser yes, but not for 99% of web pages that you see each days.

[SquareWheel]

Complexity has to live somewhere. We use abstraction to better manage it, and keep our codebases scalable and manageable. Yes it's not as efficient as it would be if every single function call were carefully planned for and orchestrated, but that's not feasible for modern applications that do many things.

It's the same way on the desktop side. Writing everything in assembly instructions would technically be the least "complex", but it'd also be utterly insane and error-prone to do it that way. Even mid-level abstractions like C++ are hard to get right. It's why many modern apps are built in higher-level abstractions, because they're easier, more reliable, and fast enough.

It's really no different for a website. You can put all of your state in one place, bridge different libraries, and manually sync DOM changes, but you're essentially just frontloading the complexity. Abstraction is an important concept in structuring your codebase into clean and maintainable code, even if it is technically more complex.

I won't argue that React doesn't get overused for otherwise-simple pages, but many pages are not simple. The web today is full of interactions, tabs, dropdowns, search bars, notifications, modals, and tooltips. It all needs to respond to your device's form factor and input method. Every network request requires error handling. It needs to be routed, cached, and served smoothly and correctly.

It's a lot. It's a lot to manage in one layer. I am content to let some of that complexity be managed by Vue, or React, or whichever framework we're discussing. If it lets me worry just about my application's logic, and it simplifies the templating, error handling, routing, and so on, that makes things easier and less error-prone for me.

Honestly, I've written plenty of web apps in vanilla JS. I've experimented enough with closures, IIFEs, classes, and other techniques for managing state. It really doesn't matter how careful you are, any sufficiently-complex project will always turn into spaghetti. Frameworks help us stave that off, at least for a little while. Their component-based architecture makes relationships more explicit, and much easier to isolate. I particularly like Vue's Single-File Component (SFC) concept which organizes components into logic, template, and styling.

Not all frameworks require a build system though, and there's plenty of options available for tackling smaller problems. Alpine is great for reactive data. htmx helps manage apps with many server calls. You don't necessarily need the full React or Vue package, if your app isn't so complex.

But if it is, I think you'll be glad to have them.