Designing very large JavaScript applications
summary
Claims that a web app can keep first‑load JS constant even as hundreds of engineers add features and that no line of JS need ever load unless required. Demonstrates route‑based code‑splitting, dynamic import, server‑side rendering vs hydration tradeoffs, and a concrete 800 KB base‑bundle failure. Introduces three concrete techniques—lazy decoration, asynchronous dependency injection, and reverse dependencies (the "enhance" pattern used for generated code and otherwise banned)—and enforces constraints with forbidden dependency tests to keep the graph clean.
AI-written summary · about
chapters (12)
- 0:00Start
- 3:59I KNOW HOW OTHERS WOULD SOLVE THE PROBLEM
- 4:34AN APPLICATION OF EMPATHY
- 4:53EMPATHY ON EASY MODE
- 5:19PROGRAMMING MODEL
- 9:42DESIGNING VERY LARGE JAVASCRIPT APPLICATIONS
- 11:52REACT COMPONENTS STATICALLY DEPEND ON THEIR CHILDREN.
- 13:29SPLIT LOGIC AND RENDERING
- 16:39AVOID CENTRAL CONFIGURATION AT ALL COST
- 19:28THE CENTRAL IMPORT PROBLEM
- 25:05FORBIDDEN DEPENDENCY TESTS
- 27:41NO ABSTRACTION IS BETTER THAN THE WRONG ABSTRACTION
related talks
27mDesigning Even Larger (JavaScript) Applications
28mLa nouvelle vague
29mBuilding Large-Scale Web Apps
01h 13mArchitecting complex JavaScript setups for large scale enterprise projects
47m2017 DevFestMN Eric Brandes
31mSpeeding up Startup for Large React Apps
51mBuilding Amazing Single Page Applications the Right Way
27mA novel, efficient approach to JavaScript loading