If your HTML-generating code interfaces with a clearly-defined internal API, then your JSON API can be just a thin layer that authenticates the user and provides an HTTP front-end to your internal API.

Essentially, your web "client" is now the HTML-generating server-side code instead of a JavaScript app. Other clients are unaffected and can work the same as they otherwise would.

I've never worked with a web application where the requirements of the "customer facing API" and the "drives the web application API" (or the "drives the mobile application API", "drives the internal admin app API", etc.) matched for very long, if ever. Customers will usually need a small subset of the API that your web app does, the authentication will likely be different, you will need to make optimizations in your web app fetching that will be highly tuned to your specific use case, and a whole bunch of other concerns that make the idea of your web application being driven off your public API unrealistic.

Sure it can. Such as implying "the only way you'd be able to separate your backend logic into an API is if your browser client uses it".

Even if I knew I needed an API and multiple clients with 100% certainty (and most products don't), I would still prefer to build my browser client deeply integrated without separating the backend logic. The benefits of having at least one platform with faster dev speed cannot be overstated.

Ya, it all really comes down to the problem you’re solving and what makes sense for the task at hand. The point I was trying to get across in my other reply to you is that sometimes the thing that makes the most sense is an SPA (even if it’s less performant, or takes a little longer to build).