What Can We Learn With JavaScript Fatigue?
summary
Argues JavaScript fatigue often equals decision fatigue and backs it with numbers and histories: NPM 520k packages, npm traffic up 1,000×, and concrete tool chains like Babel, Webpack, Mocha, React, Node and mocha/Chai examples. Shows surprising error splits — 36% coding errors 64% design errors, NASA Apollo 73% design — and demos the practical rule set: take small steps, learn fundamentals on demand, build simple versions, avoid premature optimization, prefer single‑purpose tools and measure whether added complexity actually solves a real problem.
AI-written summary · about
chapters (9)
- 0:00Intro
- 1:16Technology is not a go
- 3:07Importance of good design
- 8:46Why do we need these technologies
- 14:02Dont be defined by your stack
- 15:36Dig deep
- 17:00Build things yourself
- 18:22Microservices analogy
- 19:30Conclusion
related talks
19mWhat Can We Learn With JavaScript Fatigue
39mWhat Can We Learn With JavaScript Fatigue?
23mWorse is Better: The Upside of JavaScript Fatigue
35mFighting the Front-end Fatigue
41mThe Future of JavaScript Package Management
58mImproving the Quality of JavaScript Code
20mJavaScript’s “+” Operator and Decision Fatigue
06mLightning talk from Andrey Sitnik
