What is a polyfill?

A polyfill is code that implements a feature the current browser lacks, so the rest of your code can use it as though it were native.

if (!Array.prototype.at) {
  Array.prototype.at = function (i) {
    const n = Math.trunc(i) || 0;
    return this[n < 0 ? this.length + n : n];
  };
}

Note the feature detection. A polyfill must check first and do nothing when the native version exists — the native one is faster and more correct, and overwriting it can break other libraries.

Polyfill vs transpiling

They solve different problems and you usually need both:

• Transpiling (Babel, TypeScript) rewrites syntax the engine cannot parse — arrow functions, optional chaining, class fields. A polyfill cannot help here, because the file would fail to parse before any code ran.
• Polyfilling adds missing runtime features — Promise, fetch, Array.prototype.includes, IntersectionObserver.

What cannot be polyfilled

Anything needing engine or platform support that JavaScript cannot express: new syntax, WeakRef semantics, real CSS features, hardware APIs. Some APIs get a partial fill — often called a "ponyfill" when it is exported as a plain function instead of patching a global, which avoids the risk of conflicting with another library's patch.

Do not ship them to everyone

The usual mistake is bundling a large polyfill set for all users, so modern browsers download code they will never execute. Better options:

• core-js with browserslist and useBuiltIns: "usage", so Babel includes only what your targets actually need.
• A polyfill service that serves a bundle tailored to the requesting user agent.
• Simply dropping support for browsers your analytics show nobody uses.

Check browserslist occasionally. Many projects still ship polyfills for browsers that disappeared years ago, which is pure payload for no benefit.