Что такое фреймворк

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

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

Короткая формулировка для интервью:

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

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

Пример с UI:

// Библиотечный стиль: я сам решаю, где и когда вызвать функцию
const formatted = formatPrice(1990);

// Фреймворковый стиль: я описываю страницу, а инструмент сам подключает ее к роутингу
export default function ProductPage() {
  return <h1>Product</h1>;
}

Во втором случае важен не сам синтаксис компонента. Важно, что вокруг него есть правила: где файл лежит, как он становится маршрутом, когда рендерится, как попадает в бандл и какие ограничения есть у окружения.

Практический риск появляется, когда эти правила игнорируют. Например, код с window или localStorage в месте, которое рендерится на сервере, может упасть на SSR или дать hydration mismatch. Безопаснее вынести такую логику в клиентский эффект, проверить наличие браузерного API и заранее продумать fallback для первого рендера.

Хороший ответ не обязан перечислять все инструменты. Достаточно показать границы ответственности.

Angular обычно приводят как пример полноценного frontend-фреймворка: он задает структуру приложения, DI, шаблоны, роутинг, формы и сильные соглашения. Next.js можно назвать фреймворком поверх React, потому что он добавляет роутинг, SSR, SSG, загрузку данных, сборку и правила проекта. React сам по себе аккуратнее назвать библиотекой для построения UI, хотя в разговорной речи его иногда называют фреймворком.

Такая оговорка звучит сильнее, чем спор о том, React фреймворк или нет. Вы показываете, что понимаете уровни: UI-библиотека, фреймворк приложения, метафреймворк, сборщик, набор утилит.

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

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

Во frontend выбор особенно влияет на UX после ошибки. Если фреймворк предлагает свой способ загрузки данных, важно понимать, где показывать loading, error и empty state, как отменять устаревшие запросы и где чистить подписки. Иначе можно получить лишние запросы, гонку ответов или состояние, которое уже не соответствует текущему экрану.

На интервью не стоит отвечать только определением из учебника. Лучше дать трехчастный ответ:

1. Что это: каркас, правила, готовые механизмы.
2. Как это работает: фреймворк управляет частью потока и вызывает ваш код в своих точках расширения.
3. Какой trade-off: быстрее старт и единые соглашения, но больше ограничений, зависимость от экосистемы и риск избыточности.
4. Что делать на практике: читать правила фреймворка для рендеринга, запросов, cleanup, безопасности внешних данных и доступной навигации.

Если хотите добавить пример, выбирайте frontend-пример, а не случайный backend-инструмент. Например: в Next.js вы кладете файл страницы в определенное место, а фреймворк сам превращает его в route, настраивает сборку и выбирает режим рендеринга. Это сразу показывает практический смысл.