> Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience.

The retro approach is to have two frames. One to submit, one to slow-stream a bunch of html elements which we can thankfully now lay out via flexboxes which are highly efficient when it comes to relayout, i.e. only the appended elements would incur some runtime costs, the already rendered ones don't get recomputed.

I have seen chan-style imageboards that update posts as people type (every dozen milliseconds) with 10k posts in a thread. The layout recomputation overhead is really low.

> ... slow-stream a bunch of html elements

Slow-stream?

Keep the socket open and write a div to it each time a new line is posted. Browsers can and do render partial documents.

> Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience.

???

  <pre>If you have any questions:

  Phone:    <b>0123456789</b>  <a href="tel:+18123456789">[call me]</a>
  whatsapp: <b>0123456789</b>  <a href="https://wa.me/0123456789?text=I'm%20interested">[message me]</a>
  facebook: <b>html.purist</b> <a href="https://www.facebook.com/messages/t/html.purist/">[message me]</a>
  </pre>

https://jsfiddle.net/r3u5yvk8/

I'm now on their contact list.

> Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience.

I can’t recall the last time any website offered me an acceptable embedded chat experience (not counting dedicated clients like Discord) so that’s all for the better.

Table sorting in the front end only works if all of the data exists in the front end though.

Yeah if you actually want to sort datasets of any meaningful size, you’ll be making requests to return database results anyway since a database is going to be infinitely faster and more comprehensive than any client side solution.

Most of the web bloat is not used to create highly interactive GUIs.