Hacker News Reader

Comment by nn3 | Hacker News Reader

>You need experienced engineers to create performance no >matter what your domain is.

Actually the funny thing with HTML is that the simplest things are fast. If you just write a old school HTML web page without a bazillion frame works and not going too heavy on graphics things are usually fast.

And doing that is literally so much simpler and easier than learning all the super complicated frameworks of the day.

So it's a progression from initially fast for simple, to slower and slower as people learn the complicated (and slow) frameworks, and then eventually maybe fast again if you have an expert who can make all this mess fast again.

Most people never reach that expert stage of course, but sadly still leave the "easy and fast" stage.

View on HN

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.

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.

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

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.

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.

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

Server side rendering is not really that slow, and SPA is not really that fast if your bundle size is huge.

More important is that most users will not able to distinguish the difference. I have asked my friends how they feel to compare Facebook to a traditional MVC web site in term of speed difference, none of them can feel the difference.

However, the transition from page to page do affect the user experience. As a user, when I want to do a task that involve many UIs and I need to click multiple pages, I will think it is a bad experience, but I do accept to switch to another page for another task. Therefore, It makes sense to have a SPA for some rich UI feature so that user can remain in the same page

Reply on news.ycombinator.com