For my own startups that I work on as a solo developer over the last few years, everything is currently in vanilla JS and CSS. I have been programming for deca

For my own startups that I work on as a solo developer over the last few years, everything is currently in vanilla JS and CSS. I have been programming for decades and used many different component systems on the web and desktop, such as React, Angular, Vue, WPF, wxWidgets, some more that I dont remember. For projects involving several designers and developers, some kind of component model might be necessary to be able to easily reuse and integrate code. Also designers or backend programmers may not factor in the complexity of certain design or architectural decisions such as state changes that are supposed to cascade to other items on the page. Since I am controlling all of those decisions, I can for example simplify so that either only state relevant to one small element is updated, or an entire tab panel is re-rendered. And then can ensure there is time to optimize the panel rendering. With that amount of control, usually the extra cognitive load for the component system etc. seems to not be worthwhile. But for example many years ago I had a complex web front end given to me on a shoestring budget, with subpanels etc. supposedly automatically reflecting every other type of state change that occurred. He insisted that I use a plain version of something called Knockout.js which did not have facilities for tracking and updating based on so many dependent state changes. Then he kept adding more and more panels and components, with more cascading or interacting state changes that caused bugs when I tried to manually keep them up to date. So that was kind of a "setup" in terms of the architecture required of me by the contract and the design decisions and there were lots of bugs and was especially rough to do in a small time frame. At the time things like React and related state management did not exist or were not known to the client, who thought he knew better about architectural decisions anyway and so that wasn't something I had room to negotiate or in the budget to research. You either need a good concept for handling all of these potentially interacting state changes such as what happens with component and state flow systems, or you do what I do. The whole design avoids it where possible, and when necessary I set it up so I can just re-render that whole section, making design decisions to avoid something causing annoying latency or other problems. It's a lot easier for me to do this stuff as a solo developer where I have end to end control. Also one thing that has changed in the last several years I think is that Firefox and Chrome have gotten significantly faster at re-rendering HTML through various optimizations. So actually some teams may want to reevaluate complex state or component frameworks to see if they might be overkill.