Is that really easier than just responding to clicking things server side? Again I fully understand there are some use cases where that's just not possible but in my, admittedly limited, web development experience you can get a whole heck of a lot done server side with no JS at all

[–] towerful 2 points 4 months ago (1 children)

At scale, it can be considerably cheaper.
Limit data access according to security policy and some basic filtering from the request. It's not a huge amount of processing for an API server to do.
Web pages, desktop app, mobile apps, other servers can all use it to access the data.
Template rendering is then done on the client side. So processing for that is done on the client, saving a lot of compute cost - meaning the servers can respond to more API requests.
Data transferred is lower as well. A template that gets populated by the client using data from an API request will be overall smaller than the full template rendered server side.
The client apps can then be entirely managed separately from the server apps, without having to be tightly integrated. This allows the front end team to do what they want, and the backend team do what they want - as long as the API endpoints are correct.

For most things, an SPA isn't required or even desirable (which is why server side rendering of SPAs is a thing).
But SPAs should give a better experience to users, and can be easier to build.

[–] Scoopta 2 points 4 months ago

That's interesting, I suppose there are advantages to that. I personally believe those advantages don't outweigh the downsides of forcing users to run code in their browsers but that's an interesting perspective.