Why I hate your Single Page App

Use a decent router. Single Page App ecosystems have been festered by mediocre routers that make doing stuff like this hard, where there's no need to be.

This is the design our team likes to follow, I haven't seen it documented anywhere (but I doubt it's new), so I'll write it here.

Essentially, we try to replicate traditional server side MVC thinking on the client side. Decent server side rendered apps that don't have the problems mentioned in the OP's post usually follow RESTful principles to some extent. This means that what you see on a page is a pure (ish) function of these things:

    * The parameters in the URL
    * The state of the database

And nothing else. Translated to the client side, it means that you want anything the user sees to be a function of:

    * The URL
    * The state of the model layer (or the flux stores, whatever)
    * Addendum: 100% of the model layer is an 
      eventually-consistent subset of the database

We use one exception to this rule: unimportant state is allowed to be right in the view (we use React, so that's component state). Stuff like "is the dropdown menu expanded" or "which of the items in a list are selected" is neither in the URL nor in the model layer (because we won't sync it back to the database). The rule of thumb is "if the user refreshes the page, is it a problem if this data is lost?". If the answer is "no", we can make it component state, as close to the action as possible (so not in the root component usually).

All of this combined gets us a lot of stuff for free. For example, all our modal dialogs, and even "is the menu shown" is addressable from the URL. This might feel like overengineering, but it gets us lots of stuff for free.

For example, users on mobile phones expect to be able to close a modal or a menu by hitting the hardware back button. We get this for free, because when the user does an action that causes a modal to show, we redirect to some URL like example.com/wherever/?someModal=1. (all using the history api). Router picks it up, modal is shown. Model layer is not touched, this is 100% view layer work. Then, when the user hits "back", the browser restores the URL to example.com/wherever, router picks up the change again and the view renders the same page but without the modal.

We get all the usual browser features for free simply by following basic REST ideas. Don't put URL stuff in your stores. Don't put non-backend-synced stuff in your stores (just like you wouldn't put important state in your sessions in server side rendered apps). Put everything that matters in the URL.

Any routing library that encourages you to sync URL stuff into your model layer is, IMO, wrong by design.

I half way agree here. Too many things are SPA's that don't need to be. An internal tool used by < 1000 people? Maybe let that stay server side rendered. A cutting edge app that promises a new clean way to bank/farm/hire/cryptowhatever, then please embrace SPA's and PWA's. The reason we have a glut of these SPA's is because we have devs, designers and product not recognizing context. Some things don't need to look or feel cutting edge. The real tragedy here is that I've seen companies burn thousands on SPA's when they could have had one front-end on their API team make it server side rendered.

Exactly.

- The author is describing hypertext, which is perfectly fine for textual static content, one of the key goals for which the World Wide Web was conceived.

- Server-side generation of HTML seems totally out of place for other use cases: HTML/JS are now the assembly languages of the web and they belong in the browser. Besides a more distributed architecture is just perfect: server and client focus on what they do best.

- Fixing web-apps with broken history buttons and unlinkable urls is important, but to be honest there are fewer and fewer SPAs that are mono-url these days. And it's perfectly fine to have a unlinkable "Delete this Invoice" app button. If it's not real content it should not be a link.

How hard it is to get things right? It's not hard at all. It's builtin with frameworks like Ember or Angular, and for React you got react-router which does things correctly by default. It's just bad programming. I don't even understand why people would make an SPA without a url-router. Doesn't that just make development harder/more anoying?

Why would links take longer to load in a SPA? CSS, Javascript and the like should already be downloaded, there should be much less networking involved.

Also. My SPA's come in at around 120-130kb minified (no gzip). That's about the same as "pure-html" sites which include jquery.

I do agree with your last point though. Pure content sites, or even "mostly"-content sites, is probably better off with backend generated html.

> If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it.

This really shouldn't be a problem for anything other than file inputs. If someone's form is losing submitted information on a validation failure when using an actual HTML submit, then I find it pretty unlikely that they're doing a good job of AJAX submission.