Lesson 8: Performance

Benchmarks, bundle size comparisons, and optimization strategies.

Lesson 8 of 8: how @gentleduck/calendar compares to other React calendar libraries, plus optimization tips.

Bundle size

We replaced react-day-picker with @gentleduck/calendar. Comparison against the major React calendar libraries:

Core function benchmarks (average of 2000 iterations):

Generate benchmarks locally:

cd packages/duck-calendar && bun run benchmark

Tool	Result
publint	All good
attw (are-the-types-wrong)	Types correct for node10, node16, bundler
ESM	Pure ESM, `"type": "module"`

These are the changes that took the core bundle from 7.0 KB down to 4.9 KB gzipped (75% smaller than react-day-picker):

Intl.DateTimeFormat caching: formatters cached per locale+options, avoiding expensive re-instantiation.
Stable keyboard callback: configRef pattern, zero recreation cost.
Pre-computed time field orders: 4 static arrays replace Array.filter() on every keystroke.
Frozen selection constants: one UNSELECTED object shared across unselected days.
Dev JSX elimination: production build uses createElement directly, no jsxDEV metadata.

Pure functions: grid building and selection allocate no closures and hold no subscriptions.
No date library dependency: NativeAdapter uses native Date and Intl.DateTimeFormat.
Tree-shakeable: import only what you need; if it's just buildCalendarMonth, the rest goes.
Minimal React overhead: hooks use useMemo to avoid rebuilding grids on every render.
No CSS runtime: no CSS-in-JS overhead, no stylesheet injection.