Animations are still better off handled client side, though you can go far with web components and liveview updated HTML: https://github.com/hmans/three-elements
Definitely not it's intended use case, but it works perfectly on regular Internet latencies in the 100-300ms ranges.
Whereas interactive elements just require an update in 100ms or 200ms after the user pressed a button, which is not that hard to achieve.
For server rendered animations, all the frames might be delayed due to geographical distance, but the time gap between the arrival of individual frames is not affected by geographical distance. The server is not waiting for the client to request the next frame, it’s always pushing.
For the user, it’s similar to watching a streaming video after letting it buffer a bit.
For interactive elements, every interaction has to go through the round trip. So the gap between interactions is affected by distance.
Server rendered games would suffer much more than server rendered animation.
For example, if you want a 60 fps animation created and the server is far far away, like the other side of the globe that could be an issue or if your connection is bad.
With liveview, you cannot create offline apps without javascript for example. That is a big limitation. But since most apps don't really require offline capabilities that is not really a big issue.
I have however tried to use a liveview hosted in Sweden from Japan (which is basically on the other side of the globe) and I didn't experience any noticable latency for simple html updates.
I think if you're making a game, you'll still need to use javascript. But if you are just making a simple crud app you may not need it for at least most of the stuff.
I still think creating modals or things that the user expects to be instant should perhaps still be done in javascript but for all the server requested data liveview is probably faster than your average SPA.