I would have to disagree on the last sentence -- there is nothing in any definition of a software framework I know about that suggests that a software framework

I would have to disagree on the last sentence -- there is nothing in any definition of a software framework I know about that suggests that a software framework cannot encompass more than one function. .NET indeed does have a much larger solution stack then most web frameworks, for better or worse (there are advantages and disadvantages to this approach). But that does not disqualify it from being a framework in my opinion. Web programming is more fragmented in nature, for better or worse. I think that was more my point with the first paragraph (and also a response that most .NET programmers don't need to care too much about any backbone frameworks .NET was built on). .NET provides you with a full front-to-back ecosystem. With web applications, you usually chose, at minimum, some form of Javascript framework, some back end framework, and some form of style framework. (Full stack frameworks for some reason have not taken off in the web ecosystem.) Even that description simplifies some of the fragmentation, due to the bewildering amount of choice. If you want to implement a Flux pattern in React for instance, there are over a dozen versions out there to chose from. I don't think this necessarily says anything about app complexity or speed of development at all, agreed. Complex apps are going to be the same. I do think that the current fragmented, churn-y nature of the Javascript ecosystem can be a barrier to entry for simple apps at the moment; for that reason, I'll welcome the day when the Javascript ecosystem reaches peak "Javascript fatigue", becomes a bit more stabilized.