I don’t know that there’s a precise, shared definition of “microfrontends,” but LinkedIn has been doing something like this for a few years now via Ember engines. Here’s how it works:

Each “pillar” on LinkedIn (e.g Feed, Profile, My Network, etc.) is its own isolated Ember app (called an engine), and at build time it all gets stitched together into the single integrated experience you get when you log in to http://linkedin.com .

While each engine/“microfrontend” is isolated by default, it can request access to shared app-wide objects (e.g. auth or i18n services). The code for each engine is lazily loaded the first time a member navigates to that URL.

The current system is based on concatenated AMD modules, but we are currently working on integrating Embroider ( https://github.com/embroider-build/embroider) which uses webpack for more aggressive treeshaking/code splitting.

We also have some rules in place to prevent payload bloat and hard-to-debug issues, e.g. what we affectionately call “the Highlander rule”—there can only be one version of large shared dependencies across all the microfrontends.

But for us, microfrontends are fundamentally about enabling teams to iterate quickly and independently without stepping on each other’s toes, even in our (very very large) Ember app.

(I will also note that microfrontends are far from perfect and introduce exciting new problems to deal with. It’s no silver bullet. But especially at LinkedIn scale, it’s a valuable tool I’m glad we have in our toolbelt.)

Thank you for coming to my TED talk.