[wruza]

every other API is basically unimportant and arbitrary

Well, frontend-to-backend api is also unimportant and arbitrary, unless it’s designed for public use. Since for a user the page is always in sync with its server, this api is an implementation detail as much as any other internal api (e.g. between service processes or between async-threads)

Why do you think that the project separation is unavoidable in this case? E.g. some of my sites are simple express apps serving scripts and resources. I don’t have integrated build pipelines there because… well, that is exactly my concern. There seems to be no reason that we couldn’t have an ~isomorphic project with multiple entry points on multiple “ends” and a single build system for all of them.

[pas]

I don't think it's unavoidable, but in practice it is two separate components with markedly different concerns and trade offs.

For example if we don't use any client side JS, use only a templating system, it becomes easy to keep it one project.

Eg. there's NextJS, which is a bundle of React and a NodeJS backed in one project. (And while it provides a getStaticProps and other gimmicks it doesn't really do much to make client-server state sync seamless. I still have to manually write the /api stuff.)