If you build for the web and still read compatibility pages one by one, you are doing extra work. Compatibility data does not really become usable until it becomes SQL you can query [C002]. This project turns it into a 66MB SQLite file with 19,834 features and 260,715 support records.
The real cost is not just time reading docs. It is context switching. You check a browser page, jump back to chat, then back to code, then explain the same background again. AI tools are starting to eat not just coding work, but all the tiny chunks of time lost in those switches.
That is why this matters: simonw/browser-compat-db [C001] is not just another compatibility viewer. It turns MDN browser support data into something you can actually ask questions of. Which browsers support this? Since when? Under what limits? That is a different workflow from opening page after page.
The numbers are the point, not decoration: 19,834 features, 260,715 support records, one 66MB database file. At that size, treating compatibility as a handful of docs tabs stops making sense. A database is easier to compare across browsers, version numbers, old browser-specific names, and partial support than a deep tree of pages.
Many people think they need a smarter model. Most of the time they need fewer windows. If you want to know whether a tool change is real or just a nicer wrapper, ask one thing first: does it remove manual context-moving, or does it leave you doing the same work in a prettier interface? If this clicked for you, share it with the person still checking compatibility page by page.