It's because of the large number of impedance mismatches in the naive web stack. All of these frameworks are efforts to get around the fact that these technologies don't mesh up very well. You get React because Javascript isn't a good paradigm fit for interacting with the DOM model, partially because the DOM model was written for Java (not Javascript) and it shows all through the API, and partially because imperative updates in response to events isn't a great paradigm for UI. You get Typescript because web projects now routinely scale beyond what you really want to program in a dynamic scripting language. You get three.js because OpenGL was just jammed into the browser without much thought about how to integrate it into the web. You get promises and that whole crazy kettle of fish because you have no persistent execution environment in JS, you just run little islands of code sometimes and then the browser puts your entire runtime away and goes on doing browser things, which is an impedence mismatch with the style of language that JS is (note that in _all_ languages you'd consider similar to JS (Python, Perl, etc), the default model is that the language runtime is _always_ in control). You get crazy frameworks for CSS because CSS integrates poorly with JS, not helped by the number of people who considered this a feature. And you get a positive _explosion_ of these technologies because there's multiple answers to all of these problems (and more!) and they all interact with each other. You get all of these things because there _isn't a good answer_, so we keep thrashing around trying to find the good answer that doesn't exist, the one that smooths over all the impedance mismatches and makes web development a simple and coherent environment. Little bits of progress are made here and there and get a lot of attention, but since there's so many fronts to make progress on, it's hard to make progress that everyone agrees is monotonically better than anything before it. There is an interesting contrast with the desktop widget world. In this world, there are many good answers, but they all come with caveats, like what platforms they support, and what languages they bind against, and how easy they are to use. It's kind of a dual of the JS situation; in the JS world it's as cross platform as anything ever created and you can in fact mix and match to some extent between the solutions, the client is fixed, but it's a terrible mismash of random semi-standardized techs that you're trying to unify, but at least everything is, in the end, Javascript. In the desktop widget world, you have standardization and you can have coherent APIs and you can have a lot of widgets to choose from, but you have all these run time concerns where even the most cross-platform widgets aren't cross-platform enough for everyone and if you're not using the same language as the implementation language of the widgets, the bindings can be complicated and spotty. But you don't get the JS profusion of ways of doing things; there aren't 25 libraries with distinct ways of managing putting up images, there's just the Image widget.
https://reddit.com/r/programming/comments/8n00k2/why_is_frontend_development_so_unstable/dzs5138?context=3