A single-page app is almost always worse than a multi-page app

This seems really misinformed and written by somebody who has no idea how SPAs work. The SPAs approach results in much cleaner and simpler architecture in practice because you have clear separation between the client and the server. It also forces you to think about the API up front allowing you to create other clients, such as native mobile apps, later on.

The SPA approach also helps with statefulness, because it allows you to keep the UI state on the client where it belongs. The UI becomes much easier to reason about because you're not trying to keep state of the server and client in sync. Meanwhile, the server can just be a set of service calls the UI queries when it needs data, and doesn't need to store any state about it. This directly helps with horizontal scaling where you can spin up more servers and balance across them.

While SPAs can have a larger initial Js download, they can be a lot more responsive overall because you don't have page repaints, and you fetch data as you need it.

Testing actually becomes easier because your front-end is decoupled from the backend. You can test it in isolation, and the amount of statefulness is dependent on the complexity of the UI as opposed to whether its implemented SPA style or not. An equally complex UI implemented using traditional server-side rendering will likely be harder to test in practice.

Also not sure why authentication needs to be any different with SPAs. You can authenticate exactly the same way as if you did server-side rendering.

>Let's illustrate this with an example: we're building an e-commerce site that has a list of categories. We need to update the list from time to time. In an MPA, the list is updated on every page load. That's not the case in an SPA though.

Why wouldn't it be?

>In an MPA, we can simply pass models to views and render attributes we need. This isn't the case in an SPA. We need to define data formats and implement serialization.

Not really sure what that's about either. JSON exists, and I'm pretty sure nobody is inventing serialization formats in SPAs.

>Single-page apps are much more expensive to build than multi-page apps. In most cases, there is no business reason to choose this architecture.

Perhaps this is just a problem with the particular stack the author is using, and they're extrapolating this to be a general problem?

It should be completely uncontroversial that "if it costs much more, it better provide a benefit that's worth the extra cost". I agree completely with the statement, "it's same tradeoff as literally every other business decision: will the resulting benefits be greater than the costs they incur?"

I will add that I think "vastly better user experience" is very situation-dependent. Many applications put on the web (be they client-side rendered, server-side rendered, or a mix) are really boring simple things: fill in a simple form and get some basic information. A lot of users and businesses really don't value that much what an SPA can do. They don't think they are "vastly better" - sorry. In many cases an SPA doesn't necessarily give you the benefits worth the cost, especially since there are many costs. In other cases an SPA is obviously the right way to do a job, and it'd be a poor decision to try to do otherwise.

I wish people would focus on understanding "there are X ways to do this, and here are the pros and cons of each approach". Trade-offs, trade-offs, trade-offs. If we focused more on understanding the alternatives and their trade-offs, the field would be a saner place.

Thanks! Texas looks awesome.

I find the author forget that those problems arise with each new paradigm and each time tools evolves to resolves those problems.

This is where skill and experience come in.

Should huge wizards and complex forms be constantly sent back to the server and rendered as each bit is filled in? Of course not.

But if you have a basic CRUD app with a big dashboard, create route, edit route, view route, etc., it's a hell of a lot cleaner to break up each one of these main features into mini SPAs that cleanly refresh the state on the server when moving from one function to another.

Otherwise, you're constantly making duplicate calls to ensure you've got the data you want as you really can't be sure if some previous click from one of dozens of in-memory widgets has stale or incomplete data.

At least that's been my experience working on a few legacy apps written in AngularJS and, God forbid, JQuery. At that time, an Asp.Net or GWT app would have probably been easier to maintain as the duct tape increased over the years.

Maybe React and Vue allow for cleaner architectures, but older apps were a pain.