Framework Design - Lessons Learned from Repeated Mistakes
summary
Frameworks encode other engineers’ hard-won opinions and manage app structure rather than just offering functions, and that distinction drives API choices: keep interfaces small and consistent, make operations orthogonal (CRUD and opposites), and encapsulate internals including CSS. Documentation must include copy‑paste examples, tooling and scaffolding enforce patterns, tests guard promises, and a plugin model preserves a small core + plugins footprint. The author recounts rewriting a framework six times as usage exposes better designs.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 3:00Libraries
- 5:04Library
- 7:50Frameworks
- 11:26API
- 11:56Keep your API small
- 13:40Make your functions intuitive
- 15:04Keep your APIs orthogonal
- 16:51Encapsulation
- 18:15Documentation
- 19:01Error Handling
- 22:27Promises
- 23:28Opinions critical
- 24:43What is a framework
- 25:29Conclusion
related talks
32mWhy Invent a Framework and How to Live with It?
27mDesigning Even Larger (JavaScript) Applications
49mFrom Frameworks to Superframeworks
32mMiss the forest for the trees: How frontend developers fail to be engineers
18mA framework author's case against frameworks
56mThe Web, Its Frameworks and Its Standards: Deconstruct to (Re?)Construct
50mI Don’t Care About Your JavaScript Framework
30mFrom futons to functions: the principles of good API design