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