Что такое полифил

Полифил закрывает дыру в возможностях среды выполнения. Вы пишете код под стандартный API, но часть браузеров этот API еще не знает. Тогда полифил добавляет реализацию, чтобы код не падал у пользователей с такими браузерами.

Короткий ответ на интервью может звучать так:

Полифил добавляет недостающую стандартную функцию в старый браузер. Он нужен для совместимости, но за него платят размером бандла и риском неполной эмуляции. Поэтому я подключаю его под конкретные целевые браузеры и конкретный API.

Важно не звучать так, будто полифил делает браузер полностью современным. Он решает только конкретную задачу и только в рамках того, что вообще можно реализовать на JavaScript или поверх доступных браузерных возможностей.

Транспиляция отвечает за синтаксис. Например, сборщик может превратить стрелочную функцию в обычную функцию, чтобы старый браузер смог распарсить файл.

Полифил отвечает за runtime API. Если в браузере нет метода или объекта, одного переписывания синтаксиса мало.

const hasSelected = selectedIds.includes(currentId);

Если старый браузер не поддерживает Array.prototype.includes, этот код может упасть с ошибкой. Транспилятор не обязан автоматически заменить такой вызов. Нужен полифил, явная совместимая альтернатива или настройка инструмента, который добавит нужные runtime зависимости.

Хороший ответ показывает критерий выбора. Не нужно говорить, что полифилы всегда нужны или всегда вредны. Сначала есть продуктовый вопрос: кого вы поддерживаете и что случится, если API недоступен.

Если без API ломается форма оплаты, авторизация или основной экран, полифил может быть оправдан. Если речь о небольшой декоративной функции, иногда лучше дать fallback и не увеличивать общий JavaScript.

Опасный путь выглядит так: импортировать большой набор полифилов в точке входа и не проверять, кому он нужен. Это может быть проще на старте, но потом бандл растет, а пользователи современных браузеров получают лишний код.

Более аккуратный путь: поддерживать список целевых браузеров, смотреть поддержку конкретных API, проверять результат в bundle analyzer и тестировать старые среды, если они важны для продукта.

Если в проекте есть SSR, отдельно проверьте, где выполняется код полифила. Импорт, который обращается к window или document на сервере, может сломать рендер до отправки HTML. Для таких случаев нужен клиентский guard, динамический импорт или полифил, безопасный для серверной среды.

Плохой пример, если вы обещаете поддержку браузеров без fetch:

async function loadProfile() {
  const response = await fetch("/api/profile");
  return response.json();
}

Такой сценарий может сломаться в среде, где нет fetch или Promise. Без fetch вызов упадет в рантайме, а без Promise может не работать код вокруг async и await. В интерфейсе это выглядит как пустой профиль, вечный loading или ошибка до того, как пользователь увидит понятное сообщение.

Безопаснее добавить проверенный полифил до старта приложения или вынести запросы в клиентскую обертку, которая умеет показать fallback для неподдерживаемой среды. При этом полифил не заменяет обработку сетевых ошибок. Все равно нужно проверять статус ответа и показывать loading, error и empty state.

На интервью полезно сказать не только, что вы подключите fetch polyfill. Добавьте, что проверите, какие еще зависимости нужны, например Promise, и протестируете критичный сценарий в целевом браузере.

Полифилы стоят денег в производительности. Браузер должен скачать, распарсить и выполнить дополнительный JavaScript. На слабых устройствах это заметно влияет на первый экран и интерактивность.

Есть и поведенческий риск. Нативная реализация браузера может быть быстрее и точнее, а полифил может покрывать только часть стандарта. Поэтому для сложных API лучше читать документацию пакета и не обещать, что все edge cases будут работать как в современном браузере.

На собеседовании отвечайте в три шага. Сначала дайте определение: полифил добавляет отсутствующий стандартный API. Затем отделите его от транспиляции: синтаксис и runtime это разные проблемы. После этого покажите практику: подключать нужно только под реальные целевые браузеры и с проверкой размера бандла.

Такой ответ лучше простого перечисления core-js и fetch, потому что показывает инженерное решение. Вы не просто знаете термин, а понимаете, как он влияет на пользователей, сборку и поддержку проекта.