It was Ruby on Rails, it was forms-based, and it was hell. To personal taste these days, I much prefer writing a heavyweight client and a thin server that emits

It was Ruby on Rails, it was forms-based, and it was hell. To personal taste these days, I much prefer writing a heavyweight client and a thin server that emits raw data and does very little HTML rendering or HTML pre-processing to the alternatives I tried before. But even if the server is doing a lot of heavy lifting, the end user experience can benefit both in performance and bandwidth from minimizing page reloads. There's some pretty spiffy client and server template technologies now that let you get pretty close to write once, render on either the client or the server depending on which is cheaper. And there are other applications for which manipulating history is a better fit. Otherwise, how would you mail history into a web experience that doesn't match very well to page navigation at all, like a WebVR walk where you want to be able to return to a location via URL, or a music player where you want the history to go back and forth between the songs you played?