The only problem: We're downgrading functionality, while upscaling file sizes, bandwidths, processor load, the complexity of the tool chains involved, the costs

The only problem: We're downgrading functionality, while upscaling file sizes, bandwidths, processor load, the complexity of the tool chains involved, the costs of development, etc. Most of what we do was present for decades, and there's not so much change at all. E.g., there's not so much difference in requesting live data in a browser by the use of a hidden frame and reacting to its onload event (or using a mechanism, which became later known as padded JSON), like in the 1990s, and using a nifty AJAX library. (You're still requesting some data from a server to load it into the browser and eventually process it in an onload event handler in order to partially update the UI). The difference is really in the amount of processing and tooling involved in pulling this up. And then, there's the bitter irony of the history that started with the iPhone. Before, there had been smart phones, too, like the SE's ones, perfectly capable of displaying a subset of HTML4, and even a wide range of feature phones, being perfectly able to display a subset of XHTML. The selling point of the iPhone was its ability of displaying perfectly normal websites without any further modifications or restrictions applied. Now, file sizes are shooting up (because mobile?) and even your 4K screen is restricted most of the time to what may be done on a 5 inch touch display at the cost of high processing loads implied by an abundance of abstraction layers that are never put to a sensible use in the first place. So transition is nice and a good thing (like, if we had made use of multipart-http, as in HTTP1.1, but, yes, there was this MS bug regarding http chunks -- however, we may get now a second chance), but, nevertheless, we may question the direction of a particular transition from time to time.