The bandwagoning is disproportionately on the side of those leaning towards big frameworks. Look, I've been on the inside of large companies making framework choices and rarely is the decision rational. Often it's based on what's popular and based on the assumption that popular things are popular for good reasons. Biased metrics get thrown around to justify preconceived notions, and off to the races we go. Years later, everyone sees the old stack as "old and outdated" and a strong desire to throw it all away and rewrite it with the new hotness takes hold. Then the entire irrational process repeats itself.

I'm not saying the big trendy thick client JS frameworks are the wrong tool for every job. But in my experience they do seem to be the wrong tool for an alarming number of jobs they are presently being used for. And I'm not just spitting rhetoric here. I'm more than happy to put my money where my mouth is. If you want to know specifically when I think a big thick client JS framework might be the right tool for the job and when it probably isn't, this article does a good job of outlining that: https://www.sitepoint.com/javascript-dependency-backlash-myt...

As for the tradeoff associated with developer productivity vs. performance, there is some validity to that. However, I think people overestimate the developer productivity gains the frameworks offer. You only get productivity gains if your whole team is already fully trained on the framework. And in addition to the performance tradeoffs, you also risk your codebase having a shorter lifespan because the framework may make breaking changes to its API some day (e.g. Angular 1 -> Angular 2), whereas a vanilla JS implementation that relies on smaller, single purpose JS libraries will age considerably better.

Large companies almost by definition need to hire a lot of developers. Seems to me that it would be an absolutely rational and sensible choice to use popular frameworks keeping those constraints in mind.

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.

Probably not; people would just learn Haskell.

And that would be so amazingly beautiful.

Google will hire people who can write good vanilla JS code, not someone who's good at the latest fad js framework. In fact, if you're good at writing vanilla JS, you would probably pick up these frameworks overnight.

Pickup a framework overnight results in shoehorning your current knowledge into the framework and late night rants about how the framework sucks.

It was a figure of speech! :)

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.

I'd say it depends on the framework a lot.

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 :)

I plead guilty

People focus on frameworks and popularity, but as someone who builds a lot of complex front ends, what really matters to me is architecture--architectural simplicity and architectural scalability.

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.

I think your points have some weight to them. Specifically I 100% agree that JS frameworks are at times misused, and in lots of situations are completely unnecessary. However, my point is the valid use cases for these JS frameworks warrant the open source investment that many community members are pouring into them.

That I completely agree with. And to be clear, while I disagree with some of what Tom Dale says sometimes, he's a very talented guy. LinkedIn is lucky to get him and I think it's entirely a good thing to see another prominent open source project get some corporate support.

I think we see many here pump up their abilities that they could homebrew an excellent implementation of [insert special feature] better than [insert framework/library]. Truth is, I don't trust most software engineers to do that without a vetting of some sorts, and open source software provides that. I consider myself pretty good, having done some serious open source work in the frontend world, but if I had to homebrew a framework like React and all of the pieces to make it work (or Angular, even with my intricate knowledge of it), I would not be able to match everything with performance, flexibility, and good API signatures. Most developers are not experienced with thinking about all 3 factors in tandem, and it shows with the code that is written on a typical basis.