Веб-платформа и API
Поверх языка браузер даёт набор платформенных API для общения с внешним миром: сеть (XMLHttpRequest, fetch), хранилище (localStorage, IndexedDB), фоновые потоки (web workers, service workers) и каналы связи между контекстами (postMessage, server-sent events). Это тот слой, где пишется большая часть «настоящего» кода приложения.
Сквозная идея темы — асинхронность и изоляция. Почти каждый из этих API либо не блокирует главный поток (промисы, события, транзакции), либо выносит работу за его пределы (воркеры). Понимание того, кто кого не блокирует и кто с кем как обменивается данными, важнее знания сигнатур. Каждый слой ниже раскрывает один API.
Карта темы
- AJAX и XMLHttpRequest — классический API запросов,
readyState, коллбэки и почему его вытеснилfetch. - Fetch API — промис-ориентированные запросы,
Response, почемуfetchне падает на 404 и как его отменить. - Клиентское хранилище — web storage против IndexedDB, синхронное строковое против асинхронного транзакционного.
- postMessage — безопасный обмен между окнами и iframe поверх политики одного источника.
- Service workers — сетевой прокси, жизненный цикл, кэш и офлайн, основа PWA.
- Worker threads — фоновые потоки, передача сообщений и Transferable-объекты.
- Server-sent events — односторонний серверный push через
EventSourceи его отличие от WebSocket.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
Ждать, что fetch отклонит промис на 404 | fetch реджектится только на сетевой сбой; 404/500 — это успешный resolve, проверяйте response.ok |
Думать, что fetch(url) вернёт данные | Он резолвится в Response по приходу заголовков; тело читают отдельным .json()/.text() |
Хранить крупные структурированные данные в localStorage | Web storage синхронный, только строки и ~5 МБ; для этого есть асинхронный IndexedDB |
Не проверять event.origin в message | Любая страница может слать вам сообщения — это XSS-канал |
| Держать состояние в глобалах service worker | Воркер убивается по простою и рестартится; состояние — в IndexedDB или кэше |
| Путать service worker и обычный worker | Первый — сетевой прокси на уровне origin; второй — фоновый счётчик для CPU-работы |
| Выбирать WebSocket там, где хватило бы SSE | Для одностороннего серверного push SSE проще и авто-переподключается сам |
Значение для собеседований
Веб-платформенные API спрашивают, чтобы понять, писали ли вы реальные приложения, а не только учебные примеры. Кандидат, который помнит, что fetch не реджектится на 404 и что service worker терпит убийство по простою, явно сталкивался с этим на практике.
Что обычно проверяют:
- Чем
fetchлучше XHR и в чём его две ловушки — не-реджект на HTTP-ошибке и отдельное чтение тела. - Разницу web storage и IndexedDB по синхронности, размеру и типам данных.
- Зачем проверять
event.originвpostMessage. - Жизненный цикл service worker и как он даёт офлайн.
- Когда достаточно SSE, а когда нужен WebSocket.
Типичный неверный ответ: «если сервер вернул 404, fetch бросит ошибку в catch». На деле промис fetch резолвится и на 404, и на 500 — ошибкой считается только сетевой сбой, а статус вы обязаны проверить сами через response.ok.