A Brief History of Modularity
summary
The talk stakes that modularity wins when it isolates design decisions likely to change, not when it follows the vague “separation of concerns” mantra; cites npm with ~472,000 packages and 2 billion downloads a week and the Left Pad incident to show scale; measures real costs via webpack/Browserify/Rollup comparisons that collapse closures and cut runtime overhead; cites David Parnas’ criterion and argues for disposable code over gratuitous reuse, recommending modules for genuinely hard, change-prone parts.
AI-written summary · about
chapters (27)
- 0:00Introduction
- 2:10Who am I
- 3:50Questions from beginners
- 4:45Motivation for writing modular code
- 7:45Modularity and time
- 9:26The packaged ecosystem
- 9:56Why modularity
- 11:03What is modularity
- 12:09How small is too small
- 14:39Reusable abstractions
- 15:55Comments are hard
- 16:44Complex systems
- 17:10Problems with modularity
- 17:37Modular tools
- 19:12Lowlevel programming concepts
- 19:58Transpiler
- 20:27Disadvantages of modularity
- 20:55Why we love modularity
- 21:17Microservices
- 21:55Misconception
- 22:32The 21st Century
- 22:52David Parnas
- 23:52JeanPaul Sartre
- 24:38Writing easy to extend code
- 25:36The return of conservatism
- 27:05Summary
- 27:45Tools
related talks
30mA brief history and mishistory of modularity
39mA brief history and mishistory of modularity
19mModularity Matters
01mMark Richards at DDD Europe
53mArchitecting Robust JavaScript Applications
46mModular Applications with Spring
29mModularity and Monorepositories
01h 10mModular JavaScript: Dynamic Dependency Resolution