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 pract

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?