Microfrontends and theming: visual consistency vs host coupling

[victoraf-11]

For which library do you need help?

native-federation

Question

Microfrontends + theming: visual consistency vs host coupling

Related topics

• Previous microfrontend discussion (closed): Critical Limitation in Native Federation for Resolving Shared Dependencies #968

Context

We're working with a microfrontend architecture in Angular. We use Angular Material for the UI in both the host and the microfrontends, but the points here aren’t tied to a specific UI framework: the principles should apply generally. These microfrontends are also intended to be reused in other apps that might not use Angular Material at all.

The core question: how do we maintain visual consistency between host and microfrontend without creating too much structural coupling?

Possible approaches

1. Centralized theming in the host
   The host defines the theme using Angular Material (for example, v17) with SASS and generates the CSS at build-time. Microfrontends "inherit" the theme defined by the host.

   Concerns:

   • Implicit dependency between host and MFEs: the host must use Angular Material even if its own implementation doesn’t need it.
   • Host visual changes can break MFEs without touching their code.
   • Harder to evolve or version MFEs independently.

2. Theming defined in both host and MFE
   Both the host and each microfrontend define their own theming.

   Concerns:

   • Redundant definitions.
   • Maintaining visual consistency if the host changes colors or styles: if the primary color changes in the host, it should also be updated in the microfrontend. Could this configuration be shared?
   • Medium-term maintenance overhead.

3. Global design tokens
   The host exposes design tokens (CSS variables, base typography, spacing, etc.) that MFEs consume to define their own local theming.

   Open questions:

   • MFEs depend on variables defined at a "brand" level.
   • What happens if a microfrontend is integrated outside the main brand app?

4. Per-MFE design tokens
   Each MFE defines its own design tokens with a unique namespace. The host defines its own theming and configures the design tokens exposed by the microfrontend. The microfrontend then defines its own theming using the CSS variables configured by the host.

   Concerns:

   • Extra complexity in token management and coordination.
   • More delicate versioning of tokens and MFEs independently.

Note: approaches 3 and 4 are basically two sides of the same coin: using tokens to decouple theming from the UI framework, balancing autonomy vs complexity.

Other related points

• Assets: where should resources used by a microfrontend live: in the host or in the microfrontend itself? We assume they should live in the microfrontend, but what about resources that must be provided by the host (e.g., the application logo)?

References

• Scaling CSS in Micro Frontends: https://blog.logrocket.com/scaling-css-in-micro-frontends/

Proof of Concept (PoC)

To ground this discussion in concrete experiments, I’ve built a public PoC repository exploring different theming strategies in an Angular microfrontend architecture (Angular Material + Native Federation):

• PoC repository:
  https://github.com/victoraf-11/poc-angular-mfe-theming

The PoC includes:

• Multiple theming approaches evaluated in isolation.
• Experiments around design tokens, host–MFE responsibilities, and versioning boundaries.
• Documentation summarizing findings, trade-offs, and constraints observed during implementation.

The goal of the PoC is not to present a definitive solution, but to provide a realistic baseline for discussing:

• Visual consistency vs. autonomy.
• Host coupling introduced by theming decisions.
• Long-term maintainability and evolution of MFEs.

Feedback on the architectural direction, assumptions, and conclusions drawn from these experiments is especially welcome.

Questions for the community

• How do you handle theming in microfrontend architectures?
• Where do you draw the line between visual consistency and independence?
• What challenges have you faced in the medium to long term?

---

Note

This is not a bug report, but an architectural discussion related to the autonomy of microfrontends and their long-term maintainability.
If another label fits better (e.g. architecture, microfrontends, theming), feel free to adjust it.