Sure, chrome lets you simulate 2G connections and all that, but last time I checked it didn't simulate the slowdown of compiling 2MB of javascript on an old phone. Could be a revealing constraint to put in the developer tools.
Ignoring the costs of maintaining that complexity, it was at best a 2x increase in capability. Accounting for the costs, it was a net loss.
Finally: "same but faster" is a valid capability that people want. I want a compiler that is simply the same, but faster. Once I hit a certain threshhold of speed improvement, then I'll entertain an actual capability improvement (more compiler features like incorporating static analysis or whatever).
Which is a better user experience:
1) Download an enormous framework that also runs slower and slower each year on constant hardware, because developers add more features?
2) Download a tiny page which hands heavy lifting off to the server (if you really do that the pages are only about 8kb plus images), and which requests an equally tiny page when the user does something requiring a server response?
It won’t be the same for every app, of course, but most of the content I see online doesn’t need or even benefit from JavaScript. I’ve literally turned it off by default and generally get a better UX… yes with a few exceptions, but only a few.
The onset of SPA's what contributes to this. It's making server-side content generation leaner, although sometimes at the expense of the user experience with worse page responsiveness during downloads. What's debatable is if the user benefits are worth the increase of upfront UX cost.