> why I've always been puzzled by the urge to move more and more logic to the frontend.This is usually about a mix of scalability, responsiveness, and partition resilience; with the level of importance of those being dependent on the application.
* Scale: if the client makes fewer request of the server(s) then you have reduced server and network requirements. As server resources get cheaper (and the cheap options more reliable) that side of things is becoming less important, but the network requirements extend far beyond you and almost all the way to the user (see the following two points) who might have a very slow connection at times.
* Responsiveness: the more that you can do client side the quicker your application will feel to the user, even if there is a delay in updates actually hitting the global view you can make it look/feel instantaneous (though you do start to have more problems wrt conflict management when people are collaborating). Have a look at the different methods online games (where real responsiveness and the appearance of instant iteration are vital) manage this.
* Partition resilience: if the client can keep working for a while without needing to talk to other hosts, perhaps queuing updates for reply when communication is restored, your application can keep functioning if there is an issue at your end (glitch at your server provider perhaps) or the user's (on mobile and temporarily in a radio blackspot?) or in between (i.e. a routing issue between ISPs). Even partial resilience is better than none: even if I can't see other people's updates until I'm back in a good signal area, if the app calmly tells me so but allows me to continue to add my work and review already locally cached information I can continue to work (or play!) in a way that wouldn't be possible if more of the logic were server-side.
