Microfrontends and theming: visual consistency vs host coupling

[victoraf-11]

Microfrontends + theming: visual consistency vs host coupling

I'm a frontend engineer working primarily with Angular and microfrontend-based architectures. In our current setup, microfrontends are independently developed and deployed, and composed into a host application.

The specific composition mechanism (Module Federation, single-spa, iframe-based, etc.) is intentionally not the focus here. The question is architectural and framework-agnostic.

The core problem is the following:

How can we maintain visual consistency between a host application and its microfrontends
without introducing tight coupling that undermines microfrontend autonomy and independent evolution?

In our case, Angular Material is used today, but the concerns described below should apply equally to any UI framework or design system.

Possible approaches

1. Centralized theming in the host

The host application defines the theme and produces the final CSS at build time. Microfrontends implicitly inherit this styling at runtime.

Concerns:

• Implicit dependency: MFEs become coupled to the host’s theming implementation.
• Host-side visual changes may break MFEs without changes in their code.
• Limits independent evolution and versioning of microfrontends.

2. Theming defined independently in host and MFEs

Both the host and each microfrontend define their own theming configuration.

Concerns:

• Redundant definitions and duplication of design decisions.
• Visual drift over time as the system evolves.
• If a core brand value changes (e.g. primary color), all MFEs must be updated manually.
• Increasing maintenance cost in the medium to long term.

3. Global design tokens provided by the host

The host exposes design tokens (CSS variables for colors, typography, spacing, etc.). Microfrontends consume these tokens and define their own local theming on top of them.

Open questions:

• MFEs become dependent on brand-level tokens.
• How should token versioning and backward compatibility be handled?
• What happens when a microfrontend is consumed outside the main “brand” host?

4. Per-microfrontend design tokens configured by the host

Each microfrontend defines its own namespaced design tokens. The host configures those tokens at integration time. The microfrontend builds its internal theming using the values provided by the host.

Concerns:

• Higher complexity in token definition, documentation, and coordination.
• More delicate versioning contracts between MFEs and hosts.
• Risk of over-engineering if not strictly governed.

Note: approaches 3 and 4 are two sides of the same coin: using design tokens to decouple theming from the UI framework, trading simplicity for autonomy.

Other related concerns

Asset ownership

Where should assets used by a microfrontend live?

• In general, it seems reasonable for MFEs to own their assets.
• However, some assets are inherently host-defined (e.g. application logo, brand imagery).

How do you typically define and enforce this boundary in real-world systems?

Questions for the community

• How do you handle theming in microfrontend architectures?
• Where do you draw the line between visual consistency and microfrontend independence?
• What challenges have you encountered in the medium to long term?
• Have design tokens helped, or introduced new forms of coupling?

Note

This is not a bug report, but an architectural discussion about long-term maintainability, coupling boundaries, and design contracts between hosts and microfrontends.

An earlier version of this discussion was raised in a framework-specific context; this version intentionally generalizes the problem.