Panel: Ember at Scale
summary
Company apps hit concrete limits: a single Ember monolith holds 4,000 components and 600 routes, hundreds of engineers (often 150–200 developers) touch millions of lines of code, and cold builds shrink from hours to around 5–6 minute builds only after heavy work. Engines introduce subtle bundling and state-duplication bugs, Embroider and tree-shaking promise smaller payloads, yarn dedupe cuts build memory by ~40%, and switching to Glimmer/Octane yields 15–25% render improvements.
AI-written summary · about
chapters (10)
- 0:00Welcome and introduction
- 1:27Scaling challenges at Intercom
- 3:37LinkedIn’s Ember journey
- 6:05HashiCorp’s Ember ecosystem
- 8:11Clark’s Ember scaling issues
- 10:17Hiring Ember engineers
- 17:35Monolith vs engines debate
- 24:56Build time optimization
- 31:16Runtime performance tips
- 35:28Closing remarks
related talks
35mPanel: Ember – Why and Where?
30mEmber at Scale
28mModernizing a Massive Monolith
31mTaming the Beast: Managing a really ambitious codebase
40mEmber's Technical Foundations – And How They Are Changing
01h 01mOpening Keynote
33mScaling Frontend: Supercharging Productivity with Dedicated Infrastructure Teams
34mSoftware Productivity and Ember: Ember CLI