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

> This is not an argument against SPA, it’s an argument to invest in UX.

ZIRP-era thinking. Gotta get by with less of everything now, unless you're a growth/hyperscaler snowflake, in which case the advice doesn't apply to us common-or-garden engineering shops.

A lot of UX gains can be achieved in a lean way with minimal effort. It is unfortunate, that the state of the industry is such, that half of „senior“ engineers only mastered CRUD and 90% of engineering and product managers are just random people without essential knowledge or skills required for their jobs. ZIRP era thinking is to assume that money will and only money can solve the problem of building a decent product.

Time is the other variable!