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