The eternal client server pendulum

A few decades ago when Java applets were all the rage an acquaintance of mine remarked that it was just the next wave in the eternal pendulum of functionality moving from server to client and back. His remark struck me as naive. This acquaintance probably did not hear about the incredible promise of Java applets. Well, truth be told, he was right. And in the meantime he has been right more often than I would ever thought possible. But not immediately.

We all know what happened to Java applets and instead of functionality moving to the client, we got servers doing the heavy lifting of calculating and rendering responses. Clients in general didn't have the resources to take on this responsibility. Remember LAMP and all the variations?

Clients gained power pretty quickly though and before too long functionality was moving back to the client again. This time in the form of Flash, JavaScript and mobile apps. Frontends got smarter and smarter and backends were dumbed down to CRUD machines exposing state via REST API's. This was because clients were becoming capable and, as always, of technical limitations. Bandwidth was limited, unstable and with a latency that killed the user experience. 

But lo and behold! Recent trends indicate functionality is moving back to the server again. Bandwidth and latency limitations are now minimized, and cloud computing has become so available, affordable, powerful and versatile, that it is becoming easier to let the backend take care of all the heavy lifting again. Whowouldhavethunk! But it's also because the complexity on the client side has really gotten out of hand. Anyone who has recently built a reasonably big application knows exactly what I'm talking about. The frontend space is moving so fast that keeping up with the latest trend is a fulltime job. And it's not getting any easier. Just have a look at all the client side state management solutions. Every web framework has at least one unique solution. And there are a gazillion web frameworks out there. Or dive into all the different communication protocols. HTTP 1 or 2? REST or gRPC? Or GraphQL? SignalR? Yaml or JSON? Or protobuf? Or Avro? The solution space is just mind boggling at this point in time. So new kids on the block such as Svelte and Phoenix Liveview  focus on the backend as the place where most of the magic happens. Clients are once again reduced to dumb screens that do nothing more than displaying pretty pictures.
So it's deja vu again (again!). Why is it always going back and forth? I think because when clients get more powerful functionality is shipped their way to compensate for limitations in either the network (bandwidth, latency) or the server (memory, processing power, price, …). But since the state of applications are almost always shared with the outer world, this comes with a ton of extra complexity. Distributed applications are simply a lot harder to get right than centralized ones. So once the server can take over again they will. Just because it's simpler. Clients will take over some of the functionality as long as there are limitations in the network or the backend. And these will be solved one by one over time.
My long standing prediction is that the unstoppable force of centralization will lead us to a future where client side terminals are nothing more than sheets of glass for displaying content and all the magic happens in the back end. But in the meantime we might be going back and forth a few more times.