> Sure. When you use API, you can design it with a domain-specific data format. When you use SSR, you stick to HTML page overhead. Now you hydration, your JS t

> Sure. When you use API, you can design it with a domain-specific data format. When you use SSR, you stick to HTML page overhead. Now you hydration, your JS to run, and a custom serialization/deserialization format (and a custom parser) to maintain. > This is not an argument against SPA, it’s an argument to invest in UX. When done right, SPA and native clients do deliver better UX than SSR/generic browser. The effort to achieve that is not huge, in fact this behavior can be built as a reusable component. We're well over a decade into SPAs and we're still seeing these problems/errors. I routinely see SPAs keeling over without any feedback built by large, richly resourced. The tool has something to do with it if so many different people and organizations are failing.