Среда выполнения кода

Среда выполнения кода

Технический фундамент выбора runtime

Инженерное правило простое: сначала определи среду, потом проектируй решение.

• браузерный код ориентирован на UI, события и DOM;
• серверный код — на обработку данных, API и инфраструктуру;
• одинаковый синтаксис JS не гарантирует одинаковый набор API;
• проверка контекста до реализации дешевле, чем отладка после релиза.

Это снижает класс ошибок "код корректный, но выполняется не там".

Почему среда выполнения — часть архитектуры

Когда пишешь код, важно понимать не только "что он делает", но и "где он должен жить". Ошибка в выборе среды часто приводит к багам, которые сложно отловить по тексту программы: синтаксис может быть идеальным, а контекст — неверным.

Ключевой момент: один и тот же JavaScript-код может быть валидным, но бессмысленным в неправильном runtime.

Проверь себя: почему вызов API вроде document в Node.js — это не "мелкая ошибка", а сигнал, что логика оказалась не там?

Что такое runtime простыми словами

Runtime — это окружение, где работает JavaScript и где доступны дополнительные API. Браузер дает window, document, работу с DOM. Node.js дает файловую систему, серверные модули и другой набор API.

const runtime = 'browser';
const api = runtime === 'browser' ? 'document' : 'fs';

console.log('Текущий runtime:', runtime);
console.log('Типичный API:', api);

Практическая логика выбора среды

Сценарий «обновить интерфейс» почти всегда должен жить в браузере. Сценарий «сохранить прогресс в хранилище» обычно идет на сервер. Разделение по ответственности уменьшает хаос в коде.

function chooseRuntime(taskType) {
  if (taskType === 'ui-update') return 'browser';
  if (taskType === 'save-progress') return 'node';
  return 'review';
}

console.log(chooseRuntime('ui-update'));
console.log(chooseRuntime('save-progress'));

Проверь себя: что вернет функция для taskType = 'send-email' и почему это полезно на старте?

Глобальные объекты среды: быстрый ориентир

Полезно помнить минимум:

• браузер: window, document
• Node.js: global, process

function detectRuntime() {
  if (typeof window !== 'undefined') return 'browser';
  if (typeof process !== 'undefined') return 'node';
  return 'unknown';
}

console.log(detectRuntime());

Это не универсальная магия (в разных окружениях могут быть полифиллы), но хороший beginner-паттерн для осознанной проверки контекста.

Частые ошибки новичков

Одна из самых частых ошибок — перенести паттерн из браузера на сервер (или наоборот) без проверки доступности API.

const runtime = 'node';
const needsDom = true;

const canRun = runtime === 'browser' || !needsDom;
console.log(canRun ? 'OK' : 'Ошибка контекста');

Если задача требует DOM, а runtime — node, это архитектурная ошибка, а не «мелкий баг».

Анти-провал: прежде чем "чинить ошибку", зафиксируй, в каком окружении этот код действительно запускается.

Что будет, если изменить входные данные

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

function needsFallback(runtime, hasApi) {
  if (runtime === 'browser' && !hasApi) {
    return 'add-fallback';
  }
  return 'run-main-flow';
}

console.log(needsFallback('browser', false));

Проверь себя: что вернет функция для needsFallback('node', false) и почему?

Анти-провал: не вызывай API "напрямую", пока не проверил, что оно реально доступно в текущем runtime.

Краткий итог

• Runtime определяет набор доступных API поверх языка JavaScript.
• Выбор среды — архитектурное решение: UI-логика обычно в браузере, серверные сценарии — в Node.js.
• Один и тот же синтаксис не гарантирует одинаковое поведение в разных окружениях.
• Явная проверка контекста дешевле, чем отладка багов после релиза.
• Прод-окружение может отличаться от локального, поэтому полезны проверки и fallback-логика.