Что использовали раньше до появления Promise в JavaScript

Короткий ответ: до Promise основой были callback-функции. Функция запускала асинхронную работу, а результат отдавала не через return, а через вызов переданной функции.

loadUser(userId, function (err, user) {
  if (err) {
    showError(err);
    return;
  }

  renderUser(user);
});

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

Хороший ответ не должен звучать как простое перечисление: раньше были колбэки, потом стало лучше. Лучше покажите эволюцию:

• callback-функции были базовым способом получить результат позже;
• для ошибок часто использовали соглашение err первым аргументом;
• для событийных потоков применяли EventEmitter и похожие API;
• для управления несколькими callback-задачами брали библиотеки вроде Async.js;
• в браузерном legacy-коде встречались jQuery Deferred и похожие модели.

Практический вывод: Promise не изобрел асинхронность. Он стандартизировал способ представить будущий результат, строить цепочки и понятнее обрабатывать ошибки.

Самая известная проблема называлась callback hell или pyramid of doom. Это ситуация, когда шаги вложены друг в друга. Каждый новый шаг увеличивает отступ, а вместе с ним сложность чтения.

Плохой пример. Так лучше не писать в новом коде:

loadUser(userId, function (err, user) {
  if (err) return showError(err);

  loadOrders(user.id, function (err, orders) {
    if (err) return showError(err);

    loadRecommendations(orders, function (err, recommendations) {
      if (err) return showError(err);

      renderPage(user, orders, recommendations);
    });
  });
});

Что здесь ломается на практике: обработка ошибок повторяется, код сложно тестировать, трудно добавить отмену, таймаут или промежуточное состояние загрузки. В UI это часто приводит к неочевидным багам. Старый запрос может перерисовать экран после нового, кнопка может навсегда остаться в состоянии loading, а ошибка может потеряться между уровнями вложенности.

Безопаснее разнести шаги на небольшие функции, вернуть из них Promise и в месте вызова держать один путь для loading, error и успешного состояния. В React дополнительно проверяйте отмену запроса или актуальность ответа в useEffect. Так вы не обновите состояние после размонтирования или после более нового запроса.

До широкого использования Promise разработчики не всегда писали всю вложенность вручную. Библиотеки вроде Async.js давали готовые функции для последовательного и параллельного запуска задач. Это помогало не показать UI раньше нужных данных и не запускать зависимый запрос слишком рано. Но базовый факт не менялся: под капотом оставался callback-контракт.

EventEmitter решал другую задачу. Он хорошо подходил не для одного результата, а для серии событий: данные пришли, поток закрылся, произошла ошибка. На интервью стоит сказать, что event-based API и callback API похожи тем, что оба вызывают функции позже. Но модель у них разная.

В старом frontend-коде часто встречался jQuery Deferred. Он позволял подписываться на завершение асинхронной операции и строить цепочки обработчиков. По смыслу он близок к Promise, но исторически появился до полной стандартизации. В старых версиях он не всегда вел себя как нативный Promise.

Безопасная формулировка для интервью: были Deferred-объекты, например в jQuery. Они решали похожую задачу, но не были тем же самым стандартным Promise-контрактом. Поэтому при миграции legacy-кода их поведение нужно проверять.

Если вас спрашивают про прошлые подходы, обычно ждут не учебник истории, а понимание, зачем Promise стали полезны. Promise дал объект, который можно вернуть из функции, передать дальше и связать с другими операциями через then, catch и позже через async/await.

Пример безопасной миграции callback API:

function loadUserPromise(userId) {
  return new Promise((resolve, reject) => {
    loadUser(userId, function (err, user) {
      if (err) {
        reject(err);
        return;
      }

      resolve(user);
    });
  });
}

Так старый API получает более удобный внешний контракт. Но важно вызвать либо resolve, либо reject, не дергать их повторно из разных веток и не проглотить ошибку. Если этот код используется для запроса с экрана, рядом все равно нужна защита от устаревшего ответа: например AbortController для fetch или флаг актуальности в cleanup эффекта.

На интервью можно ответить так:

До Promise чаще использовали callback-функции. Асинхронная операция принимала функцию-обработчик и вызывала ее с результатом или ошибкой. В Node.js был распространен error-first callback. Для событийных сценариев использовали EventEmitter, а для управления несколькими задачами брали библиотеки вроде Async.js. В браузерном legacy-коде встречался jQuery Deferred. Главная проблема старого подхода была не в callback как таковом, а в сложной композиции: вложенность, повторяющаяся обработка ошибок и риск потерять состояние. Promise стандартизировал будущий результат и сделал цепочки и ошибки понятнее.

Эту формулировку можно сократить до 3-4 предложений, если интервью идет быстро. Главное не забыть практический смысл: Promise появился как ответ на реальные проблемы поддержки асинхронного кода. Для frontend это значит меньше риска потерять ошибку, оставить вечный loading, выполнить лишний запрос или обновить экран устаревшими данными.