Evolution of Client-Side Architectures
In this article, we take a brief look at the evolution of client-side architectures and how they shaped the web as we know it today.
we need to keep in mind that all of the innovations are designed to solve the business problem efficiently, based on these metrics:
1- Performance
2- Complexity
3- Team size
4- Cost
in the early age of software engineering, most business logic was handled on the server side.
we mainly needed to render static data in the browser and make it accessible to users.
Server-side MVC :
since we already have a server application, it was easy to access databases and send pre-rerendered html to the browser from one centralized point. By the early 2000s, this marked the end of the debate, and frameworks like Django and ASP.NET became popular within developers’ stacks.
With the increase of web visitors, businesses started to expect the web to behave more like web applications, so new problems started to appear , servers are receiving heavy interactivity load , and more developers are needed to focus on the client side .
at this stage, vanilla javascript already introduced client-side logic, DOM manipulation, async communication ,
SPA :
JS frameworks ERA, where the structured workflows and design patterns philosophy migrated to the client side now,
many architectural patterns appeared under the single page applications:
Component based : mostly common for simple applications
BFF : backend for frontend where the frontend owns the backend api DTO
appeared with the multi client backend servers to avoid ( over / under) fetching data.
MVVM : Model–view–viewmodel a classic separation of
data, business logic, UI.
FLUX : Unidirectional (Action → Dispatcher → Store → View)
data flow pattern with centralized state management, Redux, Vuex.
SSR/SSG/ISR : Pre rendering strategies mainly to improve performance, SEO, and initial load experience.
"Note" for classic modular architectures:
classic architectures like : Clean, Hexagonal, Onion are optimized heavily for backend, can be applied conceptually in the frontend, only for long lived projects, where business logic doucoupling is extremely important but in most projects its hard to define boundaries and expect everyone to respect them also the frameworks and there ecosystem were already opinionated.
now dedicated teams can solve complex data flows, Heavy UI rendering, apply unique patterns, so we saw a release of large scale web-platforms, like Facebook, amazon and Binance but tight coupling and technical opinion conflicts appeared.
Microfrontends
When many engineers worked on large modules, and the vertical scaling was not enough,
the term microfrontends appeared as an inspiration from microservices,
where different Modules built with different technologies and design patterns can be deployed and managed separately.
Bonus
with this trendy orientation into the browser, even heavy desktop applications and low-level systems began shifting toward the web. WebAssembly (Wasm) made it possible to run near native performance code in the browser, allowing languages like C, C++, and Rust to target the web without rewriting everything in JavaScript.