Why use a mash-up of smaller libraries when there's a monolithic framework out there with everything that we need? Libraries are our tools, and if they fulfill a need in our architecture, by all means use them. Some developers shy away from low-level tools because of the dependency-chaos that ensues. In practice, this happens anyway, even if we're leveraging an all-encompassing framework.
At the end of the day, the distinction between frameworks and libraries doesn't really matter to us. Creating a third-party dependency nightmare doesn't scale well. Neither does sticking with one tool exclusively and maintaining a lot of code ourselves. It's about finding the right fit between depending heavily on other projects and reinventing the wheel ourselves.
The tools we use to help implement our architecture do so by exposing patterns common throughout JavaScript applications. And they do so consistently. As our application scales in size due to a growing featureset, we can apply the same framework components over and over. Frameworks also promote consistency in the patterns we implement ourselves. If we look at the internals of any framework, we will see that it has its own generic components; these are extended to provide us with usable components.
Open source frameworks have the most developers looking at the code, and the most projects using the framework in production. They get lots of feedback from the community of users, and these include performance enhancements. Third-party tools are the right place to focus on performance, because they're likely the most utilized code in a given application. Leaving all performance outcomes up to browser vendors and JavaScript libraries isn't smart. Leveraging the performance behind components we use all the time is smart.
Successful JavaScript frameworks have strong communities surrounding them. This is more powerful than having robust documentation because we can ask questions as they arise. Odds are, someone else is trying to do something similar in their project, using the same framework as us. Open source projects are like a knowledge engine; even if the exact answer we need isn't out there, we can often find enough through the wisdom of the community to figure it out ourselves.
Saying one framework scales better than another isn't justified. Writing a TODO application as a benchmark for how well the framework scales is hardly useful. We write TODO applications to get a feel for the framework, and how it compares to others. If we're unsure about which framework fits our style, a TODO application is a good start.
Our goal is to implement something that scales well in response to influencers. These are unique and unknown upfront. The best we can do is make predictions about what scaling influencers we'll likely be hit with in the future. Based on these likely influencers, and the nature of the application we're building, some frameworks are better candidates than others. Frameworks help us scale, but they don't scale for us.