The performance angle of SPAs has been proven wrong many times.

If SPAs had better perf than MPAs, I can assure you Amazon (the store) would be an SPA. But SPAs are notoriously slow, specially if built with React. Amazon tested React and it was too slow for them so they kept using Java for SSR + jQuery. I think they removed jQuery recently, but keep using the same approach of SSR + sprinkled JS.

As for dev complexity, I'd be very surprised if that was the case. Are taking into account writing the backend code or only the frontend? What about client-side data caching? What about spinners? What about mismatched version of the app for users that don't close their tabs all day long? Etc. Etc.

Yes I know all problems with SPAs have solutions. But that's the point the article is making: you have to solve it.

> If SPAs had better perf than MPAs, I can assure you Amazon (the store) would be an SPA.

What technology does the Instragram in-app shopping experience use?

Because whatever that is, it is 10x better than the Amazon app.

Amazon's websites, mobile and desktop, and app, are all horrible compared to the competition. Slow, hard to navigate, long load times, I wouldn't use Amazon as a point of reference for anything.

I don't use Instagram so I can't compare. I don't use the Amazon mobile app either.

What I do know is that the Amazon mobile website, while ugly and outdated in many respects, runs ways better in my crap Android phone than probably 99% of SPAs.

I don't know, but it's probable the "Instragram in-app shopping experience" has better UX. Although that's not really what we're discussing here, are we?

Amazon app is actually a glorified webview.

Are you _amazon_? Nearly none of the companies have the scale of amazon, nor the needs of amazon. "It's proven many many times" is all in the eyes of the beholder, i'd say. Sure it might be slow if you are optimizing for 1ms latency, but that's not what 99% of the people do.

Google also doesn't use react. The ads stack is written in C++, for fb it's hack + c++, neither of which are the right tools for majority of use cases.

I am really struggling to understand your pov. I can throw together a whole app in asp.net MVC in days that takes weeks with react. Adding that extra layer of complexity of an API and duping the models adds a ton of work on top of everything.

But on top of that with C# and razor you've got strongly typed intellisense that just works which means rapidly building the templates which you just cannot achieve when making a spa.

Amazon is highly optimized for conversions on a single navigation. This is not representative of all web use cases. For ecommerce, I would agree with you. This is generally true of any site where a significant amount of the visits are load one page and then bounce to another site. SPA advantages don't help in your primary use case.

In other use cases, which there are plenty, different sets of rules dominate. There are plenty of places where SPAs provide a much better user experience than MPA.

I find SPAs simpler to do than MPAs if it fits the use case.

This is my experience as well. The SPA works best when the application is doing a bunch of stuff on the client side. If it has to make a bunch of trips back to the server, it's going to be a headache to debug.

To me, it's not a matter of performance one way or the other (server lag vs. overweight client). I'll deal with those issues when I come to them. What I care about is the ago-old problem of cohesion and coupling. I want the user-facing stuff in one place so that I can write and maintain it, closely cohering to itself and loosely coupled to the other parts of the system.

Even if this were true, you are sacrificing your end user experience for having a better development experience.

I'm a frontend dev and I work with React all day long. I still think MPAs and stuff like HotWire/Livewire/etc should be enough for like 90% of what we do. Being the last 10% offline first or Google Maps/ Figma level of interactivity apps.