Micro Frontends
summary
Argues micro frontends let teams scale and modernize incrementally, showing concrete approaches: isolated runtimes via iframes (used for payments), shared runtime with web components via custom elements and the Stencil tool, and runtime communication with postMessage. Calls out real costs: heavy bundle sizes, memory from multiple framework instances, and UI drift; cites painful cases like 10–15 micro frontends for three developers and a working payment rollout at Lendl in production. Recommends component libraries, Storybook, and automated dependency tools.
AI-written summary · about
chapters (14)
- 0:00Start
- 0:36LETS TALK ABOUT MICRO FRONTENDS
- 1:05How to structure the development of a web application?
- 4:14Because your team is growing
- 5:32Because you have a legacy appliction and want to modernize
- 6:08BLOCKCHAIN
- 15:33Or use the tools you're already using
- 16:04WHAT ARE THE CHALLENGES?
- 20:37Another Approach
- 21:55Using the same framework everywhere?
- 24:26Multiple Micro- Frontends should not share code
- 25:23Do you hate webpack configs?
- 26:07Routing
- 27:10Conclusion Micro Frontends can help big time
related talks
29mMicro Frontends, how to evolve to an extensible frontend
29mMicro Frontends, or How to Evolve to an Extensible Frontend
57mMicro Frontends – a strive for fully verticalized systems
52mMicro frontends: prepare for the ride
10mMicrofrontends done right
27mMicro-frontends: anti-patterns
46mScaling Micro-Frontends with Custom Elements
36mMicrofrontends: Scalability Savior or Unmanageable Maze?
