A brief history and mishistory of modularity
summary
Argument: modularity means choices about what to hide from other parts of the system, not vague “separation of concerns.” Evidence: the npm registry scale (hundreds of thousands of packages, billions of monthly downloads) and the left-pad outage show real fragility. Tool comparison shows runtime cost: browserify/webpack preserve modularity (per-module wrappers) while rollup hoists into a single function, reducing lookup overhead. Recommendation: slice modules to isolate likely-to-change decisions, prefer disposable code, and measure bundle/runtime impact before splitting further.
AI-written summary · about
chapters (20)
- 0:00Intro
- 2:00MPM
- 4:10Thinking
- 6:25Modularity
- 10:00Modularity and time
- 10:50What is modularity
- 12:58The largest module repository
- 13:45Why so many modules
- 14:45Definition of modularity
- 15:30Small modules philosophy
- 16:35How small is too small
- 18:55Did we forget to program
- 19:20No true programmer
- 24:20Information
- 25:45Nolan Lawson
- 29:03Rich Harris
- 29:27Cost of modularity
- 30:40Misconceptions
- 33:20Intuition
- 36:13Spacetime
related talks
30mA brief history and mishistory of modularity
29mA Brief History of Modularity
19mModularity Matters
01mMark Richards at DDD Europe
36mUnbundling the JavaScript module bundler
56mComponents and Modules
19mMaking front end modules actually work
41mThe future is modules not frameworks. JS modules Architecture demo.