4 ms·

This perspective is reasonable, until you start applying it to highly interactive / dynamic GUIs. Real-time chat is the most obvious case where the html purist

by cj 7y ago

This perspective is reasonable, until you start applying it to highly interactive / dynamic GUIs. Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience. Another example: any page that displays a row/table of data that the user wants to sort (frontend libraries make sorting instantaneous, compared to full page refreshes with html-only). There are lots of people using complicated frontend frameworks in cases where pure html from the server would obviously be better. But it’s difficult to argue all libraries are bad and slow for every application.

brightball 7y ago
Table sorting in the front end only works if all of the data exists in the front end though.
- yurishimo 7y ago
  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.
6510 7y ago
> 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: 0123456789 <a href="tel:+18123456789">[call me]</a> whatsapp: 0123456789 <a href="https://wa.me/0123456789?text=I'm%20interested">[message me]</a> facebook: html.purist <a href="https://www.facebook.com/messages/t/html.purist/">[message me]</a> </pre> https://jsfiddle.net/r3u5yvk8/ https://jsfiddle.net/r3u5yvk8/ I'm now on their contact list.
the8472 7y ago
> 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.
- mnsc 7y ago
  > ... slow-stream a bunch of html elements Slow-stream?
  - the8472 7y ago
    Keep the socket open and write a div to it each time a new line is posted. Browsers can and do render partial documents.
Razengan 7y ago
> 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.
adrianN 7y ago
Most of the web bloat is not used to create highly interactive GUIs.

by cj 7y ago

brightball 7y ago

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

yurishimo 7y ago
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.

6510 7y ago

> 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: 0123456789 <a href="tel:+18123456789">[call me]</a> whatsapp: 0123456789 <a href="https://wa.me/0123456789?text=I'm%20interested">[message me]</a> facebook: html.purist <a href="https://www.facebook.com/messages/t/html.purist/">[message me]</a> </pre> https://jsfiddle.net/r3u5yvk8/ https://jsfiddle.net/r3u5yvk8/ I'm now on their contact list.

the8472 7y ago

> 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.

mnsc 7y ago
> ... slow-stream a bunch of html elements Slow-stream?
- the8472 7y ago
  Keep the socket open and write a div to it each time a new line is posted. Browsers can and do render partial documents.

Razengan 7y ago

> 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.

adrianN 7y ago

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