| @forcecalendar/core | 2.1.53 |
| @forcecalendar/interface | 1.0.57 |
| @fullcalendar/core | 6.1.20 |
| @fullcalendar/daygrid | 6.1.20 |
| @fullcalendar/timegrid | 6.1.20 |
| @fullcalendar/list | 6.1.20 |
| @fullcalendar/rrule | 6.1.20 |
| rrule | 2.8.1 |
| Package | Size |
|---|---|
| @forcecalendar/core | 365.5 KB |
| @forcecalendar/interface | 715.7 KB |
| Total | 1.06 MB |
| Package | Size |
|---|---|
| @fullcalendar/core | 1.81 MB |
| @fullcalendar/daygrid | 201.5 KB |
| @fullcalendar/timegrid | 235.6 KB |
| @fullcalendar/list | 70.7 KB |
| @fullcalendar/rrule | 30.2 KB |
| rrule | 699.1 KB |
| Total | 3.01 MB |
Installed size measured via du -sb node_modules/package. All packages installed from npm, not local builds. ForceCalendar ships core + interface for equivalent functionality to FullCalendar's multi-package stack.
ForceCalendar's built-in RecurrenceEngine vs the standalone rrule library (v2.8.1). Both are pure JavaScript implementations processing RFC 5545 recurrence rules. Higher ops/sec is better.
Note: rrule wins 5 of 5 test cases. It is a mature, dedicated library and is faster for recurrence expansion. ForceCalendar's engine trades raw speed for tighter integration with its event model.
| Pattern | Occurrences | ForceCalendar ops/s | rrule ops/s | Winner |
|---|---|---|---|---|
| Daily for 1 year | 365 | 1,701 | 28,948 | rrule (17.0x) |
| Weekly (MWF) for 1 year | 156 | 2,136 | 64,763 | rrule (30.3x) |
| Monthly (15th) for 5 years | 60 | 7,303 | 160,378 | rrule (22.0x) |
| Yearly for 10 years | 10 | 54,260 | 629,105 | rrule (11.6x) |
| Daily for 5 years (1825 occurrences) | 1,825 | 3 | 3,859 | rrule (1286.3x) |
What we compare
- +Bundle size -- installed node_modules footprint for equivalent calendar functionality
- +Recurrence expansion -- pure JS performance generating occurrences from RRULE patterns
- +Reproducibility -- all benchmarks use tinybench with warmup, run on the same machine, same Node version
What we do not compare
- --DOM rendering -- ForceCalendar core is DOM-free; FullCalendar renders directly. Apples to oranges.
- --Memory usage -- different architectures make heap comparisons misleading
- --Feature parity -- both libraries have capabilities the other does not; this is not a feature comparison
How we measure
- 1.Bundle size is measured with
du -sbon each package'snode_modules/directory. This is the installed size on disk, not minified or gzipped transfer size. All packages are installed fresh from npm. - 2.Recurrence is benchmarked with tinybench, which runs each function through a warmup phase then measures operations per second over multiple iterations. Test patterns: daily (365 and 1825 occurrences), weekly MWF (156), monthly on the 15th (60), and yearly (10).
- 3.Automation — benchmarks re-run automatically via GitHub Actions on every release and weekly on Sundays. Results are committed to the repository and this dashboard updates on each push.
Results may vary across environments. The source code and runner are open source — verify the methodology and reproduce the results yourself.