Separate frontend from backend development and make it even two teams. This makes it much more robust and loosely coupled because both sides protect the interface from each other.

My experience is the opposite. The interface created in such a situation is the worst of both worlds.

This works. Now you only need double the engineers to create the same app as you would using a server side framework. Hardly a more powerful argument against SPAs than this.

I'm not sure I buy this. I recently worked on a project where we had one .net core developer, a dev ops guy, and me doing the client SPA. We were all able to focus on our core competencies and turn around the project incredibly quickly. I would argue that you can get away with the same team size split between front and back end and possibly end up with a more efficient allocation of resources.

Perhaps, but if both teams are half the size, specialised and deliver faster, it’s a win.

That may not always be the case, but if your SSR team and API team are the same size, your devs suck, bluntly. API based backends are much easier to build, test, manage and look after.

Two teams sharing an interface means one team will block the other most of the time if a new feature always requires changes in the interface and implementation on both sides. Doesn't matter if individual development speed increases, overall project speed will suffer greatly.

That's a hell of a generalisation, and it falls down pretty fast when you move beyond CRUD apps. You can easily end up with entire teams whose role is just to babysit Elasticsearch.

No, it doesn’t.

Regardless of the backend stack, if you maintain both the front end and the backend, it is categorically less effort to only maintain the backend (ie. just run an API).

Half as much effort? 3/4? I don’t know, maybe your UI is a man autogenerated swagger frontend and it’s (43/50) as much effort.

It depends... but it is always less effort not maintaining an external user facing UI.

I think the counterpoint to this would be Google Search. The core product is incredibly simple from a frontend perspective, but the backend is world-class engineering.

I think making information usable is hard. This means that the burden of the development falls on whatever is making the information useful. If you simply can query an API and get stuff back that's valuable because the data is already processed, UI is pretty easy (aka Google). If your backend is returning raw data that needs to be organized and displayed, and users need to be guided through complex processes that are just simple CRUD operations server side, you have a much harder UX/UI challenge. Most things fall somewhere in the middle.

Well, what does your API actually do? If you're e.g. Heroku, your front end does almost nothing in comparison to the rest of your product. Why would running the backend of a globally distributed infrastructure-as-a-service company be easier than maintaining the front end?

I'd argue more than double considering all the things a good SSR gives you reliably for free.