In the early days of the browser-based internet, the UI layer was gold-paper thin.

Browsers were not even capable of processing user input from day one. Computers were slow and didn’t have a lot of memory or video capabilities. Cascading Style Sheets (CSS), the iPhone, Android hadn’t been invented yet.

And so the logical consequence was that (almost) all the rendering logic was processed server-side. And so the weight of each layer looked like this: a lot of logic and code in the back-end or system layer, then a process layer that also implemented the rendering logic that couldn’t yet be done in a browser:

Performance of the devices and browser improved over the decades, the increasing user experience demands of people and the evolution of the client-side software pushed us to improve user interfaces.

The back-end layer partially crumbled into small services, while other parts were replaced by SaaS APIs.

And so when we look at the weight of the layers when building a system today, it looks more like this:

Consequences

This however is not without consequences.  Some of the things that were handled by the process layer now must happen in the UI layer, like: orchestration, caching and even CQRS and event-sourcing. 

The latter is a very interesting evolution as it is a tell for a more global trend : the introduction of engineering practices to the UI layer. 

Componentization (thanks to frameworks like ReactJS), patterns & design systems, libraries…

These are thrilling times 🙂