Tonal vs Teoria
Both answer music-theory questions in JavaScript. The practical difference is maintenance and API style, and one of them is clearly ahead.
Side by side
| Tonal | Teoria | |
|---|---|---|
| API style | Functional, immutable | Object-oriented |
| Modularity | Per-feature packages | Single library |
| TypeScript | Yes | No |
| Bundle impact | Import only what you need | Whole library |
| Coverage | Notes, intervals, scales, chords, keys, progressions | Notes, intervals, scales, chords |
| Language | JavaScript | JavaScript |
| License | MIT | MIT |
| Platforms | macOS Windows Linux Web | macOS Windows Linux Web |
| First released | 2015 | 2011 |
| Maintained | Yes | Not actively maintained (last activity 2017) |
Where they actually differ
Maintenance decides it
Tonal is actively developed with TypeScript types and regular releases. Teoria has been effectively dormant for years. For a dependency that sits at the centre of a music app, that difference outweighs any API preference.
Functional and modular versus object-oriented
Tonal exposes pure functions over strings and plain objects, and ships as separate packages so you can import only the scale logic if that is all you need. Teoria builds note and chord objects with methods. Both are workable; Tonal’s approach is easier to tree-shake and easier to test.
Tonal covers more ground
Key analysis, progressions, roman numerals and pitch-class set operations are available in Tonal’s package family. Teoria covers the fundamentals well but stops sooner.
Migration is not painful
Both work with note names as strings at the boundary, so replacing Teoria usually means rewriting call sites rather than restructuring your data.
Which should you choose?
Choose Tonal when…
- You are starting anything new
- You want TypeScript types
- You care about bundle size
- You need keys, progressions or set theory
Choose Teoria when…
- You have an existing Teoria codebase that works
- You specifically prefer an object-oriented API