Your Flow example tells me that you sincerely believe that ease to learn is a non-factor. I think it is a mistake to believe that someone can be such a good developer to the point that learning curves are ignorable, especially because of collective factors (companies and teams).

Static types were not brought to the point of being a success in JS because this was something deemed fancy or the like, but because of companies worried about the how traversable their projects are. In that context, TypeScript was the one that brought it because it is easier to learn, which again is not an insignificant detail, as it means saved cost for the companies. In the end they’re pragmatic and rational choices.

I strongly believe in one design motto that says products have to adapt to people, not the opposite. Devs have failed to adapt to the chaotic native Front-end stack, so now they are coming up with their own non-native solutions, more shaped in the way they would like the native stack to be, even if they are imperfect solutions (and they sure are).

I wrote an article not long ago about the cost of JS frameworks, so I know what you’re saying when you advocate for writing less code. However, if it was that simple, no one would use frameworks, preprocessors and bundlers and all that stuff. It is true that many people don’t know these costs but many do and pay them happily. See, in real-life, big project situations, working in teams, it is very hard to tame this native FE stack. There is a good chance that you end up writing a new framework for each of your bigger “vanilla” projects, so in the end I don’t think it is that simple.