While the key idea behind micro-frontends is the same as for microservices — independent development and deployment — micro-frontend architecture presents very different problems.

No real isolation.
Backend microservices run in separate processes — often on separate machines. Micro-frontends share the same browser tab: the same DOM, CSS namespace, event system, storage, and main thread.

Limited deployment independence.
Backends integrate over the network — but micro-frontends integrate in memory. They depend on a shell application, shared routing and design systems: braking changes in those layers affect everyone.

Shared data is unavoidable.
A lot of frontend state is cross-cutting: feature flags, session, auth, cart contents. We can modularize code, but cannot pretend data ownership is cleanly separated.

Shared and constrained hardware.
On the backend, a slow service does not block CPU for others and can be easily scaled. In the browser, components compete for the same main thread, often on low-end mobile devices. Performance budgets are a cross-team concern.

Integration problems are very prominent.
Backend failures degrade responses. With proper loading and fallback states in UI, users may not even notice. Frontend failures degrade user experience: broken layout, flicker, inconsistent interactions — all seen immediately.

Splitting responsibility without breaking UX is the real challenge of micro-frontends.