First time I hear XMLHttpRequest was a mistake.

No one is going to sit through a full-page reload on every form validation.

Even intermediate solutions that merged (hacked) client-server state failed too. APIs are just better.

The irony is you're posting on HN, which does exactly what you suggest no one will tolerate. How slow is this form submission for you? ;-)

Conversely, the upvote button (which I used for your point) doesn’t perform a full refresh. Both are good.

Turn off your JS and upvote something. It becomes substantially less pleasant.

Turn off JS and load an SPA :p

hey, we all love how fast HN loads, not gonna argue!

On the other hand, I don't think it's usable for other crowds. I spend most of my day inside vim, so I'm used to switching windows and going back all the time but I don't think that having to load a submit form in a new page, losing all context of the conversation tree is particularly usable.

Sites or "apps" relying heavily on full page loads are, in my experience, much faster than their "efficient" XMLHttpeRequest counterparts, in practice. As in, click, thing happens, thing is done happening, much faster. We even have examples of this with the same "app"—Gmail, for example: Basic HTML, "mobile", standard, and, though I think it's gone now, Inbox. At least four versions. Basic HTML is less janky than "mobile" on mobile, and much, much faster than standard or Inbox, despite "inefficient" full page loads.

> No one is going to sit through a full-page reload on every form validation.

Why not? Most of the pure HTML forms I use load at least an order of magnitude faster than the complex SPAs I use because there's so many fewer network requests. You can make SPAs which are as fast but I'd say fewer than a third companies, even very large ones like Google or Facebook, succeed at doing so and an even smaller percentage have thought hard enough about error handling. On a daily basic I use sites from Google, Twitter, Facebook, etc. where I have to do a reload anyway because their developers were unaware that network operations require timeouts, retries, and that you need to provide UI feedback for all of those to match what the browser provides by default.

EDIT: to be clear, I like that we can do a ton of very complicated things in a browser now — we've been working towards that as an industry for the last 3 decades and it's great that it's largely arrived — but I think it really hits the failure of companies to skimp on resources for anything which isn't critical to the default user experience. Duplicating built-in functionality should be seen as an expensive commitment, not the default unless you're willing to devote the extra resources needed.

I agree with this.

Yes, ideally, a SPA could be better (i.e why re-send the parts of the app that didn't need to change), but most of these apps are actually way slower -- either because the developers don't know/care beteer, or perhaps more probably, are not given the time to implement the perfect(-ish) solution.

A full html page reload isn't much slower than react/redux doing a json fetch, but it may appear so since most of the content doesn't flash, new content comes in with an effect etc. And I agree, this looks more slick.