[wtbob]

I don't get what he doesn't understand: when the user goes back, the browser is supposed to show the document he saw when he left, as it was when he left it (so long as that view hasn't expired out of the browser's cache completely). This is intuitively what a user expects, right?

> Note: if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider it portant that users not be presented with error messages or warning messages when they use navigation controls (such as BACK) to view previously fetched resources. Even though sometimes such resources ought not to cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of preventing caching (e.g. “once-only” URLs) in order not to suffer the effects of improperly functioning history mechanisms.

I don't get what he fails to understand: if the back function obeyed expiration headers, then going back could potentially reload the page, potentially causing a re-GET or even a re-POST.

[Noseshine]

As I read and see this, it is not about normal HTML pages. The issue probably is more important for SPAs.

For example, you post something that increases your total message counter, and the URL is changed (single page app: the page is not reloaded, only modified by Javascript), for example showing the new message (think "forum" as an example). If the user clicks "Back" they may get the page-state with the previous counter value, confusing the user. Ideally you would want the counter to be updated.

One can construct similar scenarios for regular web apps/pages where a new page is loaded, but I think the caching behavior is more out of line for SPAs. It comes down to the web serving as app platform and not just as "HTML pages for reading". You don't expect - in an application (compare behavior of a regular non-web application) - that when you go back the GUI may not reflect current state, in an app it always does, even if you go back to a previous form.

I think there will always be misunderstandings because of people who always think of the original web, a bunch of linked pages, and others who see it as (also) an application platform. The requirements needed for either often are fundamentally or sometimes subtly different. Is it ideal that we have a platform that is supposed to do such extremely different things all in one? Maybe not, but I think we actually managed surprisingly well to reconcile two very different concepts and requirements in the "web platform" thus far.

I think it would be valuable for discussion when authors a) state if they are talking about one or the other kind of web platform use b) consider that the other one that they are not talking about also exists and has equal value.

[zeveb]

I would expect that if one must write a SPA then one will hijack the Back button, no? So one could implement whatever logic makes sense within the SPA.

But really, one should avoid SPAs like the plague. Write web sites consisting of web pages. Only if the site or pages need more should one add JavaScript, and only if it's insufficient to purpose should one write an SPA (as an example, I have a hard time envisioning Mattermost, IRC or Slack working as web pages).

[Noseshine]

    > one should avoid SPAs like the plague

Why? I don't see any basis for such a statement, but I'm more than willing to learn.

[zeveb]

SPAs are basically an exploit, taking advantage of a dynamic document model and a language intended to layer a little bit of behaviour atop that model, and using it instead to deliver entire applications. It's a little like noticing that sed is Turing complete, and thus writing a text editor in sed.

The Web is supposed to be about resources and links between them; that's what REST is about (in a very real sense, REST is the driving principle behind the Web). In pretty much every case, those resources can have an attractive, human-readable HTML representation (but they may of course also have easily-parsed JSON or high-performance Thrift, flatpack or protobuf representations). One should be able to use a browser as one's user agent to use a web site built on REST principles to perform any sequence of operations that web site makes available.

Now, one might provide quite a lot of JavaScript over top of that REST interface, in order to provide a more user-friendly experience (one could imagine HN using JavaScript to allow inline commenting, while still preserving the ability to POST). In general, one should provide the plain resource-oriented interface first, and only add JavaScript later. For one thing, this helps one think clearly about the API; for another, it's a lot easier to take a clean REST API and use it from JavaScript than it is to take a purpose-built SPA and try to turn it into a proper REST system.

Now, there do exist some systems which really, really don't make a lot of sense as primarily REST apps — in my post, I used the example of chat apps. Certainly, they should have REST APIs, but honestly I can't see most people wanting to use them that way (although … it may be convenient in order to avoid distraction). For that sort of app, it's conceivable that one might properly begin with the SPA. Another example might be the 2048 game, or similar things. As much as I'd prefer a native gtk+ game, it is true that most people haven't yet upgraded to Linux; it's also true that as terrible as the JavaScript privacy & security stories are, they are much better than the native app privacy & security stories.

All those are good reasons to write an SPA.

But if one is building a brochure site, or a blog, or a magazine, or a trip planner, or an e-commerce site, or pretty much anything that most of use — then starting with an SPA is wrong. All of those should be modeled as resources and state first, with UI added later.

An example would be that I discovered it's impossible to checkout using Target's website without JavaScript; I was just trying to send a gift certificate to a friend, and now Target isn't seeing that money, due to a poor design decision. There's absolutely no reason that Target should require me to enable JavaScript in order to POST them a credit card number and a quantity.

[Noseshine]

You are not giving reasons against SPAs which is what you said earlier, you are giving reasons for using the right tool for the job. Which nobody disagreed with from the beginning, not me anyway.

[zeveb]

> You are not giving reasons against SPAs

I think being inefficient ('writing a text editor in sed') and impeding doing things the right way ('it's a lot easier to take a clean REST API and use it from JavaScript than it is to take a purpose-built SPA and try to turn it into a proper REST system') are reasons not to write SPAs, no?

And the presence of reasons to write proper HTML/HTTP apps implies why one shouldn't write improper SPAs, no?

[paulryanrogers]

Sometimes payment goes through a third party like BrainTree. So if the merchant wants to minimize the PCI-DSS liability they may use JS to send the data directly to the processor.

[taneq]

> I don't get what he fails to understand: if the back function obeyed expiration headers, then going back could potentially reload the page, potentially causing a re-GET or even a re-POST.

There's already behaviour in place in most (all?) browsers to cover this case, at least for POST. When you go back to a page with had form data attached to the request, they'll ask you whether to re-submit the form.

This doesn't happen for GET, but then you probably shouldn't be using GET for data anyway.

[wtbob]

Honestly, they shouldn't re-prompt IMHO — they should only do that on a reload — rather, they should just display the page as it was, which is what I expect when I hit back.

[paavokoya]

I agree. This would greatly frustrate users on quick-feed news sites and social media who are hoping to find that article or post they were just reading to find it now gone because the sites algorithm marked it as 'read'.

[kalleboo]

I have this problem all the time on YouTube. I'll instinctively click through to subscriptions but when that is loading I'll notice a recommended video that looks interesting. But then hitting back it's gone because YouTube has reshuffled the recommendations

[rudedogg]

It would be interesting to see the analytics for this. I've seen the dialog many times, but can't think of a time I resubmitted the form.

[lmm]

I resubmit the form approximately always, FWIW.