Unfortunately with today's SPA apps we don't even get the HTML directly, but with the recent resurgence of server-side rendering we may soon be able to get rendered HTML with one HTTP request. And then the only hurdles will be legal.
It works the other way: with today's SPAs the API (that powers the frontend) is exposed for us to use directly, without going through the HTML - just use your browser's devtools to inspect the network/fetch/XHR requests and build your own client.
-----
On an related-but-unrelated note: I don't know why so many website companies aren't allowing users to pay to use their own client: it's win-win-win: the service operator gets new revenue to make-up for the lack of ads in third-party clients, it doesn't cost the operator anything (because their web-services and APIs are already going to be well-documented, right?), and makes the user/consumer-base happy because they can use a specialized client.
Where would Twitter be today if we could continue to use Tweetbot and other clients with our own single-user API-key or so?
On the user side you need to:
- pay the service a recurring fee
- pay the client probably a recurring fee (x2 or x3 if you use multiple clients on different platform)
- mix and match the above and manage when it falls out of sync
It's totally possible, but how many users are willing to go that route ? Weather apps could be an example of that with the pluggable data sources, but that's to me a crazy small niche.