Whoever wrote that doesn't get web application development.
Your precious "framework" comes undone the moment you deploy the app, IME. Framework couldn't tell you jack about your application usage patterns, because hits, as they come in, land on various web servers; some lean mean ones for static data, some chunky and familiar ones for the little backend logic, and some way way up front, multiplexing the incoming traffic. All the juice goes to databases, them too, in various layers, logs, and various levels of caching, etc.
It might start as an RC airplane that you have total control over, but it eventually becomes more like being a traffic operator in a Real World airport control room.
It all depends on whether you're talking about page-based or no-refresh web apps. For the former, you're right: the framework is less relevant, since the system is just basically responding to page requests. However, for a no-refresh app, the opposite is true, especially if the app is highly complex. The framework must manage the transfer of all code and content, which is where pre-fetching and factoring become particularly important.
Your precious "framework" comes undone the moment you deploy the app, IME. Framework couldn't tell you jack about your application usage patterns, because hits, as they come in, land on various web servers; some lean mean ones for static data, some chunky and familiar ones for the little backend logic, and some way way up front, multiplexing the incoming traffic. All the juice goes to databases, them too, in various layers, logs, and various levels of caching, etc.
It might start as an RC airplane that you have total control over, but it eventually becomes more like being a traffic operator in a Real World airport control room.