>Checkout the popularity of React, it's proliferation into the marketplace, and it's use on production environments.

How is this a valid methodology to picking a framework for your web product for your new business / project? If the idea is to reduce training/recruiting/onboarding costs and sacrifice domain-specificity to attempt to utterly commoditize your developers, I can sort of understand that reasoning at larger scales. I just don't understand why a new business/project would choose this weird circumstantial path for new development initiatives.

I also don't understand why I can't seem to get any React enthusiasts to explain to me the business value prop of using React for a _new_ business started today. I'm only guessing that there are elements of cost reduction in training/onboarding/continuing education, but nobody will even go as far as admitting that much of it, let alone give a decent technical reason for using React.

Does all of this really just boil down to "It's javascript, and I know javascript. And not only that, but it's React, and I've used React before to work on this website that I thought was pretty cool, so I might as well just use React again because so many other people use it."?

I don't even think that is that bad of a business reason, I just don't get why people are so cagey about it and try to invent weird technical reasons for why your enterprise document store needs to have a reactive, fully-fledged javascript application running in the client browser just to show a document and expose basic CRUD actions.