Основы веба
Эта тема — не про один API, а про широкий контекст, в котором живёт фронтенд-код. Хороший инженер понимает не только свой JavaScript, но и платформу вокруг: как браузер превращает разметку в пиксели, по какому протоколу летят данные, почему одну картинку отдают в JPEG, а другую в PNG, что делает интерфейс доступным и как проверить компонент так, чтобы поймать регрессию.
Каждый слой здесь — самостоятельная область, которую спрашивают на собеседовании отдельным блоком вопросов, и почти каждая сводится к инженерному компромиссу: скорость против надёжности (TCP/UDP), размер против качества (форматы), скорость теста против его полноты (snapshot/screenshot). Полная карта — ниже.
Карта темы
- Устройство веб-платформы — браузер как среда исполнения, разделение HTML/CSS/JS, конвейер рендеринга и семантическая разметка.
- Сетевые протоколы — HTTP и WebSocket поверх TCP, разница TCP и UDP по надёжности и накладным расходам.
- Форматы изображений — JPEG против PNG, прозрачность и потери, современные WebP/AVIF и векторный SVG.
- Доступность — управление с клавиатуры, семантика и ARIA, управление фокусом, контраст и проверка.
- Headless UI-киты — библиотеки, дающие поведение и доступность без навязанных стилей и разметки.
- Тестирование компонентов — snapshot против screenshot, что каждый ловит и где его предел.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Считать, что HTTP работает поверх UDP | HTTP — поверх TCP; UDP используют видео, игры, DNS |
| Менять местами роли надёжности TCP и UDP | TCP — надёжный и упорядоченный; UDP — без гарантий, но с малыми накладными |
| Называть WebSocket «запрос/ответ» | WebSocket — полнодуплексное постоянное соединение |
| Думать, что JPEG поддерживает прозрачность | Прозрачность даёт PNG (и WebP/AVIF), а не JPEG |
| Считать PNG форматом с потерями или лимитом 256 цветов | Это описание GIF; PNG — без потерь, полноцветный |
Полагать, что aria-label на всём решает доступность | Сначала семантический HTML, клавиатура, фокус, контраст |
| Верить, что автоаудит доказывает доступность | Автоматика ловит лишь часть; нужны клавиатура и скринридер |
Убирать фокус через outline: none без замены | Клавиатурные пользователи теряют видимый фокус |
| Думать, что headless-кит навязывает стили | Наоборот — он даёт поведение и a11y, стили ваши |
| Ждать, что snapshot-тест поймает CSS-регрессию | Snapshot слеп к визуалу; для этого нужен screenshot |
Значение для собеседований
Эти вопросы отделяют инженера с широким кругозором от узкого «кодера». Ответ здесь — почти всегда компромисс, и сильный кандидат называет обе стороны: «PNG без потерь и с прозрачностью, но тяжёлый; JPEG лёгкий, но с потерями и без альфа-канала — поэтому фото в JPEG, логотипы в PNG».
Что обычно проверяют:
- Слой протокола: HTTP/WebSocket поверх TCP, разница TCP и UDP.
- Выбор формата картинки под задачу и почему WebP/AVIF выигрывают.
- Что делает интерфейс доступным и что автоматика этого не доказывает.
- Что такое headless-библиотека и зачем переиспользовать её a11y-логику.
- Чем snapshot-тест отличается от screenshot и где предел каждого.
Типичный неверный ответ: «доступность — это добавить aria-label каждому элементу, и скринридеры заработают». На деле избыток ARIA поверх несемантической разметки чаще вредит; начинают с нативных элементов, клавиатурной управляемости, управления фокусом и контраста, а ARIA добавляют точечно.