If the search finds a matching guide, you can be pretty confident that a human expert has reviewed this and the result is in fact the best way to do X using the modern web platform (complete with fallbacks).

FWIW, Modern Web Guidance can *also* be used as a learning tool, and we're planning to promote that use case more. For example, if someone wants to know what the "best" way is to build a navigation drawer, they could run: npx modern-web-guidance@latest search "navigation drawer"

Modern Web Guidance v0.0.192 is out. With it your coding agent now knows how to: • build SMS one-time-code forms that autofill (WebOTP) • make dark mode toggles that follow the OS • honor the OS text size setting • reduce INP and lazy-load video/audio • feature-detect CSS at-rules with @supports

Even granting that Chrome has shipped some features before they should have, that doesn't change the reality that literally millions of sites deploy features that are only in 1 browser. I'm arguing that it's better if those sites have access to correct types for the features they choose to use.

I'm not sure that's true. Regardless, the question is fine and my response is useful to anyone else following along.

Friction can be a good thing. But I'd argue the biggest threat to the web is not compat bugs; it's competition from other platforms, where businesses are choosing those platforms over the web (e.g. "It works better in the app" banners). You don't want to put too much friction in the way of progress

The mischaracterization I'm referring to was "without consulting standards bodies first" We can have a healthy debate about whether Chrome decides to ship some features too early, but it is definitely not the case that Chrome ships features without consulting standards bodies.

This is not an accurate characterization of how Chrome ships new web features.

Your requiestIdleCallback example actually demonstrates this point because right now requestIdleCallback *IS* in TypeScript but it's still not available in Safari.

TypeScript is not the best tool for guarding against accidentally shipping a feature you shouldn't. That's a job for a linter (connected to Baseline or Browserslist data) and, ultimately, for your test suite to catch. Also, as I say in the post, the 2-engine rule won't protect you from that anyway.

The good news: TS's type-generation pipeline is open source, and the datasets it consumes already include the full set of web platform features—even those only in one browser. So if you remove the 2-engine restriction, you can use the same generator to create types for all web features.

TS has a policy to exclude web features unless they're supported in at least 2 browser engines. That means TS can be missing types for perfectly valid APIs—including APIs that are safe to use today as a progressive enhancement.

If you've ever tried using a new web API in TypeScript, you've probably hit this problem: An API exists. It works in your browser. But TypeScript has no types for it. The reason is a limitation that TS unfortunately applies to its built-in libs. BUT, I've created a relatively simple fix 👇