Dead Button Syndrome | Hacker News Reader

Dead Button Syndrome

em-tg.github.io

4 pointsem-tg3 comments

A human should never be able to win a race condition, yet even without network delays, we somehow manage to make user interfaces that require running tens of billions of instructions, handling hundreds of millions of characters worth of data, all to present some text to the user, and it falls apart because the user pressed a button in less than a second or sometimes even a few seconds.

An ncurses GUI running over a dial-up terminal in the 90's was more responsive than most web pages on a modern web browser.

Granted, half the problem is the web browser itself. I'm typing this on a Chromium-based web browser on a an older laptop, and even though Hacker News is about the leanest web page in existence, I'm typing often a word ahead of what's displaying, because enough RAM to store 8 billion characters, and a processor with two cores each running 2.3 billion operations per second, each able to execute multiple instructions per operation, can hardly handle a text box displayed through Chromium's bloat.

I wanted to bring up an issue I've run into increasingly often, and ended up writing a short history of the SSR/CSR pendulum swing (as I understand it, anyway).

Fun-fact: I mention in the article that html forms are interactive even while the rest of the page is downloading, but they're are also interactive when the form itself is downloading. So the following form:

  <form method="post">
    <button type="submit">Submit Form</button>
    <input type="hidden" name="foo" value="a">
    <input type="hidden" name="bar" value="b">
    <input type="hidden" name="baz" value="c">
  </form>

can send any of the following requests:

  foo=a&bar=b&baz=c

  foo=a&bar=b

  foo=a

or even no request body at all.

That's an interesting example that goes right to the heart of the problem.

That plain-HTML form could fail on you because a person submitted the form when it was partially complete.

In React you have the same problem of incomplete initialization and the honorable thing to do is "lock out" the button visually or hide it behind a spinner or otherwise not show it unless the system is properly initialized. If this is not done and the event handler runs, the event handler might test that a state variable is null and abort the request (handling the error how?) or maybe the button is dead because the null gets dereferenced and an exception is thrown but not handled in the event handler but it is fine when you click again later when the initialization is done.

Related to that is the search result page that claims to have "zero results" before the results load.

Back when I was working on RIAs 20 years ago I thought it was best to design the communications so that the application could initialize itself with one AJAX request: it might take a while for an application to boot up, but comm latency is minimized and illegal intermediate states are eliminated. Similarly clicking one button or taking one action that makes an AJAX call should send the all the data to update the application UI in one request. It's like the N+1 thing in SQL.

React gives people the tools to deal with the illegal states that occur while applications are updating and people usually use them well enough to avoid catastrophe but not enough to delight users.

Reply on news.ycombinator.com