Drawing the line between 3rd party and custom code
summary
Decision rule: pick a library that actually solves roughly 80% solution of your use cases and reduces risk, otherwise roll your own and accept maintenance cost. Measure impact with concrete tools: check gzip size on bundlephobia, view import sizes with import-cost, analyze bundles with webpack-bundle-analyzer, and run Chrome/Lighthouse audits. Inspect source and node_modules, watch GitHub stars/npm downloads for popularity signals, and prefer small native rewrites (example: replace jQuery toggle with element.classList) when code is mostly unused.
AI-written summary · about
chapters (9)
- 0:00Introduction and speaker intro
- 2:11Why we build applications
- 4:19How we decide on tools
- 9:38Key factors in decision-making
- 14:03Open source benefits and risks
- 16:56When to roll your own code
- 19:48Finding the right balance
- 21:11Making good decisions
- 22:35Best practices and legacy code
related talks
27mDrawing the line between 3rd party and handcrafted code
24mThe missing guide for deciding between 3rd party library and custom code -JSWORLD 2023
06mLightning talk from Andrey Sitnik
35mKnowing Your TCO (Total Cost of Ownership)
42mYour library sucks, and why you should use it
45mLightning talks
30mOptimizing for Developer Delight
26mInvisible Code: Building JavaScript Libraries For Non-Technical People
