I think this is a good assumption, but it breaks down when you look at bandwidth costs. A large reason why these apps take so long to load is because of the kb of dependencies and bundles they have to download. That adds up quickly with many visitors, and there's practically no way you would be accruing the same amount of bandwidth costs with a bland PHP or direct HTML response.
You think heavy HTML responses are cheaper than one extra-heavy initial JS request?
I'd like to see some analysis on that. I'm assuming if you're building an SPA or any kind of app, many of your visitors and clicks are repeat visitors and won't have to download that bundle... probably once a day, M-Th assuming daily release schedule w/ lets-not-break-it-before-the-weekend policy.
I think all that client-side caching would outweigh the cost of the initial bloated bundle.
> many of your visitors and clicks are repeat visitors
I think this isn't a guarantee and depends on what kind of application you're trying to build. A DMV website is (hopefully?) not going to have many users returning every day or even every week or month. If it's not social media or gaming, it's probably not going to have any sort of consistent userbase, so most visitors are not going to benefit from client side caching.
> You think heavy HTML responses are cheaper than one extra-heavy initial JS request?
If we assume "cheap" means cost-wise here, almost certainly. Consider a search engine like Google. If you are generating HTML server side (ex. PHP), the row count is limited by whatever you assume the user's screen resolution will be. That means a few hundred results returned at most, since no user is going to scroll through thousands of results on the same screen. So you perform a DB query and generate the HTML for a hundred rows or so and return it, job done.
Now consider the JS equivalent: the user downloads up to a megabyte of bundled JS. Then, the JS has to perform a fetch call to some API which probably returns the rows in JSON. At last, the client side JS iterates over the JSON and generates some new DOM elements for each row. Job done.
In the JS example, the user's browser had to download the bundle and the API response in order to render the rows, while the PHP example only queried the DB in order to render them. You might think, well the PHP way still uses up bandwidth to get results from the database right? Which is technically true, but pricing wise your database is most likely in the same data center as your web server so you're not paying anything for that bandwidth (since it's going over a physical direct connection cable instead of the Internet proper). Whereas the user is 100% not going to be in the same data center as your API server, so you're going to get whacked with bandwidth charges wherever your API is hosted on top of serving the JS bundle.
Of course, for the majority of people we're talking about pennies here. It really doesn't matter until you start getting more than 1 request per second, at which point every hour of every day of every month of every year is going to compound your bandwidth pricing problem until you figure out a way to slim down your payloads. Or, just do what most news sites do and keep adding third party advertiser JS until your ad profits outweigh your bandwidth expenses. Lots of options in this brave new frontier!
