I think the prime directive of all UI should be, "Ack UI inputs immediately, no matter what else is going on." Throw up a spinner, make something throb, change a status to "loading", anything. Don't just go off and attempt to do it and hope for timely response.

Why can't the browser do this? I mean, it's a universal function / feature, right? And ultimately, it's the browsers that's waiting, not to application per se. (Yeah, I okay. But you know what I mean).

I can't think of any good reason why the browsers can't help out with this UI / UX. Am I crazy?

Technically, in a SPA, the browser isn't waiting. Clicking the link just triggers a function call.

There has to be a wait somewhere. That is, the browser can't update anything until it knows what to do. So between the click and that new assignment is wait, yes?

Just to be clear, that is a poorly designed SPA, none of that should be happening and is easy to avoid.

That is absolutely true, but I've seen it enough times to be annoyed. Also, the grand parent post was about classic HTML apps which were poorly designed with issues that should be easily avoidable.

A normal web page doesn't have to be well-designed in these ways, though. And SPAs often are not designed in this way. The author addresses this pretty well in the first paragraph.

When you click a link or button on a normal website, the browser doesn't give indication on the ongoing state of your http request either. Only a javascript-enhanced experience can do that.

Clicking on a save button and seeing the page hang is the normal way browsers handle http requests. But a javascript-enhanced experience can tell users about the local perception of the http request (ongoing, timeout, retry, error), or it can inform the user that it's safe to navigate away while their requests retry.

Firefox for Android shows a thin orange progress bar beneath the navigation bar, and Chrome for Android shows a similar blue one. Firefox and Chrome for the desktop show the loading spinner in the tab.

Most browsers at least show a spinner somewhere, do they not?

In chrome the bottom left status "connecting url..." Like a grey rectangle

Most indicate this by making the refresh button into an X or similar, and usually with one or two small visual indicators. Safari on iOS shows a little bar, etc.

Forgot about that one.

I love browser push state so cool, but yeah if it doesn't work right you get stuck not being able to go back.

Edit: also agree to it disappear when accidentally hit back or leave page... I don't think you need to ask permission to use cookies so should opt for it... Or some other way to store.

The problem with using cookies for navigation is then you restrict the user to a single window/tab. If the user opens a separate window and navigates somewhere else in the application, the cookie state will reflect the new window and disregard the state from the previous one.

Sorry for the cookies I meant the storing of whatever you were writing into a form and accidentally hitting back or navigating away from the page. Like in mobile leaving the browser and returning to it, sometimes for me it starts it over haha no, just empty your soul into an essay response, all gone. Probably soared the recipient.

Interesting about the separate window, thought cookies could be set to never expire.

Oh, I see. For saving the form state, localStorage would work better than cookies for saving and restoring because then the information is only kept on the client. That still doesn't solve the multiple window problem, but that's likely less of an issue for a filling out a form than for navigation.

Cookies can certainly be set to never expire, but you don't know which window the cookie was intended for because the cookies are shared.

I wasn't aware. Are you talking like HTML5? Haven't used local storage before. Thanks for the info.

Yes, see Window.localStorage [1] and this short guide [2].

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/loca...

[2]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage...

thanks for the references, I'd like to start using it at some point. Would be cool to check the client's device capabilities/run a specific event based on conditions met.

I finally used memcache(d) so that's cool.

Back and forward buttons should scroll when there is a link to an anchor on the same page.

There was some website linked to by HN a while ago that as you scrolled down the page, history events would be recorded. So if you wanted to go back to the previous page, you'd have to press back about 8 times if you scrolled to the end of the article.

Slate.com does this.