Google would go bankrupt from a combination of the insane salaries they'd have to pay and the inability to ever fill jobs if its entire stack was based on Haskell.

My point was that unless you're a small startup with very specific need for the tech stack you're using, you probably shouldn't be hiring based on whether the candidate knows certain framework, because that can be learned quickly, as long as the developer has solid foundation.

Many frameworks deeply affect how the code is written and have very specific boilerplate, custom templating and such. And some frameworks simply offer means of doing some things in an easier, usually specific, way with the relevant language.

In my experience it is also highly relevant how your thoughts on architecture match up to the framework's. I'd say you can happen to have a solid affinity for the way a framework is thought out. But in general, I'd agree, overnight is generally not sufficient for anything proper :)

Before trying React/Redux, I was against js frameworks too. They all seemed to add a whole extra layer of unnecessary mutable state to keep in sync, and required lots of cruft and duplication. Just give me coffeescript, underscore, and jquery, thank you very much. I composed nice little modular components that latched on to server-generated html, kept state to a minimum, and used a global event bus to deal with interdependence. It had some warts, but it got the job done and scaled up reasonably well. It certainly beat procedural jquery spaghetti and I thought it beat the current crop of frameworks too--what it lacked in polish, community, and standardization were made up for by modularity and simplicity.

Of course, then I discovered React, and more recently, Redux. I immediately realized that it was the culmination of what I'd been trying to do all along. It was basically the same idea, but battle-tested, standardized, and infinitely more elegant. So why wouldn't I use it? Sure, there was a learning curve while I got used to other people's way of thinking about and expressing these concepts. Rather than designing the system myself and knowing it like the back of my hand, I had to learn a whole new vocabulary and toolchain. But it was so, so worth it in the end. I'm still building apps with an architecture I believe in, and I get all the benefits of a well-supported framework to boot.

So, to finally get back to the central point: never once was popularity an important factor in my decisions, and I suspect this is also the case for many many others who adopt one framework or another. Not everything that's popular is only popular due to a bandwagon effect--sometimes the shiny new thing really is a big step forward.