> I don't understand what problem they're trying to solve Building highly stateful / interactive web apps. If your web app is sufficiently complex enough then

> I don't understand what problem they're trying to solve Building highly stateful / interactive web apps. If your web app is sufficiently complex enough then your vanilla js solution will just become an undocumented framework in disguise. When you build a homegrown system that manages components and their lifecycles (reacting to state changes) then you've written a framework that no one else has experience or knowledge of. > What makes the trade-off of all that extra complexity and abstraction worth it? Interactive UI's that react to state changes are hard to manually manage as complexity increases. Your UI and state are connected by an undocumented large state machine. These frameworks essentially allow you to define how your state, in any shape it may take, should be reflected in the UI (DOM). > Aren't HTML/CSS/JS perfectly fine and time-tested tools for web development on their own? Sure, but all of the frameworks are written in JS and you write plain JS to use them. You might use something like JSX or TypeScript for convenience, but these are turned into plain JS. They're also not required, they've just become standard because of how convenient they are.