Historically, user-facing applications were rendered on the server — the same place where all logic resides. The backend processed requests and generated HTML dynamically.

Around 2010, single page applications (SPA) emerged. HTML started being generating in the browser using data from backend, which enabled complex state management and rich UI interactions.

Today, we see a partial return to server-side rendering (SSR) for performance and SEO reasons. Still, state orchestration and smooth UX remain complex enough to require dedicated frontend expertise.

Just like backend systems, frontend codebases often start as monoliths. And just like in the backend world, once a frontend team grows beyond ~5 engineers, coordination becomes harder, release cycles slow down, and ownership becomes blurry, calling for split teams — the micro-frontend approach.

Usually this is achieved by having a shell application that provides layout, routing, and shared infrastructure. Independent frontend teams work on separate pages or feature slices, that are composed at runtime.

Core principles of micro-frontends:

• Isolation
  Unlike backend microservices, code from different teams ends up in the same browser page — so teams have to namespace CSS classes, browser events, cookies and local storage items.

• Resilience
  A robust frontend prioritizes server-side rendering and progressive enhancement. Teams should rely on server-side rendering, using client-side JS to enhance UX.

• Technology agnosticism
  Teams should be able to choose their frontend stacks, which should not affect performance or user experience of the whole SPA.

Microservice thinking is not limited to backend systems. The idea of independent teams working on well-defined, isolated components applies to any system divisible by such components.