Для тех, кто держит workspace на десятки пакетов, это ускорение pnpm install без изменений в конфигурации. Для пользователей Windows это ещё и конец .cmd и .ps1-обёрток: их заменяет .exe. Обратная сторона видна по патчу 12.3.1: обновление с 12.2 через self-update ломало миграцию старых shim, и это исправили в тот же день.

• Установка в больших workspace ускорена: lockfile читается во время discovery проектов, граф workspace обрабатывается один раз вместо полного копирования lockfile.
• Контекстно-зависимые глобальные команды и shim стали нативными исполняемыми файлами; в Windows .exe вместо .cmd и .ps1, старые shim мигрируют при следующей глобальной установке или self-update.
• Флаги доверия --trust-lockfile, --no-trust-lockfile, --trust-policy, --trust-policy-exclude и --trust-policy-ignore-after теперь работают и для remove и update.
• Исправлено зависание recursive run и exec, в том числе с --filter и --workspace-concurrency=1.
• Системный резолвер на Linux использует getaddrinfo и больше не должен молча обращаться к Google Public DNS при неподдерживаемой опции no_tld_query.

Откуда взялось ускорение в монорепозиториях

По заметкам к релизу, раньше pnpm сначала обходил все проекты workspace, а потом отдельно разбирал lockfile и копировал его целиком для резолвера. В 12.3 lockfile читается уже на этапе discovery, а граф workspace строится один раз и передаётся резолверу и генератору lockfile без полного копирования. Конкретных цифр ускорения команда pnpm в заметках не приводит, формулировка звучит как «sped up installs in large workspaces»; эффект тем заметнее, чем больше пакетов и чем толще lockfile.

Что изменилось для глобальных команд и Windows

pnpm умеет ставить node, deno и bun как глобальные команды, которые подбирают версию по контексту проекта. До 12.3 в Windows такие команды были скриптами .cmd и .ps1, а на других платформах shell-обёртками. Теперь везде это нативные исполняемые файлы. Старые shim от pnpm 12 мигрируют при следующей глобальной установке или self-update; именно этот переход и сломался при обновлении с 12.2, что исправили в 12.3.1: нативный shim теперь мигрирует при первом запуске.

Безопасность: trust-флаги и скрытие секретов

Механизм доверия к lockfile появился в pnpm 12 как защита от атак на цепочку поставок: пакеты, не прошедшие политику доверия, не ставятся. В 12.2 флаги были только у install и add; 12.3 добавляет их к remove и update. Второе изменение того же ряда: учётные данные и query-параметры из URL реестров теперь скрываются в сообщениях об ошибках fetch и загрузки tarball, так что токен приватного реестра больше не утекает в лог CI при обрыве соединения.

Исправления, которые стоит знать

• Добавление локальных директорий, tarball-файлов и tarball по URL через pnpm add снова работает.
• recursive run и recursive exec больше не зависают, включая варианты с --filter и --workspace-concurrency=1.
• Дочерние процессы в Windows запускаются корректно.
• Linux: системный резолвер переведён на getaddrinfo; при неподдерживаемой опции no_tld_query в resolv.conf pnpm больше не должен молча уходить к Google Public DNS, что важно в закрытых сетях и там, где внешние DNS фильтруются.
• 12.3.1: исправлены обработка workspace anchor и параллельная проверка lockfile.

Как обновиться

Обновляться стоит сразу на 12.3.1, минуя 12.3.0. Если pnpm установлен через Corepack или npm i -g pnpm, обновление идёт обычным способом; если через self-update, после перехода с 12.2 стоит один раз запустить любую глобальную команду, чтобы shim мигрировал. Проверить, что всё на месте: pnpm --version должен показать 12.3.1, а pnpm shim ls (если пользуетесь shim) не должен ругаться на старые обёртки.

Кому обновление ничего не изменит: одиночным проектам без workspace и тем, кто не пользуется глобальными командами pnpm. Из соседних новостей про инструменты JavaScript на сайте: GitHub CLI 2.99 и Wasmi 2.0. Полный список изменений с номерами issue лежит на странице релиза.

Источники: pnpm v12.3.0 на GitHub, pnpm v12.3.1 на GitHub

Изображение на обложке: pnpm, логотип проекта

Я разбираю WebLLM как рабочий инструмент: что нужно от железа и браузера, сколько весят модели, какой скоростью придётся заплатить за отказ от сервера и где проще остаться на облачном API. Все команды и фрагменты кода взяты из README репозитория, цифры производительности из статьи авторов на arXiv, требования к видеопамяти из файла конфигурации в исходниках.

Материал для фронтенд- и фулстек-разработчиков, которым нужен чат, классификатор или JSON-извлекатель на клиенте без счёта за токены и без передачи пользовательских данных третьей стороне.

• WebLLM выполняет модель в браузере на WebGPU, без сервера; API совместим с OpenAI Chat Completions: стриминг, JSON-режим, seed. Вызов функций помечен в README как незавершённый.
• Актуальная версия пакета @mlc-ai/web-llm — 0.2.84 от 27 мая 2026 года; в 2025–2026 годах вышло всего 7 релизов против 63 за 2024 год по данным реестра npm.
• По замерам авторов на MacBook Pro M3 Max WebLLM выдаёт 41,1 токена/с на Llama-3.1-8B и 71,1 токена/с на Phi-3.5-mini, то есть 71–80% от нативного MLC-LLM на том же железе.
• Модели в 4-битной квантизации требуют от 0,7 ГБ видеопамяти (gemma3-1b) до 6,4 ГБ (Qwen3.5-9B) по значениям vram_required_MB в src/config.ts; первый запуск качает всё это с huggingface.co.
• WebGPU по данным MDN есть в Chrome и Edge с версии 113, в Safari 26 с сентября 2025 года, в Firefox с 141 только частично: Linux и Intel-маки не поддерживаются.

Как WebLLM выполняет модель в браузере и при чём тут WebGPU?

Модель считается на видеокарте пользователя через WebGPU, а всё, что не ложится на GPU, крутится в WebAssembly. Авторы описывают схему так: родственный проект MLC LLM компилирует открытую модель заранее в два артефакта, конвертированные веса и WASM-библиотеку с WebGPU-ядрами и вспомогательными функциями. WebLLM в браузере загружает оба артефакта с хостинга, инициализирует WebGPU-устройство и дальше исполняет граф вычислений локально.

Everything runs inside the browser with no server support and is accelerated with WebGPU.

Отсюда же и главное ограничение, о котором в статье авторы говорят прямо: в отличие от CUDA у WebGPU нет готовых ускоренных библиотек для типовых ядер, поэтому матричные умножения и внимание команде пришлось писать и оптимизировать самой. Цена этого видна в замерах: на Apple MacBook Pro M3 Max в Chrome Canary 133 WebLLM версии 0.2.75 выдавал 41,1 токена/с на 4-битной Llama-3.1-8B против 57,7 у нативного MLC-LLM с Metal-ядрами на той же машине, и 71,1 против 89,3 токена/с на Phi-3.5-mini. Это 71,2% и 79,6% нативной скорости соответственно, замер вендора, другого железа в статье нет.

Второй компонент, о котором обычно забывают, это кэш. Веса и WASM-библиотека скачиваются при первом обращении и складываются в хранилище браузера. README перечисляет четыре бэкенда, которые задаются полем cacheBackend в AppConfig: Cache API по умолчанию, IndexedDB, Origin Private File System и экспериментальный cross-origin через расширение Chrome, чтобы одни и те же веса не качались заново для каждого сайта. Без расширения движок сам откатывается на Cache API.

JSON-режим, который в серверных API обычно реализован на стороне провайдера, здесь тоже выполняется локально: по README структурированная генерация встроена в WebAssembly-часть библиотеки модели, а попробовать её со своей JSON-схемой можно в JSON Playground на Hugging Face. Про то, как WASM-рантаймы догоняют нативный код, мы писали в заметке про Wasmi 2.0.

Что нужно, чтобы запустить первый чат?

Достаточно npm-пакета, одного вызова фабрики и терпения на первую загрузку весов. README даёт три варианта установки и импорт через CDN для JSFiddle и CodePen без сборщика.

Движок создаётся функцией CreateMLCEngine: это асинхронная фабрика: она возвращает Promise, а готовый движок с загруженной моделью получают через await. Колбэк прогресса обязателен на практике, потому что без него пользователь смотрит на пустой экран, пока качаются гигабайты.

loading models requires downloading and it can take a significant amount of time for the very first run without caching previously

Дальше интерфейс тот же, что у клиента OpenAI: engine.chat.completions.create({ messages }). Одна ловушка: параметр model в запросе игнорируется, модель выбирается при создании движка или через engine.reload(model). Стриминг включается флагом stream: true, а статистика по токенам приходит только в последнем чанке, если попросить её через stream_options.

Готовый чат для проверки железа не нужно собирать самому: WebLLM Chat сделан на том же пакете, а его код открыт в отдельном репозитории.

Какие модели доступны и сколько видеопамяти им нужно?

В список prebuiltAppConfig.model_list в src/config.ts на 3 сентября входят 165 записей: это варианты квантизации и длины контекста для семейств Llama 3.x, Qwen 2.5, Qwen 3 и Qwen 3.5, Phi 3.5 и Phi 4 mini, Gemma 2 и Gemma 3, Mistral и Ministral 3, дистилляты DeepSeek-R1, SmolLM2, OLMo 2, а также две модели эмбеддингов snowflake-arctic-embed. README при этом всё ещё перечисляет старый набор с Llama 2 и Qwen2, так что актуальный набор виден только в коде.

У каждой записи есть поле vram_required_MB, и это честнее любого «весит N гигабайт»: оно включает не только веса, но и память под KV-кэш при заданном контексте. Для 4-битных вариантов с половинной точностью (суффикс q4f16_1) разброс такой:

• gemma3-1b-it — 0,71 ГБ; Llama-3.2-1B-Instruct — 0,88 ГБ; Qwen2.5-0.5B-Instruct — 0,94 ГБ. Помечены флагом low_resource_required, это кандидаты для встроенной графики и ноутбуков.
• Qwen3-0.6B — 1,40 ГБ; gemma-2-2b-it — 1,90 ГБ; Llama-3.2-3B-Instruct — 2,26 ГБ.
• Qwen3-4B — 3,43 ГБ; Phi-3.5-mini-instruct — 3,67 ГБ; Llama-3.1-8B-Instruct — 5,00 ГБ; Qwen3-8B — 5,70 ГБ; Qwen3.5-9B — 6,43 ГБ.
• Есть и Llama-3.1-70B-Instruct в 3-битной квантизации с требованием 31,15 ГБ; на потребительской видеокарте это не запустится.

Варианты с суффиксом «-1k» урезают контекст до одной тысячи токенов и экономят память: у Llama-3.1-8B это 4,60 ГБ вместо 5,00, у Phi-3.5-mini 2,52 ГБ вместо 3,67. Все эти гигабайты приезжают с huggingface.co/mlc-ai, поэтому доступность и скорость этого хоста в вашей сети стоит проверить до того, как обещать пользователям «работает без сервера». Свою модель в формате MLC подключают через appConfig.model_list, указав URL весов и WASM-библиотеки. Какие небольшие открытые модели вышли в августе и на чём их запускать дома, мы собирали в обзоре открытых нейросетей.

Полный каталог собранных моделей лежит на mlc.ai/models. Номер совместимой сборки библиотек зашит в пакет: для 0.2.84 это константа modelVersion со значением «v0_2_84/base», так что после обновления npm-пакета кэшированные WASM-библиотеки могут потребовать перезагрузки.

Как не заморозить интерфейс: Web Worker или Service Worker?

Для обычного приложения хватает выделенного Web Worker, а Service Worker нужен, когда модель должна переживать переходы между страницами. Оба варианта в README оформлены одинаково: в потоке живёт обработчик, в основном скрипте создаётся движок-прокси с тем же интерфейсом MLCEngineInterface.

С Service Worker сложнее. Его жизненным циклом управляет браузер и может убить поток без предупреждения; движок шлёт heartbeat каждые 10 секунд по умолчанию (значение keepAliveMs в src/service_worker.ts), но авторы просят закладывать обработку ошибок и в приложении. README отдельно требует создавать ServiceWorkerMLCEngineHandler на верхнем уровне скрипта и запрещает делать это внутри обработчиков activate или message: браузер перезапускает уже активный воркер без повторного события activate.

Service Worker's life cycle is managed by the browser and can be killed any time without notifying the webapp. ServiceWorkerMLCEngine will try to keep the service worker thread alive by periodically sending heartbeat events, but your application should also include proper error handling.

Отдельная ветка применения — расширения Chrome: в репозитории есть примеры базового расширения и расширения на Service Worker с WebGPU, которое держит модель в фоне. По данным MDN, в Firefox WebGPU недоступен именно в контексте Service Worker, так что этот сценарий пока привязан к Chromium.

Где WebLLM выигрывает у серверного API, а где проигрывает?

Выигрывает там, где важны приватность промптов и нулевая стоимость токена, проигрывает там, где нельзя выбирать пользователю железо. Разложу по пунктам, отделяя проверяемое от обещаний.

• Деньги. Инференс идёт на GPU пользователя, счёт за токены равен нулю. Платите трафиком: каждый новый пользователь качает от 0,7 до 6,4 ГБ весов с Hugging Face; свой CDN нужен только тем, кто перехостит артефакты сам.
• Приватность. Промпты и ответы на сервер не уходят, это следует из архитектуры. Но сетевые запросы есть: веса и WASM скачиваются с huggingface.co и jsdelivr, поэтому формулировка «данные никогда не покидают устройство» некорректна, и в политике приватности так писать нельзя.
• Скорость. 71–80% от нативного инференса по замеру авторов на M3 Max. На ноутбуке с встроенной графикой цифр в статье нет, и обещать «десятки токенов в секунду» без своего замера нельзя.
• Первый запуск. Минуты загрузки против миллисекунд первого ответа у API. Кэш спасает повторные визиты, но не первый.
• Браузеры. По данным MDN, WebGPU есть в Chrome и Edge с версии 113 (полная поддержка на Linux только с 144 и только на Intel Gen12 и новее), в Safari 26 на macOS и iOS с 15 сентября 2025 года, в Firefox с 141 частично: есть Windows и Apple Silicon, нет Linux и Intel-маков. Проверка navigator.gpu обязательна.
• Управление моделью. Серверный API даёт одну версию модели для всех и мгновенную замену. В WebLLM версия модели живёт в кэше каждого браузера, а обновление пакета может потребовать перекачки библиотек.
• Функции. Вызов инструментов через tools и tool_choice в README помечен как WIP с предварительной поддержкой. Для агентских сценариев это стоп-фактор; про выбор стека для агентов у нас есть отдельный разбор.

Есть и организационный риск. По реестру npm пакет обновлялся 19 раз в 2023 году, 63 раза в 2024-м, 3 раза в 2025-м и 4 раза с начала 2026 года; последний релиз 0.2.84 вышел 27 мая. Код в репозитории при этом продолжает меняться, последний push был 3 сентября. Для продакшена это означает, что свежие модели из config.ts могут ждать релиза месяцами.

Evaluations show that WebLLM can retain up to 80% native performance on the same device with room to close the gap further.

Что делать по шагам, чтобы собрать чат на WebLLM за вечер

План ниже покрывает путь от проверки железа до защиты артефактов; команды и имена функций взяты из README для версии 0.2.84.

1. Проверьте, что в браузере есть navigator.gpu, и покажите понятную заглушку тем, у кого его нет. По MDN это Chrome и Edge 113+, Safari 26+, Firefox 141+ с оговорками по ОС.
2. Установите пакет: npm install @mlc-ai/web-llm (версия 0.2.84). Для прототипа без сборки подойдёт импорт с https://esm.run/@mlc-ai/web-llm.
3. Выберите модель из prebuiltAppConfig.model_list по полю vram_required_MB. Для широкой аудитории начните с моделей с флагом low_resource_required: Llama-3.2-1B, Qwen2.5-0.5B, gemma3-1b.
4. Создайте движок через CreateMLCEngine с initProgressCallback и выведите прогресс загрузки на экран.
5. Перенесите инференс в Web Worker через CreateWebWorkerMLCEngine, чтобы интерфейс не замирал во время генерации.
6. Включите стриминг флагом stream: true; для извлечения структурированных данных используйте JSON-режим из раздела Full OpenAI Compatibility.
7. Если артефакты лежат на своём хостинге, добавьте в запись модели поле integrity с SRI-хэшами для конфига, WASM и токенизатора; хэш генерируется командой openssl из README.

При несовпадении хэша движок бросает IntegrityError, либо пишет предупреждение и продолжает работу, если задать onFailure: "warn". Без поля integrity проверка не выполняется вовсе, как и в прежних версиях.

Что дальше: чего нет в WebLLM и за чем следить

Первое, за чем стоит следить, это релиз после 0.2.84: в src/config.ts уже есть Qwen3.5 и Ministral 3, и вопрос в том, когда они попадут в опубликованный пакет. Второе — статус вызова функций, который держится в README как WIP. Третье — cross-origin хранилище: сейчас это расширение Chrome и экспериментальный API, а без него каждый сайт качает свою копию весов.

Мы не проверяли скорость на встроенной графике и на Windows-ноутбуках; единственные опубликованные цифры относятся к MacBook Pro M3 Max. Доступность huggingface.co и esm.run из конкретной сети мы тоже не измеряли: перед запуском продукта на WebLLM стоит замерить время первой загрузки у своей аудитории или перехостить артефакты.

Источники: GitHub: mlc-ai/web-llm (README, лицензия Apache-2.0), src/config.ts: prebuiltAppConfig.model_list с vram_required_MB, src/service_worker.ts: keepAliveMs и heartbeat, arXiv 2412.15803: WebLLM: A High-Performance In-Browser LLM Inference Engine, Блог MLC: WebLLM, 13 июня 2024, Документация WebLLM, Реестр npm: @mlc-ai/web-llm (версии и даты), Hacker News: обсуждение WebLLM 2 сентября 2026, MDN: WebGPU API, совместимость браузеров, Hugging Face: модели mlc-ai, WebLLM JSON Playground, WebLLM Chat, Каталог моделей MLC, GitHub: mlc-ai/mlc-llm

Изображение на обложке: Скриншот: chat.webllm.ai

Бета обычно доживает до стабильного релиза без крупных изменений, поэтому всё перечисленное стоит проверять уже сейчас: часть новинок меняет поведение существующего кода. Background Fetch начинает применять CORS, а AbortController теперь передаёт причину отмены в Response и ReadableStream. Автор поста в блоге Chrome for Developers Рэйчел Эндрю; отдельных региональных ограничений на бету в источнике нет.

• Web Crypto получил ML-KEM 768 и 1024, ML-DSA 44, 65 и 87, ChaCha20-Poly1305 и гибридную схему X-Wing.
• WebSocket принимает options bag: new WebSocket(url, { protocols: "soap" }); новое поле targetAddressSpace позволяет подключаться к локальным адресам при secure context и разрешении Local Network Access.
• scroll-marker-group получил режимы links и tabs; в режиме tabs активный маркер остаётся единственным tab-stop, а неактивный контент скрывается из дерева доступности.
• CSSStyleValue и связанные конструкторы доступны в воркерах; text-decoration-inset принимает auto, длину, процент и одно-/двухзначную запись; FontFace.width стал алиасом stretch.
• Background Fetch теперь соблюдает CORS; WebGPU получил модификаторы frag_depth less и greater, которые позволяют не терять ранний Z-тест.

Что даёт постквантовая криптография в браузерном API

До сих пор постквантовые алгоритмы в Chrome работали только на уровне TLS, незаметно для страницы. В 154 они выходят в JavaScript: через crypto.subtle можно генерировать ключи и выполнять инкапсуляцию ML-KEM (стандарт NIST для обмена ключами) и подписи ML-DSA. Добавлены также ChaCha20-Poly1305 и X-Wing, гибрид классического X25519 и ML-KEM. На практике это нужно тем, кто делает сквозное шифрование в веб-приложениях: мессенджерам, хранилищам паролей, локальным подписям документов. Проверить у себя просто: вызвать crypto.subtle.generateKey с новым именем алгоритма в бете и убедиться, что он не бросает NotSupportedError.

Зачем WebSocket объект настроек и локальная сеть

Конструктор WebSocket много лет принимал только URL и строку или массив протоколов. Теперь второй аргумент может быть объектом: new WebSocket(url, { protocols: "soap" }). Это задел под будущие опции без ломки сигнатуры. Второе поле, targetAddressSpace, решает конкретную боль: страница с публичного HTTPS-сайта не могла открыть сокет к устройству в локальной сети. В 154 это возможно, но при трёх условиях: secure context, разрешение пользователя по механизму Local Network Access и имя хоста, которое резолвится в локальный IP. Сценарий типичный для панелей управления IoT и локальных серверов разработки.

Что меняется в CSS

Свойство scroll-marker-group, которое вместе с псевдоэлементами ::scroll-marker позволяет делать карусели и табы без JavaScript, получило два режима. links ведёт себя как набор ссылок, tabs как настоящий tablist: активный маркер единственный останавливается по Tab, а контент неактивных вкладок исключается из accessibility tree. Это закрывает главную претензию к CSS-каруселям: раньше скринридер видел все панели сразу.

Из остального: text-decoration-inset позволяет отступать подчёркивание от краёв текста и принимает auto, длину, процент и запись из одного или двух значений; FontFace.width и дескриптор font-width в @font-face стали алиасами stretch и font-stretch; типизированная объектная модель CSS (CSSStyleValue и конструкторы) теперь доступна в воркерах, что упрощает расчёты стилей вне главного потока.

Что может сломаться после обновления

• Background Fetch теперь применяет CORS: фоновые загрузки с чужих доменов без правильных заголовков начнут падать.
• AbortController прокидывает reason в Response и ReadableStream: код, который сравнивал ошибку отмены с конкретным AbortError, может получить другой объект.
• По заметкам к релизу, браузер в ряде сценариев использует события click вместо пары pointerdown/pointerup; обработчики, завязанные на порядок этих событий, стоит перепроверить.
• В WebGPU появились модификаторы frag_depth less и greater: шейдеры, которые пишут глубину, могут вернуть себе ранний Z-тест, но это требует правки WGSL.

Как попробовать

Бета ставится параллельно со стабильным Chrome со страницы загрузки Chrome Beta; анонс сборки опубликован в Chrome Releases; на Android доступна через бета-программу в магазине. Стабильный релиз 154 по обычному графику Chrome выходит примерно через четыре недели после беты, точную дату Google в посте не называет. До этого времени полезно прогнать сайт с включёнными фоновыми загрузками и WebSocket-подключениями к локальным устройствам.

Что происходит в других движках, можно сравнить с недавними релизами: WebKit переписал загрузчик модулей для Safari 27, а Firefox 155 добавил CSS-функцию progress(). Полный список изменений Chrome 154 с примерами кода лежит в блоге Chrome for Developers.

Источники: Chrome for Developers: Chrome 154 beta, Chrome Releases: Chrome Beta for Desktop Update

Изображение на обложке: Google, логотип Chrome

Для разработчика это открытый пример, где агентный конвейер отвечает за весь цикл: сбор геоданных, генерацию моделей, рантайм, автотесты по фотографиям и независимое ревью. В репозитории лежит исходный промпт, база исследования с источником у каждого факта, скрипты генерации и отчёты рецензентов с оценками от 5,5 до 8 из 10, которые авторы не подгоняли под целевую планку. Это можно клонировать, повторить на своём районе или разобрать как образец того, что сегодня получается у агентов в 3D, а что пока нет.

• Сцена: 453 контура зданий из OpenStreetMap, 75 фасадов с описанием, составленным агентами по фотографиям, 11 950 оконных и дверных проёмов, 129 опознанных магазинов с реальными арендаторами 2024–2026 годов.
• Жизнь на улице: 220 пешеходов на навигационном графе из 1398 узлов, 109 машин, автобусы и канатные трамваи по улице Пауэлл, 36 регулируемых перекрёстков.
• Два интерьера, куда можно зайти: Apple Union Square и Nintendo San Francisco, 23 интерактивных объекта.
• Проверка: 34 контрольных точки, где рендер сверяется со снимком с того же места (свободные фотографии есть для 28 из них), 147 листов сравнения, 9 отчётов агентов-рецензентов, 18 из 18 шагов сценарного прохода.
• Производительность в headless Chromium при 1080p: 50–79 кадров в секунду на улице днём, 32 в виде сверху. Ассеты: 206 GLB-файлов на 5,1 МБ.

Что построили

Реконструкция покрывает примерно 800 на 720 метров: саму площадь и кварталы между улицами Мейсон и Грант, Саттер и О'Фаррелл. Рельеф взят из USGS 3DEP (1317 высотных отметок), поэтому Пауэлл-стрит поднимается к Ноб-Хиллу так же, как в жизни. Начало координат привязано к монументу Дьюи, а вся сцена повёрнута на реальный азимут уличной сетки 80,686 градуса, чтобы фасады стояли на своих участках.

Управление обычное для браузерных прогулок: WASD для ходьбы, Shift для бега, E для взаимодействия, Tab для орбитальной камеры, T запускает кинематографический тур, клавиши 1, 2 и 3 переключают день, закат и ночь. Клавиша R накладывает на рендер реальную фотографию с той же точки, чтобы глазами оценить расхождение.

Как это собрано

Авторы подчёркивают, что ничего в сцене не расставлено «на глаз»: всё собирается при загрузке из данных. Конвейер из четырёх стадий описан в README и целиком лежит в репозитории.

1. Разведка. Одиннадцать параллельных исследовательских агентов собрали базу: контуры зданий из OSM, высоты USGS, спецификацию улиц и транспорта (число полос, односторонние направления, положение рельсов канатной дороги), обмер площади, перепись из 122 магазинов, отдельные исследования магазинов Apple и Nintendo и 34 контрольных ракурса. У каждого факта записан источник и уровень уверенности; непроверенное не придумывалось, а помечалось как нерешённое.
2. Офлайн-генерация ассетов. Скрипты на Blender как библиотеке (bpy) выпускают 206 оптимизированных GLB-модулей: окна, карнизы, витрины, маркизы, фонари, светофоры, скамейки, гидранты, машины, пальмы, торговое оборудование, части тел пешеходов. Blender в рантайме не участвует.
3. Рантайм. Приложение на Three.js собирает рельеф, улицы, фасады, реквизит, толпу и трафик из JSON-спецификаций. Фасадный движок превращает описание здания в геометрию: цокольный ярус, шагающий вместе с уклоном тротуара, витрины с реальными арендаторами и вывесками, окна по ритму пролётов, карнизы и парапеты. 75 зданий описаны отдельными спецификациями, остальные выводятся автоматически и берут арендаторов из переписи.
4. Проверка по камере. Playwright гоняет настоящее приложение по 34 ракурсам, снимает скриншоты и кладёт их рядом с фотографиями под свободной лицензией с тех же точек, плюс наложение 50 на 50. Девять независимых агентов-рецензентов (геометрия, семантика, архитектор, местный житель Сан-Франциско, художник по окружению, технический художник, интерактив) пишут отчёты, которые запускают следующий цикл правок.

Пешеходы ходят по навигационному графу из 1398 узлов по тротуарам, переходам и лестницам площади, у них есть роли: пассажир, покупатель, турист, сидящий, переходящий дорогу. Машины двигаются по графу полос по модели IDM и останавливаются на красный; светофоры работают циклом в 60 секунд.

Что показала проверка

Самая полезная часть репозитория для тех, кто оценивает возможности агентов, это итоговый QA-отчёт, сгенерированный 2 сентября. Географическая точность получила 7,5 из 10, узнаваемость зданий 5,5 с оценкой 6,5 после исправления, точность магазинов 6 (размещены 76% названных арендаторов из переписи), интерьер Apple 7, Nintendo 7,5, детализация улицы, материалы и общая узнаваемость по 6, освещение 7, навигация 8, производительность 6. Целевая планка в промпте была 8–9, и авторы прямо пишут, что оценки под неё не подгонялись.

Список открытых расхождений тоже опубликован. Контур универмага Saks в OSM нарисован по границе участка, поэтому тротуар на Пауэлл получился шириной 2,1 метра вместо примерно четырёх. Здание Уиттелл смоделировано высотой 56 метров по OSM вместо 66 по справочникам. У 34 витрин из переписи арендатор не установлен: они отрисованы нейтральной пустой фасцией, а не выдуманы. Есть и исправленные баги с понятной причиной: все стены фасадов были сгенерированы с обратной обмоткой полигонов, и отсечение задних граней прятало их там, где сзади не было панели, из-за чего стены «исчезали», если поднять взгляд.

Замеры производительности сделаны в headless Chromium при 1920 на 1080 через ANGLE и Metal, то есть на Mac. Днём в центре площади 63 кадра в секунду при 2108 вызовах отрисовки и 7,25 млн треугольников; на перекрёстке Пауэлл и Гири 51 кадр, 2646 вызовов и 7,91 млн треугольников; внутри Apple 79 кадров; в виде сверху 32 кадра при 3522 вызовах и 8,52 млн треугольников. Куча JavaScript держится на 290 МБ днём и 242 МБ ночью. Ночной режим дешевле по вызовам отрисовки, но кадров на перекрёстках даёт меньше: 38,5 на Пауэлл и Гири.

Чего в репозитории нет

На вопрос о цене и времени автор публикации на Hacker News под ником surreal_ ответил, что это результат одного прогона по очень длинному промпту с явными указаниями про субагентов и цикл самопроверки: около двух часов работы, примерно 8 млн токенов и около $33 по тарифам API. Сколько было неудачных попыток до этого прогона и вмешивался ли человек по ходу, не уточняется. Кто стоит за PhiloLabs, тоже неизвестно: организация на GitHub создана в феврале 2026 года, без описания и сайта, в ней пять репозиториев. В комментариях автор пишет, что команда уже сгенерировала большинство туристических мест Сан-Франциско и готовит обзорную статью про «моделирование мира через код»; сроков нет.

Разработчик игр в комментариях на HN отметил, что в похожих экспериментах модели выдают неоптимизированную геометрию с избыточным числом полигонов, и что для игровых ассетов он предпочитает просить у модели низкополигональные силуэты. Автор проекта ответил, что при генерации мира кодом геометрия строится из примитивов и параметрических конструкций, поэтому топология чистая по построению, а слабое место скорее текстуры. Числа из QA-отчёта, 7–8 млн треугольников и больше двух тысяч вызовов отрисовки на кадр для одного квартала, по нашей оценке, всё же говорят о заметном запасе для оптимизации.

Что с этим делать

Репозиторий стоит открыть не ради прогулки по Сан-Франциско, а ради конвейера. Файл PROMPT.md показывает, как сформулирована задача на автономную сборку: перечень обязательных объектов с адресами, требование Three.js в рантайме и Blender только офлайн, обязательная сверка с фотографиями на каждой вехе и независимые рецензенты. Папка qa/ пригодится как образец проверки против реальности, а не против самого себя: фиксированные ракурсы по координатам, автоматические сравнения и отчёты, которые прямо называют, где результат ниже планки.

Код и сгенерированные ассеты отданы под MIT, но исходные данные лицензированы отдельно: контуры зданий получены из OpenStreetMap под ODbL, высоты USGS в общественном достоянии, а сами эталонные фотографии в репозитории не распространяются: для каждого сектора сохранена только их атрибуция, чтобы набор можно было скачать заново. Названия и логотипы магазинов, как оговаривают авторы, остаются собственностью их владельцев, так что перед использованием сцены в своём продукте права на товарные знаки нужно проверять отдельно.

Источники: Репозиторий PhiloLabs/fable51-worlds, README мира Union Square, FINAL_QA_REPORT.md, Обсуждение на Hacker News

Изображение на обложке: PhiloLabs, fable51-worlds (MIT)

Для фронтендера это означает, что один из последних поводов не использовать top-level await в продакшене исчезает: в Chrome и Firefox функция работает давно, а Safari оставался браузером, ради которого библиотеки и сборщики держали обходные пути. По словам автора публикации, инженера WebKit Кая Тамкуна, вместе с загрузчиком в порядок приведены ES-модули в целом, так что после релиза Safari 27 на них «можно опираться, не задумываясь».

• Старый загрузчик модулей Safari был написан по черновику WHATWG Loader, последний раз обновлённому в январе 2016 года, ещё до появления async/await в языке.
• Top-level await, добавленный в ECMAScript 2022, реализовали поверх этой устаревшей основы, отсюда ошибки порядка выполнения и обращения к неинициализированным экспортам.
• В январе 2026 года команда удалила старый загрузчик целиком и переписала его на C++ по алгоритмам спецификации ECMAScript, отказавшись от самохостируемого JavaScript.
• Проверка: тест-кейсы от команды Bun, чей рантайм на JavaScriptCore унаследовал те же баги, фаззер графов модулей со сравнением вывода с другими движками, все модульные тесты test262 и исправленные тесты WPT без регрессий.
• Попробовать можно сегодня в Safari Technology Preview 251 или Safari 27 beta; сроки стабильного Safari 27 в публикации не названы.

Что именно ломалось

Top-level await позволяет писать await прямо в теле ES-модуля: модуль приостанавливается до разрешения промиса, и вместе с ним ждут все модули, которые его импортируют, а независимые ветки графа зависимостей продолжают выполняться. В Safari нарушался именно порядок: загрузчик неверно выбирал, когда считать модуль выполненным. WebKit показывает это на минимальном примере, где один и тот же модуль с задержкой на верхнем уровне динамически импортируется три раза подряд.

Ожидаемый порядок завершения импортов 1, 2, 3. Старый загрузчик выдавал 2, 3, 1, причём второй и третий импорт завершались с ошибкой Cannot access 'someArray' before initialization, и только первый печатал список экспортов. Причина одна: когда первый импорт доходил до await и уступал управление, промис второго импорта должен был ждать окончания выполнения модуля, но из-за ошибки разрешался сразу. Код получал ещё не инициализированные экспорты и падал. С новым загрузчиком вывод становится ожидаемым: 1, 2, 3, и каждый раз с корректным списком ключей.

Почему баг не удавалось починить годами

Спецификация ECMAScript оставляет часть механики модулей на усмотрение хоста, в первую очередь загрузку по сети в браузере или с диска в Node.js и Bun. Загрузчик Safari писали в эпоху предложения WHATWG Loader, которое описывало эту хостовую часть и последний раз обновлялось в январе 2016 года. Тогда модули выполнялись строго синхронно, и черновика хватало. Затем предложение фактически умерло, вытесненное разделом о модулях в самом стандарте ECMAScript, а в 2022 году в язык вошёл top-level await. В WebKit его реализовали поверх алгоритмов заброшенного черновика, а не по асинхронным алгоритмам стандарта. Отсюда тонкие ошибки, которые, по словам Тамкуна, команда безуспешно пыталась закрыть несколько раз, пока не решила заменить основание.

Второе решение касается языка реализации. Старый загрузчик был самохостируемым встроенным кодом на JavaScript. У такого подхода есть плюсы: его можно инлайнить в пользовательский код и не платить за переход между JavaScript и C++. Но он медленнее стартует, потому что компилируется во время выполнения, а оптимизирующие JIT-компиляторы JavaScriptCore плохо используют его широкие паттерны применения; загрузчик к тому же не горячий путь, так что выигрыша от компиляции на лету почти нет. Новый загрузчик написан целиком на C++.

Как переписывали и проверяли

Работа началась в январе 2026 года с удаления файла со старым загрузчиком. Дальше команда переводила псевдокод операций из спецификации ECMAScript в C++ по одной, начав с листовых функций вроде ExecuteModule и ModuleRequestsEqual, у которых нет зависимостей, и двигаясь по графу вызовов. Через несколько недель черновая реализация справлялась с типичными случаями, и появился draft pull request.

Тестов было три слоя. Во-первых, инженеры Bun, чей рантайм построен на JavaScriptCore и унаследовал те же проблемы, передали собранные ими случаи неправильного поведения; их адаптировали под консольную оболочку jsc. Во-вторых, команда написала фаззер, который генерирует большие графы модулей, часть с top-level await, часть без, и сравнивает текстовый вывод JavaScriptCore с выводом других движков байт в байт; по словам WebKit, во всех проверенных примерах новый загрузчик отработал верно. В-третьих, все модульные тесты набора test262 стали проходить, а часть ранее падавших тестов WPT исправилась без регрессий. Перед слиянием разработчики несколько недель пользовались сборкой Safari с новым загрузчиком как основным браузером.

Что делать фронтендеру

• Проверить свои модули с top-level await в Safari Technology Preview 251 или Safari 27 beta; о найденных проблемах WebKit просит сообщать на bugs.webkit.org.
• Обходные пути для Safari пока не убирать: стабильный Safari 27 ещё не вышел, а старые версии Safari останутся у пользователей надолго.
• Если проект работает на Bun, следить за обновлениями рантайма: он использует JavaScriptCore и, по словам WebKit, унаследовал те же ошибки загрузчика; о сроках их исправления в Bun публикация не говорит.

Дата выхода стабильного Safari 27 в публикации не названа. Открытым остаётся и вопрос старых версий: о переносе исправления в уже вышедшие Safari WebKit не сообщает, так что доля пользователей на Safari 26 и старше будет определять, когда обходные пути можно убрать совсем.

Источник: WebKit Blog: Fixing Top-Level Await in Safari

Изображение на обложке: Изображение: логотип WebKit, Apple

В тот же день вышел Firefox 155 для десктопа, и для верстальщиков в нём есть чем заняться: CSS-функции progress() и alpha(), свойство font-width, attr() в любом свойстве, а в JavaScript Promise.allKeyed(). Обновиться стоит и без новинок: бюллетень безопасности MFSA 2026-82 закрывает несколько уязвимостей высокого уровня.

• Блокировщик в Firefox для iOS включается в Settings, затем Browsing, затем Ad Blocker; по умолчанию выключен, расширение ставить не нужно.
• Работает на технологии Apple WebKit Content Blocker и списке EasyList; рекламу в поисковой выдаче и рекламу самих сайтов может пропускать.
• Firefox 155: CSS progress(), alpha(), font-width, attr() везде; Promise.allKeyed() и allSettledKeyed(); согласование QUIC v2 для HTTP/3; NDJSON в JSON Viewer.
• MFSA 2026-82 закрывает уязвимости высокого уровня, среди них CVE-2026-84119, 84143 и 84144, и повышение привилегий в Firefox для Android.
• Минимальную версию iOS для блокировщика Mozilla не назвала; доступность функции по регионам анонс не описывает.

Почему блокировщик пришлось встраивать

Apple разрешает сторонним браузерам блокировать контент только через свой механизм Content Blocker: приложение отдаёт WebKit готовый список правил, а сам движок решает, какие запросы не выполнять. Расширение не может «посмотреть» на страницу и вмешаться в её код, как это делает uBlock Origin на десктопе. Mozilla взяла список EasyList, самый распространённый набор правил для рекламы, и упаковала его в такой блок правил внутри приложения.

Ad Blocker uses Apple's WebKit Content Blocker technology and the EasyList filter list.

Из этой архитектуры следуют ограничения, которые Mozilla перечисляет сама. Реклама, которую сайт отдаёт с собственного домена, может остаться, потому что её не отличить от контента по URL. Реклама в результатах поиска не блокируется. Рекламные ярлыки на стартовой странице самого Firefox к блокировщику не относятся. Включается всё в три касания: Settings, Browsing, Ad Blocker; там же выключается, если сайт перестал работать.

Что Firefox 155 даёт верстальщику

По заметкам для разработчиков на MDN, самое полезное в CSS — функция progress(): она возвращает долю от 0 до 1, показывающую, где значение находится между двумя границами. Раньше такой расчёт делали руками через calc(), теперь адаптивные размеры шрифта и отступов записываются короче. Функция alpha() меняет прозрачность цвета без переписывания его в rgb(), а attr() отныне работает в любом свойстве, а не только в content.

В JavaScript добавились Promise.allKeyed() и Promise.allSettledKeyed(): они принимают объект с промисами и возвращают объект с теми же ключами, так что не нужно сопоставлять результаты по индексам массива. Свойство font-width заменило font-stretch, старое имя оставлено как псевдоним. Если импорт модуля упал из-за временной ошибки сервера, повторный импорт теперь может выполниться успешно; это касается JS, JSON, CSS и текстовых модулей. В сетевом стеке появилось согласование QUIC version 2 для HTTP/3, а JSON Viewer в DevTools научился читать NDJSON построчно.

Для автотестов: в WebDriver BiDi исправлены перезагрузка фреймов, подписки и конфликт с DevTools, в WebRTC добавлена поддержка двухбайтовых RTP-заголовков с идентификаторами от 15 и новые поля статистики. Перед использованием progress() и alpha() в проде стоит сверить поддержку в Chrome и Safari на caniuse: MDN описывает только Firefox.

Почему обновиться сегодня

Бюллетень MFSA 2026-82 сопровождает релиз набором исправлений. CVE-2026-84119 (выход из песочницы через use-after-free в навигации DOM), CVE-2026-84143 и CVE-2026-84144 помечены как уязвимости высокого уровня, CVE-2026-84142 объединяет внутренне найденные ошибки памяти умеренного уровня. Отдельно для Firefox на Android бюллетень называет повышение привилегий (CVE-2026-84117, высокий уровень) и раскрытие информации через WebExtensions (CVE-2026-84127, умеренный уровень). Обновление на 155 закрывает всё это разом; на десктопе и Android оно важнее новых функций.

Что дальше

Mozilla объясняет встроенный блокировщик ограничениями расширений на iOS и формулирует их как «недоступны таким же образом», а не «невозможны навсегда»: в ЕС и Японии Apple уже допускает альтернативные движки, и если Firefox на iOS когда-нибудь перейдёт на Gecko, вопрос с расширениями встанет заново. Пока же блокировщик работает ровно в тех пределах, которые задаёт Content Blocker API.

Источники: Introducing Ad Blocker for Firefox on iOS (Mozilla), Firefox 155 for developers (MDN), Mozilla Foundation Security Advisory 2026-82

Изображение на обложке: Mozilla

Zero — иммерсивный лендинг индийского стартапа Zero University, который предлагает альтернативу классическому университетскому пути. Сайт превращает скролл в шестиактную историю: традиционное образование, разбитое стекло, горящие деньги, уничтоженные сертификаты, тоннель из логотипа ZERO и, наконец, интерактивная карта города с офисами реальных компаний. Цель — не просто показать красивую картинку, а провести пользователя через аргумент: диплом перестаёт быть гарантией, а навыки открывают дорогу в индустрию.

Проект разрабатывала студия BUNQ LABS четыре месяца. Исходные ассеты занимали больше гигабайта: несжатые Blender-сцены, 8K-текстуры и запечённые анимации. Финальная сборка уместилась в 10 МБ и держит 60 FPS даже на бюджетном Android. Команда опубликовала технический разбор на Codrops, а мы выделили решения, которые можно перенести в свои WebGL-проекты.

• Первый жест как ворота: распознавание нуля — это простая проверка угла, округлости и замкнутости, а не нейросеть.
• Виртуальный скролл заменяет нативный: одно число управляет загрузкой, анимацией, шейдерами и текстом.
• Ассеты важнее рендера: DRACO, KTX2/ETC1S, атласы и собственный превьювер сжали гигабайты до мегабайтов.
• Текстурные загрузки — главный источник фризов; декодинг в воркере и очередь по requestIdleCallback решают проблему.
• Адаптивное качество по frame time позволяет не гадать о мощности устройства.
• Мобильная точность шейдеров: mediump на Adreno и Mali — это реальный 16-битный float, и его недостаточно для сложных эффектов.

Разбираем, как это устроено изнутри, и что из этого можно взять в свою работу.

Сюжет из шести этапов и пяти ворот

Интерактивный нарратив строится вокруг пяти «ворот» — точек, где скролл останавливается и ждёт действия пользователя. Сначала нужно нарисовать ноль, затем удерживать касание, чтобы разбить стекло, потом — чтобы запуститься сквозь тоннель. Каждый жест связан с сюжетным поворотом: обещание университетского пути буквально трескается, за ним появляется статистика безработицы, диплом превращается в горящую бумагу, сертификаты рвутся на полосы.

От обещания к свободе

Шесть этапов идут от иллюзии контролируемого пути к интерактивной карте, где пользователь сам выбирает, куда смотреть. Финальный экран — город с башней Zero University в центре. Можно приближать, панорамировать и открывать карточки ролей, сценариев и инструментов. Это не просто финал: после того как сайт вёл пользователя за руку, он отдаёт управление обратно.

Архитектура: один скролл управляет всем

Одно из главных архитектурных решений — отказ от нативного скролла браузера. Нет ScrollTrigger, нет огромного прокручиваемого DOM. Вместо этого события колёсика и тача обновляют виртуальное значение скролла, которое плавно догоняет цель. Всё остальное — загрузка ассетов, анимации, тайминги шейдеров, текст и оверлеи — читают это единственное число.

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

Конвейер 3D-ассетов: как уместить 1 ГБ в 10 МБ

Большую часть четырёх месяцев ушла не на код, а на подготовку ассетов. Исходники пришли из Blender: несжатая геометрия, 8K-текстуры, запечённые анимации — всё вместе больше гигабайта. Первый месяц команда тратила на то, чтобы выбрать формат для каждого типа ресурсов.

DRACO и KTX2

Вся геометрия отправляется со сжатием DRACO, декодеры для которого хостятся локально в public/vendor/. Урок команда усвоила на собственном опыте: замедление на gstatic и unpkg привело к тому, что все сжатые ассеты перестали декодироваться, хотя сами файлы лежали на ихних серверах. Если декодер зависит от чужого CDN, весь пайплайн зависит от него.

Самый большой выигрыш дали текстуры. PNG может быть маленьким на диске, но в видеопамять он загружается распакованным. Текстура 2048² занимает около 16 МБ VRAM независимо от размера файла. Формат KTX2 со сжатием ETC1S остаётся сжатым на GPU, занимает меньше памяти и загружается быстрее.

Собственный превьювер компрессии

С KTX2 есть проблема: ETC1S — lossy, и локально его не посмотреть обычным просмотрщиком. Чтобы не гадать с настройками, команда сделала внутренний дашборд: сжатая и несжатая версия каждой картинки и видео рядом. Так можно было подобрать степень сжатия индивидуально — усилить там, где артефакты не заметны, сохранить качество для ключевых объектов и отключить мипмапы, где они не нужны. Инструмент простой, но редко встречается в WebGL-пайплайнах, хотя экономит огромное количество времени и памяти.

Атласы вместо дюжин картинок

Похожие текстуры собрали в общие атласы. Например, все текстуры рук уместили в один атлас 4×4, а каждая mesh сдвигала UV-координаты, чтобы взять свой кусок. Спрайты текста, сертификаты, бумажные обрывки, облака, монеты и осколки стекла тоже ушли в атласы. Больше 50 отдельных изображений превратились примерно в дюжину атласов, а большинство градиентных фонов заменили несколькими строками GLSL. Ранние сборки весили 35–40 МБ, финальная — меньше 10 МБ. При этом интерактивная карта мира вынесена в отдельную группу загрузки, чтобы не блокировать открытие сайта.

Текстурные загрузки: главный источник фризов

Уменьшить скачивание — только половина дела. Сжатые текстуры всё равно нужно загрузить в GPU на главном потоке, и крупная текстура легко блокирует рендер на 50 мс — достаточно, чтобы потерять несколько кадров. Если эта загрузка случается впервые во время скролла, подёргивание заметно сразу. Сайт может хорошо показывать себя в бенчмарках и при этом чувствоваться вязким.

• Декодировать вне главного потока — через createImageBitmap(). Тогда во время рендера остаётся только загрузка в GPU.
• Загружать в GPU в простое — декодированные текстуры ставят в очередь и выгружаются по requestIdleCallback, пока есть запас времени.
• Разбивать большие атласы на плитки 256² и загружать по одной на кадр, чтобы не выбиваться из бюджета кадра.

Когда известно, что следующий этап вот-вот появится — после загрузчика или во время перехода между воротами — очередь сбрасывается синхронно. Все нужные текстуры уже в видеопамяти, прежде чем они появятся на экране.

Адаптивное качество по реальному frame time

Невозможно заранее знать, на каком устройстве откроется сайт. Рендерер поэтому постоянно измеряет время кадра по скользящему окну и динамически меняет уровень качества. Если рендеринг замедляется — понижается tier. Если производительность стабильно высокая — tier снова растёт. Задержка между переключениями не даёт постоянно метаться у границы.

Уровни качества влияют только на визуальную полировку: devicePixelRatio, количество сэмплов размытия, геометрию монет, разрешение текста. Сама история остаётся неизменной и на флагмане, и на бюджетном телефоне. Для особо тяжёлых моментов — например, разбитие стекла — рендерер временно понижает пиксельное соотношение и отключает размытие и иней, прячет затраты внутри самого жеста.

Шейдеры под каждый эффект

Каждый ключевой момент использует собственный шейдер. ИИ помогал сгенерировать первые версии, но все финальные шейдеры переписывались и дорабатывались вручную. Вот несколько приёмов, которые стоит запомнить.

Постпроцессинг из нескольких проходов

Кадр собирается из цепочки проходов: основная 3D-сцена, процедурный фон, преломление стекла, иней и след от жеста, глубина резкости, foreground с зернистостью и тональной картой, отложенный текст, и в конце — разбитое стекло. Стеклянный, текстовый и шейдер разбития инициализируются лениво и прогреваются в простое, чтобы не попадать на критический путь загрузчика.

Иней из нарисованного нуля

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

Освещение без источников света

Реалтаймовое освещение скинненной меши рук было бы слишком дорогим, а свет должен был точно совпадать с оригинальным артом. Поэтому освещение запекли в текстуры и смешивают между ними. Используются два слота: один содержит текущий ключевой кадр, другой — следующий. По мере проигрывания анимации новый слот плавно вытесняет старый.

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

Горящие деньги

Эффект сгорания использует noise-driven distance field. Фронт горения проходит по купюре, слегка опережая точку дискарда. Перед ним появляется тонкий HDR-ободок углей, затем обугленная поверхность. FBM — самая дорогая часть шейдера, поэтому фрагменты отсекаются как можно раньше, если они ещё не достигли порога горения.

Рвущиеся сертификаты

Каждая вершина хранит индекс полосы, к которой принадлежит фрагмент диплома. Фронт разрыва движется слева направо, и каждая полоса отделяется и падает независимо со своим вращением. Нормали для освещения строятся аналитически из той же волновой функции, которая анимирует меш, поэтому normal map не нужен.

Тоннель ZERO

Тоннель получается выдавливанием поперечного сечения из логотипа ZERO. Импульс яркости распространяется по мировой координате Z, поэтому эффект остаётся бесшовным, даже когда секции тоннеля повторяются.

Текст, который приходит в фокус

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

Точность на мобильных

Одна из самых неприятных находок возникла на реальных мобильных GPU. Несколько шейдеров пришлось явно перевести на highp float, потому что на Adreno и Mali mediump — это настоящий 16-битный float. На десктопе ошибок не было, а на телефоне полосы диплома двигались одинаково, а эффект горения покрывался бэндами. Вывод: тестировать на реальных мобильных устройствах нужно с первых дней, а не перед релизом.

Дизайн взаимодействий

Исходный материал от заказчика состоял из картинок и видео, поэтому поведение каждых ворот проектировали с нуля. Большинство используют общую систему «нажми и удерживай». Общий конфиг задаёт момент появления подсказки и длительность удержания, а каждые ворота реализуют визуал через собственные хуки.

Пока пользователь удерживает касание, кадр постепенно смещается в тёмно-красный. Когда стекло разбивается, цвет возвращается примерно за 200 мс — это создаёт ощущение, что осколки выбивают темноту. Проверили вариант в 400 мс: он ощущался заметно слабее. Звук разбития привязан к первому отрисованному кадру, а не к таймеру: на медленных устройствах таймер может сыграть раньше анимации, и эффект рассинхронится.

Финальная награда — интерактивный мир

Последняя последовательность запуска выносит пользователя в открытое небо. Облака расступаются, открывая город с башней Zero University в центре, над которой появляется ореол — финальные ворота. Камера приземляется в интерактивную карту, где можно панорамировать, зумить и открывать карточки с ролями, сценариями и инструментами. Плашка Join Beta превращается в форму waitlist. После того как сайт вёл пользователя через историю, он отдаёт ему контроль — и просит остаться.

FAQ

Выводы

Самый важный урок проекта — подготовка ассетов и загрузка в GPU заслуживают не меньше внимания, чем сам рендеринг. Инструменты вроде превьювера компрессии, локальных декодеров, очереди загрузки и адаптивного менеджера качества редко выглядят героически, но именно они превратили гигабайт исходников в 10-мегабайтный сайт, который не тормозит на дешёвом телефоне.

ИИ генерировала первые версии кода и прототип, который выиграл нам проект, за 48 часов. Но полировка — сотни мелких решений, тестирование на реальных устройствах и инженерная интуиция — осталась за людьми.

Источник: технический разбор команды BUNQ LABS на Codrops.
Попробуйте открыть zero.university на десктопе и на бюджетном смартфоне — и сравните, где заметнее компромиссы качества.

В статье разбираем, почему React.memo сравнивает пропсы по ссылке, как inline-объекты и inline-функции обнуляют эту оптимизацию, и какие два простых приёма действительно возвращают производительность.

React.memo пропускает рендер только тогда, когда все пропсы равны по Object.is. Для объектов и функций это проверка по ссылке.

Inline-объекты и inline-колбэки в JSX создают новую ссылку на каждый рендер родителя, поэтому memo видит «новые» пропсы и снова рисует дочерний компонент.

В эксперименте со 200 memoизированными строками это дало 243,9 мс на один keystroke; после стабилизации ссылок — 6 мс.

Сначала выносите статические объекты за пределы компонента, а useCallback применяйте только там, где колбэк действительно пересекается с memoизированным потомком.

Оптимизировать всё подряд не нужно: измеряйте в Profiler, а не добавляйте хуки «на всякий случай».

Как React решает, рендерить компонент заново или нет

Когда родитель перерисовывается, React не делает послаблений дочерним элементам только потому, что они обёрнуты в React.memo. Он сравнивает новые пропсы со старыми. Если каждый проп проходит проверку Object.is, React может «отказаться» от рендера — bailout. Если хотя бы один проп не равен, компонент рисуется заново.

Для примитивов Object.is работает очевидно: 1 === 1 и 'hello' === 'hello'. А вот для объектов и функций сравнение идёт по ссылке.

Два объекта с одинаковым содержимым — это разные объекты в памяти. То же самое с функциями. Поэтому, когда вы пишете style=\{\{ padding: 16 \}\}, React получает новую ссылку на каждом рендере и считает проп изменившимся.

Почему inline-пропсы — это не микрооптимизация, а поломка контракта

Сам по себе объект в JSX не вреден. Если компонент дешёвый, редко перерисовывается и не обёрнут в memo, inline-пропсы почти не влияют на скорость. Проблема появляется, когда три условия накладываются друг на друга:

• родитель перерисовывается часто — поиск, скролл, фильтры, live-данные;
• дочерний компонент или поддерево достаточно тяжёлые, чтобы лишний рендер был заметен;
• вы уже добавили React.memo и ожидаете, что React будет пропускать работу.

В такой ситуации нестабильные ссылки не просто добавляют накладных расходов — они полностью отменяют ту оптимизацию, ради которой вы взяли React.memo. UI продолжает работать, но лагает ввод, тормозят списки, а в Profiler видно, что дерево горит жёлтым при каждом чихе.

Классический опасный пример

Представьте список товаров из 200 строк. Каждая строка обёрнута в memo, но в месте вызова передаются inline-пропсы:

Здесь style и onAddToCart создаются заново при каждом рендере ProductList. Для memo это сигнал, что у каждой строки изменились пропсы, и все 200 компонентов рисуются снова.

Эксперимент: от 243,9 мс до 6 мс на один keystroke

Автор оригинальной статьи собрал контрольный пример: поисковый интерфейс со 200 memoизированными строками. Все строки получают одинаковые логические значения, но новые ссылки на объекты и функции. Результат после шести введённых символов: каждая видимая строка отрендерилась 14 раз.

В React DevTools Profiler один keystroke дал коммит длительностью 243,9 мс, в котором подсветились все 200 волокон строк. Инструмент @welldone-software/why-did-you-render прямо указал причину: props.style — «different objects that are equal by value», props.onAddToCart — «different functions with the same name».

Почему 14 рендеров?
Каждый ввод в поиск меняет searchTerm, родитель перерисовывается, и inline-пропсы дают строкам новые ссылки. Счётчик рендеров растёт на каждый keystroke, даже если отфильтрованные товары не изменились.

Как починить: два приёма вместо дюжины хуков

Чтобы восстановить bailout, нужно сделать так, чтобы неизменяющиеся значения не получали новую ссылку на каждом рендере. Правило простое: сначала вынести, потом закешировать.

1. Статические объекты — за пределы компонента

Если объект не зависит от пропсов и состояния, создайте его один раз на уровне модуля. Это дешевле любого хука и не требует dependency-массива.

2. Динамические колбэки — useCallback

Если функция передаётся в memoизированный компонент и не должна меняться без причины, оберните её в useCallback со стабильным массивом зависимостей.

После этих двух изменений в эксперименте время рендера упало с 243,9 мс до 6 мс, счётчики строк застыли на 2, а Why Did You Render замолчал — avoidable re-renders исчезли.

Когда не нужно ничего стабилизировать

Главная ошибка — оборачивать в useCallback каждую функцию и выносить каждый объект за компонент. React сам по себе быстрый, а мемоизация — это контракт, а не стиль кодирования.

• Компонент дёшев и редко перерисовывается — не тратьте когнитивный бюджет команды.
• Дочерний элемент не обёрнут в React.memo — тогда стабильные ссылки ничего не экономят.
• Значение зависит от часто меняющегося состояния — useCallback с нестабильным массивом зависимостей всё равно будет пересоздаваться.
• Вы ещё не замерили в Profiler — оптимизация без измерений почти всегда лишняя работа.

React Compiler, который сейчас выходит в стабильное состояние, автоматически мемоизирует многое из того, что раньше делали вручную. Но и он не отменяет понимания ссылочной стабильности: useMemo и useCallback остаются полезными, когда нужен точный контроль, например для зависимостей эффектов.

Часто задаваемые вопросы

Выводы

Inline-объекты и inline-колбэки в JSX — не антипаттерн сами по себе. Они становятся проблемой только на границе memoизации, где React ожидает стабильные ссылки. Как только вы понимаете это правило, многие «таинственные» лишние рендеры перестают быть таинственными.

1. Профилируйте до оптимизации, а не после.
2. Вынесите статические объекты за компонент — это самый дешёвый способ стабилизации.
3. Применяйте useCallback только для колбэков, которые уходят в memoизированные потомки.
4. Проверяйте себя через React DevTools Profiler и Why Did You Render.
5. Не забывайте про React Compiler, но не полагайтесь на него как на волшебную палочку.

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

Источник: LogRocket — The React pattern everyone uses that kills performance.

Проверьте свой текущий проект: откройте React DevTools Profiler, введите что-нибудь в поиск и посмотрите, сколько компонентов подсветится жёлтым только из-за новой ссылки в пропсах.

Речь пойдёт не о теории reconcile-алгоритма, а о практике: что проверять первым делом, как изолировать проблему через Suspense, куда смотреть в production-логах и как писать тесты, которые ловят регрессии до попадания к пользователям.

Что такое hydration mismatch

Гидратация — это процесс, при котором React берёт серверный HTML и навешивает на него обработчики событий, после чего страница становится интерактивной. React ожидает, что дерево, которое он отрендерил на клиенте, точно совпадёт с тем, что пришло с сервера. Если строки, атрибуты или структура различаются, возникает hydration mismatch.

В development-режиме React покажет предупреждение, текст расхождения и стек компонента. В production всё сводится к коротким кодам вроде #418 или #425. Без телеметрии вы не узнаете, на каком маршруте, в каком компоненте и из-за каких данных произошёл сбой.

Почему это больно именно в RSC

В классическом SSR обычно один серверный рендер и один клиентский проход гидратации. App Router добавляет Server Components, Client Components, потоковую передачу, Suspense-границы, динамические данные маршрута и RSC payload, который едет рядом с HTML.

Когда несовпадение происходит вне Suspense-границы, React может отбросить весь серверный HTML и перерендерить дерево на клиенте. Приложение заплатило цену серверного рендера, а пользователь не получил ни производительности, ни преимуществ стриминга. Это не просто предупреждение в консоли, а реальная потеря производительности.

Ключевые выводы

• Hydration mismatch в production без телеметрии почти невозможно локализовать: нужна инструментация на клиенте.
• Основные причины: browser-only API, дата/время/локаль, состояние авторизации, невалидный HTML, расширения браузера, CSS-in-JS.
• Граница 'use client' — это не только маркер сборки, но и граница гидратации: серверный рендер должен быть детерминирован.
• Suspense-границы помогают изолировать сбой и не давать ему сломать всё дерево.
• Проверяйте hydration только на production-сборке: next dev ведёт себя иначе.
• Добавьте Playwright-smoke-тесты на критичные маршруты, чтобы ловить регрессии в CI.

Самые частые причины

Перед тем как копать RSC payload или сравнивать HTML, стоит проверить шесть типовых сценариев. Они покрывают подавляющее большинство production-инцидентов.

• Browser-only API во время рендера: window, document, localStorage, navigator — сервер не знает об этих значениях.
• Дата, время и локаль: Date, Intl.DateTimeFormat, относительное время — сервер обычно в UTC, пользователь в своей зоне.
• Состояние авторизации: сервер рендерит выклогнутый UI, клиент сразу видит авторизованного пользователя.
• Невалидный HTML: браузер чинит DOM до гидратации, а React сравнивает с исходным деревом.
• Расширения и middleware: браузерные плагины и edge-переписывания меняют HTML.
• CSS-in-JS и порядок классов: styled-components и Emotion могут генерировать разные имена классов при стриминге.

Browser-only API и сторонние провайдеры

Самая частая причина — не ваш собственный код, а сторонний провайдер, который читает localStorage, window или navigator при инициализации. Под это попадают аналитика, фичер-флаги, A/B-тесты, session replay и персонализация.

Проблемный вариант: провайдер читает localStorage прямо при рендере.

Исправление: серверные флаги передаются в Client Component, а локальные оверрайды применяются после гидратации.

Принцип: серверный и первый клиентский рендер должны получить одинаковый результат. Браузерные оверрайды включаются в useEffect после монтирования.

Дата, время и локаль

Сервер часто работает в UTC, а пользователь — в своей зоне. Date.toLocaleString(), Intl.DateTimeFormat и функции вроде formatDistanceToNow() дают разные строки в зависимости от часового пояса и времени между рендером и гидратацией.

Проблемный вариант: относительное время считается на сервере.

Исправление: сервер отдаёт стабильную абсолютную дату, клиент заменяет её на относительную после монтирования.

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

Состояние авторизации

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

Решение — читать куки на сервере через cookies() из next/headers.

С cookies() маршрут становится динамическим — это обычно правильный компромисс для UI, зависящего от авторизации. Начиная с Next.js 15, cookies() асинхронный и требует await. В Next.js 16 синхронный доступ к request-time API полностью уходит.

Невалидный HTML

Браузер молча чинит невалидную вёрстку. React же гидратирует не исходную строку, а DOM, который построил браузер. Классический пример — внутри

Браузер превратит это в примерно такую структуру:

Если HTML приходит из CMS или редактора, валидируйте и нормализуйте его на сервере. Для собственных компонентов следите за предупреждениями validateDOMNesting в DevTools.

Расширения браузера и middleware

Менеджеры паролей, переводчики, грамматические плагины и другие расширения могут вставлять или переупорядочивать узлы до гидратации. Edge middleware и CDN-трансформации тоже могут переписывать HTML в пути.

Если несовпадение затрагивает только <html> или <body>, сначала подозревайте расширения. React 19 стал терпимее к инъекциям в head/body, но на старых версиях такие ошибки особенно шумные.

suppressHydrationWarning на корневых элементах — документированный escape hatch, но он работает только на один уровень вглубь и не должен использоваться для сокрытия неизвестных расхождений в продуктовом UI.

CSS-in-JS и порядок классов

В проектах со styled-components или Emotion имена классов могут зависеть от порядка рендера. Стриминг и Suspense меняют этот порядок, поэтому нужен registry с useServerInsertedHTML.

Production workflow для отладки

Не начинайте с diff-а огромных HTML-документов. Работайте по порядку, сужая область поиска.

1. Настройте клиентскую телеметрию: перехватывайте console.error и отправляйте hydration-ошибки на свой endpoint.
2. Воспроизводите баг на production-сборке: next build && next start, а не next dev.
3. Используйте Suspense-границы, чтобы изолировать проблемный участок и понять, в каком поддереве ошибка.
4. Сравнивайте серверный HTML (curl) и клиентский DOM после гидратации.
5. Когда найдёте расходящийся элемент, проверьте: browser-only API, дата/время, авторизацию, HTML-вложенность, расширения, стили.

Инструментация: instrumentation-client.ts

Файл instrumentation-client.ts в Next.js запускается после загрузки документа, но до гидратации React. Это удобная точка для лёгкой клиентской телеметрии.

Если используете LogRocket, Sentry или другой инструмент, прикрепите тот же payload к текущей сессии — тогда можно будет увидеть, как выглядела страница в момент сбоя.

Изоляция через Suspense

Suspense-границы не только показывают fallback при загрузке. Если hydration mismatch случается внутри границы, React может ограничить восстановление этим поддеревом, а не переключать весь root на клиентский рендер.

Оберните поочерёдно основные секции. Если страничная ошибка исчезает после оборачивания конкретной секции, баг почти наверняка внутри неё.

Сравнение HTML и DOM

Получите серверный HTML через curl с нужными куками:

В Chrome DevTools после загрузки страницы скопируйте живой DOM:

Сохраните результат в /tmp/client-render.html и сравните:

Этот метод хорошо ловит HTML-слой, но может пропустить расхождения на уровне reconciler-а и RSC payload. Если raw HTML совпадает, проверяйте Client Components и браузерное состояние.

Профилактика

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

1. Server Component должен быть детерминированным: одни и те же входные данные дают одни и те же выходные HTML и RSC payload.
2. Все browser-only API, куки, заголовки, локаль и время должны оставаться за границей 'use client' или читаться через request-time API на сервере.
3. Для клиентского UI сначала рендерите стабильный baseline, а улучшения добавляйте в useEffect после гидратации.
4. Валидируйте HTML из внешних источников до того, как React его увидит.
5. Тестируйте hydration на production-сборке в CI.

Пример: стабильный baseline + клиентское улучшение

Скелетон — это стабильная базовая разметка. Карточки товаров появляются после монтирования. Сервер и первый клиентский рендер совпадают, а пользователь получает нужный контент чуть позже.

Smoke-тесты в CI

Ручное тестирование пропустит регрессии. Добавьте Playwright-тест на критичные маршруты.

Запускайте такой тест только против production-сборки, никогда против next dev. Сделайте его обязательной проверкой для маршрутов, где hydration failure критичен: продуктовые страницы, дашборды, чекаут, личный кабинет.

FAQ

Выводы

Hydration mismatch — не придирка React, а реальный баг производительности и корректности. Каждое несовпадение означает, что приложение могло отбросить серверный HTML, за который уже заплатило ресурсами.

В приложениях с React Server Components, где цель — меньше клиентского JavaScript и более ранний стриминг полезного UI, hydration failures тихо отменяют эти преимущества. Поэтому важно держать браузерную логику за границей 'use client', рендерить стабильные серверные baseline и проверять гидратацию в production-условиях до того, как ошибку найдут пользователи.

Hydration errors should be fixed, not ignored — официальная позиция React.

Источник: LogRocket Blog — How to fix RSC hydration mismatches in Next.js.

Проверьте свои критичные маршруты на production-сборке, настройте телеметрию и не давайте hydration-ошибкам копиться в консоли.

В своей статье разработчик Мэтт Смит объясняет, почему перестал раскладывать объекты на переменные по умолчанию и как это изменило его подход к читаемости кода.

Деструктуризация — инструмент, а не норма. Её стоит применять там, где она правда упрощает код, а не просто экономит символы.

Объект хранит контекст. project.status понятнее, чем голая переменная status, особенно в больших функциях.

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

Деструктурируйте позже, а не раньше. Сохраняйте исходный объект до тех пор, пока он действительно не понадобится в разобранном виде.

Каждая новая переменная — когнитивная цена. Если имя не добавляет смысла, лучше обратиться к свойству объекта напрямую.

Деструктуризация — не религия

Несколько лет назад Мэтт Смит деструктурировал почти всё: объекты, пропсы, параметры, возвращаемые значения. Если встречался объект — он его раскладывал. Это перестало быть осознанным решением и превратилось в привычку: так пишет «современный JavaScript».

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

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

Не бойтесь повторов

Один из самых распространённых паттернов — вынесть поля из объекта, а потом передать их как пропсы в компонент:

С этим ничего не случилось. Но сегодня автор с большей вероятностью напишет так:

Да, здесь повторяется post. Но когда он вернётся к этому коду через месяц, ему не придётся вспоминать, откуда взялись title или author. Контекст остаётся на виду.

Объект несёт контекст

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

А сто строк ниже встретили такой код:

Моментальная пауза: «archived»… что именно? Сравните с вариантом, где объект сохраняет свою форму:

Объект по-прежнему несёт полезный контекст. Лишние символы редко замедляют чтение. А вот необходимость помнить, к какой сущности относится переменная, замедляет гораздо сильнее.

Вложенность лучше раскрывать поэтапно

Раньше автор считал вложенную деструктуризацию элегантной. Сейчас она часто кажется попыткой понять всю структуру объекта ещё до того, как начал решать задачу.

Автор предпочитает писать иначе:

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

Деструктурируйте позже, а не раньше

С параметрами компонентов ситуация похожа. Для маленьких компонентов деструктуризация пропсов отлично работает:

Но по мере роста компонента автор чаще пишет так:

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

Каждая переменная — цена для читателя

Каждая локальная переменная просит читателя запомнить ещё одно имя. Иногда это стоит того, иногда — нет.

Если новая переменная обозначает осмысленную концепцию, автор с удовольствием её вводит. Имя вроде billingAddress становится частью словаря функции.

Но если автор просто превращает project.status в status, уверенности, что код стал читабельнее, нет. Полезное правило большого пальца: если деструктуризация даёт коду лучший словарь — использует её. Если она только экономит несколько символов — обычно нет.

Когда деструктуризация всё ещё уместна

Всё вышесказанное — не аргумент против деструктуризации. Автор по-прежнему применяет её постоянно.

Эти случаи локальны, сфокусированы и убирают шум. Есть и другие исключения. При маппинге массива я спокойно пишу:

Объект существует всего несколько строк, поэтому автор не чувствует, что теряет контекст. Иногда имеет смысл даже переименовать извлечённое свойство: const { status: projectStatus } = project;.

Такое имя сохраняет больше контекста, чем просто status. Но если автор всё равно несёт имя объекта в переменную, часто оказывается, что project.status читается естественнее. Не нужно придумывать новое имя, а связь с объектом остаётся очевидной.

Разница в том, что автор больше не деструктурирует просто потому, что объект существует.

Главный вопрос

Автор всё ещё любит деструктуризацию. Есть множество мест, где она заметно очищает код. Просто он больше не хватается за неё автоматически.

Перед тем как убрать объект, он спрашивает себя: удаление объекта действительно облегчает понимание или просто делает код короче?

Если деструктуризация даёт коду лучший словарь — автор её использует. Если она только экономит несколько символов — обычно нет.

Выводы

Деструктуризация остаётся одним из самых полезных синтаксических улучшений JavaScript. Но удобство записи не должно превращаться в удобство только для автора. Читаемость кода измеряется не количеством символов, а скоростью, с которой человек понимает, что происходит.

Сохраняйте объекты там, где они несут контекст. Раскрывайте вложенность поэтапно. Вводите переменные, только если они добавляют смысла. И не забывайте главный вопрос: вы делаете код понятнее или просто короче?

Источник: Matt Smith — I stopped destructuring everything

На первый взгляд кнопка «наверх» — задача на пять минут. Добавил position: fixed, обработчик window.scrollTo() — готово.

Но стоит этой кнопке появиться в живом проекте, как выясняется, что она пересекается с cookie-баннером, мешает чату поддержки, выглядит иначе в мобильной версии, не дружит со строгим CSP или пропадает из Django Admin.

В итоге маленькая UI-деталь начинает обрастать условиями. Я решил собрать их в отдельный Django-пакет — django-scroll-to-top

Когда трёх строк JavaScript достаточно

Для небольшого сайта, где нет сложной верстки, админки, CSP и требований к повторному использованию, самый простой вариант действительно выглядит примерно так:

Это нормальное решение. Не всегда стоит тянуть пакет ради одной кнопки.

Но в реальном Django-проекте быстро появляются дополнительные вопросы:

• когда именно показывать кнопку: после 300 пикселей, одного экрана или только при прокрутке вверх;
• что делать на коротких страницах;
• как не перекрыть cookie-баннер, чат, toast-уведомления или нижнюю мобильную навигацию;
• как дать пользователю закрыть кнопку;
• как не сломать клавиатурную навигацию и режим reduced motion;
• как сделать отдельное оформление для сайта и Django Admin;
• как не заставлять проект добавлять unsafe-inline в Content Security Policy;
• как позволить редактору или администратору изменить цвет, положение и иконку без нового деплоя.

Именно в этот момент «три строки JavaScript» превращаются в отдельный компонент.

Что я хотел получить

Цель была не в том, чтобы сделать ещё одну стрелку в правом нижнем углу. Хотелось собрать переиспользуемый компонент со следующими свойствами:

1. Подключение сайта одной template-тегом.
2. Отдельная поддержка обычных страниц и стандартного Django Admin.
3. Настройка внешнего вида через админку, а не через постоянную правку CSS.
4. Без jQuery, CDN, фронтенд-фреймворка и обязательной сборки.
5. Безопасная работа при строгой CSP.
6. Прогрессивное улучшение: без JavaScript остаётся обычная ссылка в начало страницы.
7. Возможность жить рядом с другими фиксированными элементами интерфейса.

Пакет в итоге хранит обычные настройки установки в settings.py, а визуальное поведение — в базе данных. Это позволяет менять кнопку через Django Admin, публиковать новую версию настроек и при необходимости откатываться на предыдущую. В проекте есть отдельные профили для публичного сайта и Django Admin, а ревизии могут быть черновыми, опубликованными или архивными.

Быстрое подключение

Базовый сценарий начинается с установки:

В settings.py добавляем приложение. Если нужна поддержка стандартной админки, пакет должен идти раньше django.contrib.admin:

Включаем области, где должна работать кнопка:

Для публичной части добавляем URLConf пакета:

А в общий шаблон сайта — один тег:

На стандартном Django Admin ничего дополнительно вставлять не нужно: пакет использует обычный механизм разрешения шаблонов Django. Если же в проекте переопределён admin/base_site.html тег можно добавить вручную в блок footer

Настройка без превращения админки в редактор CSS

Мне не хотелось хранить в базе шаблоны, произвольный CSS или JavaScript. Это неудобно для сопровождения и создаёт лишнюю поверхность для ошибок.

Поэтому визуальная часть собрана из контролируемых вариантов:

• круг, квадрат, скруглённый квадрат или pill;
• заливка solid, outline, soft, ghost, glass или gradient;
• положение в любом углу экрана;
• отдельные размеры для desktop и mobile;
• светлая и тёмная тема;
• встроенные иконки, иконки от разработчика или загружаемые SVG;
• настройки тени, границы, opacity и focus ring.

Что происходит, когда рядом есть cookie-баннер или чат

Нижний правый угол страницы редко бывает свободен. Там часто живут:

• cookie-баннер;
• компактная кнопка после закрытия баннера;
• чат поддержки;
• кнопка обратного звонка;
• мобильная навигация;
• toast-уведомления.

Пакет умеет рассматривать такие элементы как препятствия. Для этого можно пометить элемент атрибутом:

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

Для сложных виджетов есть отдельный адаптер: он может отслеживать появление и исчезновение элементов, например компактного launcher после закрытия cookie-баннера. При этом ни cookie-пакет, ни чат не становятся зависимостями django-scroll-to-top

Доступность — не отдельная галочка в конце

У кнопки есть понятное имя для screen reader, поддержка клавиатуры, видимый focus-visible, минимальный размер области нажатия и режим prefers-reduced-motion.

Если пользователь отключил анимации на уровне системы, плавная прокрутка не будет навязываться. Если JavaScript не загрузился, кнопка остаётся обычной ссылкой на начало документа.

Полный независимый аудит WCAG 2.2 AA и тестирование масштабирования 200% и 400% пока находятся в roadmap, поэтому называть компонент полностью сертифицированным по WCAG было бы неправильно. Но структурные требования — клавиатурная доступность, фокус, reduced motion, forced-colors и безопасная работа без JavaScript — уже заложены в компонент и покрываются тестами.

CSP и загружаемые SVG

В корпоративных проектах часто нельзя просто добавить inline-скрипт и включить unsafe-inline ради одной кнопки.

По умолчанию компонент использует same-origin CSS и JavaScript. Для него подходит политика такого вида:

Настраиваемые цвета и размеры отдаются не через inline-стили, а через версионированный stylesheet endpoint. Это позволяет сохранить простой контракт с одним template-тегом и не ослаблять CSP.

Отдельно пришлось подумать о загружаемых SVG. Админ не рендерит исходный файл как есть: SVG проходит санитарную обработку. Скрипты, обработчики событий, внешние ресурсы, встроенные документы и небезопасные namespace отклоняются. Для загружаемых иконок также хранится информация об авторе, источнике и лицензии.

Ревизии, публикация и откат

Одна из самых полезных вещей в пакете — не сама кнопка, а жизненный цикл её настроек.

Можно создать черновик, посмотреть результат в live preview, опубликовать изменения или вернуться к предыдущей версии. Это особенно удобно, когда кнопку настраивает не разработчик, а контент-менеджер или дизайнер.

У ревизий есть три состояния:

• draft — редактируемый черновик;
• published — текущая активная конфигурация;
• archived — сохранённая версия для отката.

Где пакет уместен, а где нет

django-scroll-to-top имеет смысл, когда кнопка нужна в нескольких проектах, должна работать в Django Admin, настраиваться без деплоя или жить в окружении со строгими требованиями к CSP и интерфейсу.

Для лендинга на одну страницу проще и правильнее написать несколько строк самостоятельно. Это будет быстрее, понятнее и дешевле в сопровождении.

Но если такая маленькая деталь начинает повторяться в нескольких продуктах, появляется необходимость поддерживать мобильную версию, доступность, независимые настройки для сайтов и админки, то отдельный компонент уже перестаёт быть избыточным.

Сейчас пакет выпущен как beta-версия 0.2.0, требует Python 3.10+ и поддерживает Django 4.2 LTS, 5.x и 6.0. Лицензия — MIT.

Исходный код, документация и примеры использования доступны в GitHub-репозитории проекта.

Пакет опубликован в PyPI под именем django-scroll-to-top.

Обратная связь, баг-репорты и предложения по интеграции с кастомными Django Admin-темами приветствуются в Issues.

В рамках Operation Endgame отключены 106 серверов SocGholish и очищены 14 971 заражённый сайт на WordPress.

SocGholish (он же FakeUpdates) — JavaScript-даунлоудер, активен с 2017 года и доставляет шифровальщиков и шпионское ПО.

Распространяется через скомпрометированные сайты под видом обновлений Chrome, Firefox и популярного софта.

Связан с группами Evil Corp, LockBit, RansomHub, Dridex и Raspberry Robin.

Владельцам сайтов рекомендовано обновить CMS, сменить учётные данные и удалить подозрительные аккаунты.

Операция прошла в рамках инициативы Operation Endgame, запущенной в 2024 году для борьбы с ботнетами и криминальной инфраструктурой. Владельцам очищенных сайтов уже разосланы уведомления: обновить CMS, изменить пароли и удалить подозрительные учётные записи.

SocGholish — один из старейших JavaScript-даунлоудеров. Он заражает компьютеры через взломанные сайты, предлагая посетителям фальшивые обновления браузеров или популярного ПО. После установки малварь открывает начальный доступ к системе, который затем используется для атак шифровальщиками и шпионским ПО.

За годы активности за SocGholish закрепились множество имён: FakeUpdates, Gold Prelude, TA569 и UNC1543. Инфраструктура малвари тесно связана с группами Evil Corp, LockBit, RansomHub, Dridex и Raspberry Robin.

Как защитить свой сайт

• Регулярно обновляйте WordPress, плагины и темы.
• Используйте сложные уникальные пароли и двухфакторную аутентификацию.
• Проверьте список администраторов и удалите подозрительные аккаунты.
• Мониторьте файлы сайта на наличие внедрённого JavaScript-кода.

Operation Endgame называет эту операцию началом дальнейших действий против SocGholish. Хотя часть инфраструктуры отключена, экосистема малвари включает аффилиатов и системы распределения трафика, поэтому угроза сохраняется. Подробности — в первоисточнике на The Hacker News.

В начале июня команда Codrops опубликовала небольшую, но наглядную демонстрацию: галерея фотографий проезжает через вьюпорт, пока каждая картинка медленно кувыркается в трёхмерном пространстве. Идея позаимствована у аниматора Jason Booth, а код выложен на GitHub вместе с пятью готовыми вариациями.

В этой статье разберёмся, как устроен эффект, из чего состоит математика и как быстро повторить его у себя — без WebGL, Canvas и тяжёлых библиотек.

Эффект строится на CSS-свойствах perspective и transform-style: preserve-3d, а анимация крутит rotationX/Y/Z и translateZ по прогрессу скролла.

Для синхронизации с прокруткой используется GSAP ScrollTrigger с параметром scrub: true; плавность даёт библиотека Lenis.

Codrops предлагает пять вариаций: от мягкого волнообразного движения до агрессивного разворота с blur и изменением яркости.

Всего нужно три ингредиента: разметка с фоновыми изображениями, CSS для 3D-контекста и 30—40 строк JS, которые связывают скролл с трансформациями.

Как устроен базовый эффект

В основе лежит простая мысль: каждая картинка — это не плоский прямоугольник, а объект в 3D-пространстве. Пока пользователь скроллит страницу, объект проходит перед «камерой» и меняет ориентацию. Входная точка анимации начинается, когда элемент появляется снизу экрана, а заканчивается, когда уходит вверх.

Для реализации используется связка GSAP + ScrollTrigger. Параметр scrub: true привязывает анимацию напрямую к позиции скролла: чем дальше прокручено, тем сильнее трансформация. Библиотека Lenis отвечает за плавность: без неё колёсико мыши на Windows или трекпад на macOS могут давать рваное движение, и вся магия растворится.

Разметка и CSS

HTML минимален: контейнер .gallery и набор .gallery__item с фоновыми картинками. Главное — обернуть каждый item дополнительным .gallery__item-wrap и задать ему perspective. Именно обёртка создаёт 3D-контекст, внутри которого вращается сама картинка.

Плавный скролл и триггеры

Перед запуском анимации инициализируем Lenis и связываем её с GSAP. Это стандартный «боеприпас» для большинства современных сайтов с анимацией по скроллу.

Математика вращения

Каждой картинке случайно задаётся начальная ориентация по трём осям. Затем GSAP анимирует от этих значений до противоположных, создавая эффект «переворота» на 180°. В обработчике onUpdate вычисляется смещение по оси Z: чем ближе элемент к центру экрана, тем глубже он «погружается» в пространство.

Совет: если вы убираете плавный скролл, протестируйте эффект на мобильном устройстве. Нативный скролл на iOS и Android может дать менее плавную картинку, и тогда имеет смысл оставить Lenis или добавить @media (prefers-reduced-motion) для доступности.

Пять вариаций одной идеи

Codrops не ограничивается одной анимацией: в репозитории пять HTML-файлов, каждый из которых демонстрирует, как одно и то же ядро превращается в разное настроение. Вот краткая карта отличий.

• Вариант 1. Мягкое волнообразное расположение картинок по горизонтали, случайные углы rotationX 70—120° и небольшой зазор по Z (−50 px). Универсальная, спокойная подача.
• Вариант 2. Больший размах по rotationX (240—290°) и усиленная глубина до −300 px. Картинки буквально переворачиваются перед глазами.
• Вариант 3. Триггер вычисляет поворот через cos(progress * π), добавляет сдвиг по Y (yPercent) и фильтры saturate/brightness. Получается «подводное» движение.
• Вариант 4. Акцент на скорости: в обработчике Lenis отслеживается velocity, и чем быстрее скролл, тем сильнее blur и ниже насыщенность. Динамично и спортивно.
• Вариант 5. Агрессивное искажение масштаба: scaleX и scaleY меняются в противофазе, картинки растягиваются и сжимаются, проходя через центр экрана.

Мини-руководство: повторяем у себя

Чтобы не копировать всю демку целиком, можно взять только схему и адаптировать под свой проект. Ниже — самый короткий путь от макета до рабочей анимации.

FAQ

Выводы

3D-анимации по скроллу — это способ сделать обычную галерею запоминающейся без тяжёлых WebGL-сцен. Хватает CSS-свойств perspective и transform-style, пары строк GSAP и библиотеки Lenis для плавности.

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

Пользователь не запоминает интерфейс, который просто красив. Он запоминает тот, который отзывается на его действия.

Источники: оригинальная статья Codrops, демо Rotating On-Scroll Animations и исходный код на GitHub.

• Скомпрометированы 144 пакета в пространстве имён @mastra/*, включая @mastra/core.
• Атака шла через взломанный аккаунт бывшего контрибьютора ehindero.
• Вредоносная библиотека easy-day-js запускалась через postinstall и устанавливала кроссплатформенный стилер.
• npm уже откатил latest-теги и удалил вредоносные версии у ключевых пакетов.

Как прошла атака на пакеты Mastra в npm

Mastra — это open-source фреймворк на JavaScript и TypeScript для создания ИИ-приложений и агентов. Только @mastra/core скачивают более 918 тыс. раз в неделю, поэтому инцидент затронул огромное число разработчиков и CI-сред.

По данным исследователей из JFrog, SafeDep, Socket и StepSecurity, атака длилась 88 минут. Злоумышленники массово публиковали версии с добавленной зависимостью easy-day-js — клоном популярной библиотеки dayjs. Пакет появился у пользователя sergey2016 16 июня в 7:05 UTC как чистая копия, а вредоносный код был внесён 17 июня в 1:01 UTC.

При установке easy-day-js срабатывал обфусцированный postinstall-хук (скрипт, который npm запускает автоматически после установки пакета): он отключал проверку TLS, загружал вторую стадию с сервера 23.254.164[.]92, запускал её фоновым процессом и самоудалялся. Финальный троян собирал историю браузера, данные свыше 160 браузерных расширений криптовалютных кошельков и передавал их на C2-сервер 23.254.164[.]123 — сервер управления злоумышленников.

Что делать разработчикам

• Проверить lock-файл: grep easy-day-js package-lock.json или npm ls easy-day-js.
• Откатиться к версии, опубликованной до 17 июня 2026 года (~1:01 UTC), и зафиксировать её в зависимостях.
• Сменить токены npm, GitHub, SSH-ключи и переменные окружения на хостах, где стоял подозрительный пакет.
• Проверить логи сети и DNS на обращения к IoC (индикаторам компрометации): IP 23.254.164[.]92 и 23.254.164[.]123.
• Включить проверку подписей пакетов: npm audit signatures, и в CI требовать SLSA-provenance-attestation.

npm уже удалил вредоносные версии у ключевых пакетов и вернул latest-теги. Но разработчикам стоит проверить свои системы: полезная нагрузка выполняется ещё на этапе установки, до первого импорта пакета. Источник: The Hacker News.

Разберём минимальный, но готовый к продакшену скелет: разделение слоёв, валидацию входных данных, централизованную обработку ошибок, версионирование, ограничение частоты запросов и автоматическую документацию. Все принципы применимы и к Express, и к Fastify, и к NestJS.

Чистое API — это прежде всего разделение ответственности: роутер знает маршруты, контроллер переводит HTTP в вызовы сервиса, сервис отвечает за бизнес-логику, а схема проверяет входные данные. Такой подход делает код предсказуемым при любом масштабе.

Чистое API — это, прежде всего, разделение ответственности: роутеры, контроллеры, сервисы и валидация живут в разных слоях.

Валидация с помощью Zod выполняется на границе — до того, как запрос попадёт в бизнес-логику.

Централизованный обработчик ошибок — единственное место, где исключения превращаются в HTTP-ответы.

Стоит закладывать версионирование и документацию OpenAPI с первого дня: позже это обойдётся дороже.

Fastify и NestJS дают те же архитектурные идеи из коробки, но логика слоёв от этого не меняется.

Что мы будем строить

Возьмём намеренно простой домен — каталог товаров. Нам важна не бизнес-логика, а структура. К концу у нас будет REST API с единым форматом ответов, валидацией, версионированием по пути /api/v1, ограничением частоты запросов и интерактивной документацией Swagger.

Структура проекта

Прежде чем писать код, договоримся, где что лежит. Каждая фича — отдельная папка, а не рассыпанный по проекту набор файлов.

• api/v1/ — все маршруты версионированы с первого дня. Добавить v2 позже можно новой папкой, а не рефакторингом.
• products/ — фичевая папка владеет роутером, контроллером, сервисом и схемой.
• middleware/ — сквозная функциональность: защита, логирование, лимиты.
• lib/ — утилиты без привязки к фреймворку.

Разделяем ответственность

Самая частая ошибка в Express-приложениях — бизнес-логика внутри обработчика маршрута. Там же появляется валидация, работа с базой данных и формирование ответа. При росте проекта такой файл становится опасным для изменений.

Роутер знает только «куда идти»

Промежуточный обработчик валидации

Промежуточный обработчик validateRequest проверяет body, params и query до попадания в контроллер. Если данные не проходят проверку, ошибка передаётся в централизованный обработчик.

Контроллер переводит HTTP в вызовы сервиса

Контроллер не знает, где хранятся товары. Его задача — извлечь параметры из запроса, вызвать сервис и вернуть ответ. Всё остальное передаётся в централизованный обработчик ошибок через next(error).

Сервис содержит бизнес-логику

Сервис не зависит от HTTP. Когда придёт время заменить хранилище в памяти на настоящую базу данных, потребуется поправить только этот файл.

Валидация на границе с Zod

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

Zod даёт две вещи сразу: проверку во время выполнения и типы TypeScript, выведенные из одной схемы. Промежуточный обработчик validateRequest проверяет body, params и query до того, как запрос попадёт в контроллер. Если данные невалидны, дальше они не идут.

Единый обработчик ошибок

Разбросанная обработка ошибок — один из главных источников хаоса: где-то возвращается { error: '...' }, где-то { message: '...' }, а где-то случайно отдаётся HTML-страница. Решение — один обработчик, через который проходят все исключения.

Теперь клиент всегда получает предсказуемую форму ответа, а добавление логирования или отправки ошибок в мониторинг — однострочное изменение в одном месте.

Единый формат ответов

Успешный ответ всегда выглядит как { success: true, data: ... }, а ошибка — как { success: false, error: { code, message, details } }. Фронтенд или сторонний интегратор знает, чего ожидать от любого эндпоинта.

Версионирование API

Версионировать API с первого дня стоит недорого. Добавить версию позже — значит ломать существующих клиентов или городить сложную миграцию.

Новая версия — новая папка src/api/v2/ и новый префикс. Старые клиенты продолжают работать на /api/v1.

Ограничение частоты запросов

Rate limiting защищает API от случайных и намеренных перегрузок. Настроить его в Express помогает пакет express-rate-limit.

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

Документация OpenAPI и Swagger

API без документации годится только для автора. С помощью swagger-jsdoc и swagger-ui-express можно получить интерактивную документацию прямо из JSDoc-комментариев в роутерах.

Совет:
Держите описания эндпоинтов в одном файле с маршрутами, а glob в swagger.ts настройте на файлы, доступные во время работы приложения. Лучше генерировать спецификацию на этапе сборки, чем полагаться на исходники TypeScript.

Fastify и NestJS: альтернативы Express

Всё, что мы разобрали, работает и в Express. Но если вы начинаете проект с нуля, стоит взглянуть на альтернативы.

• Fastify — быстрее Express в бенчмарках (порой в два раза), имеет встроенный логгер Pino и валидацию по схеме. Разделение слоёв остаётся на совести разработчика.
• NestJS — популярен в крупных компаниях: слои модулей, контроллеров и сервисов навязаны архитектурой, что упрощает введение новых разработчиков в проект.
• Express — остаётся лучшим выбором, если вы присоединяетесь к существующему проекту или команда уже знает экосистему.

Архитектурные принципы — разделение слоёв, единый формат ошибок, валидация на границе — не зависят от фреймворка. Меняется только синтаксис.

FAQ

Минимальный набор для старта

Для самостоятельного запуска понадобятся базовые зависимости и алиасы путей в tsconfig.json. Объявите @/* на папку src, и примеры заработают без ручных правок импортов.

Выводы

Чистая структура API — это не переусложнение. Это минимум, при котором бэкенд можно поддерживать нескольким людям.

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

Если начинаете новый Node.js-проект, не откладывайте структуру «на потом». А в существующем — попробуйте вынести валидацию в схему и собрать ошибки в одном обработчике. Потом всегда дороже.

Источники

Идеи и примеры в статье основаны на материале Gavin Cettolo «Clean API Design in Node.js: A Practical Guide» (dev.to).

• Базовые знания HTML и CSS
• Базовое понимание веб-компонентов
• Установленные Node.js и npm
• Умение работать в терминале на уровне, достаточном для установки пакетов
• Базовые знания конфигурационных файлов и JSON
• Понимание революционной идеи о том, что <button> — это не <div>

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

Okayyyyylet’sgo.

Фреймворк-независимые компоненты

Из всех недавних хайпов/пузырей/назовите их как хотите в мире технологий тот, что одновременно волновал и ставил в тупик меня в равной степени, — это бум дизайн-систем. Общая концепция определённо фантастическая, и почти любая команда или проект могут извлечь пользу из какой-либо формы централизованного хранилища дизайнерских решений. Но, как и любой другой бум, он породил много странностей. Люди сошлись на определённых способах восприятия дизайна в «эпоху дизайн-систем», слайды Atomic Design в каждой конференц-презентации стали мемом, а дизайн-токены стали целой личностью для некоторых.

Этот пост — не обо всех странностях, но нам нужно опереться на что-то более конкретное, чем крутая технология — это круто. И одна из моих наименее любимых странностей из курса «Дизайн-системы: странности 101» довольно специфична, но при этом является источником настоящей физической боли для меня: библиотеки компонентов, привязанные к конкретному фреймворку.

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

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

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

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

Принципы

Сначала рассмотрим несколько принципов. Если они вам близки — читайте дальше; если нет — можете закрыть вкладку, заварить чай и заняться своими делами.

Минимально возможный уровень

Хотя существует масса инструментов, которые превращают компоненты для конкретного фреймворка (давайте будем честны — почти всегда это React) в веб-компоненты, я не думаю, что такой подход соответствует тому, что мы говорим, что хотим от наших библиотек компонентов и паттернов по духу.

Когда мы создаём компоненты и проектируем API компонентов, мы разрабатываем некоторые из самых атомарных элементов дизайн-системы. В таком сценарии, на мой взгляд, есть явная, ощутимая польза от работы максимально близко к платформе доставки. Для веб-продуктов это означает работу непосредственно с веб-стандартами.

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

Максимально простые компоненты

Компоненты должны быть максимально примитивными. Даже самый, казалось бы, сложный компонент можно представить как очень простую конечную машину состояний. Мне ещё не встречался компонент, который нельзя было бы выразить таким образом, и вам не нужно по умолчанию обращаться к раздутому фреймворку для простых вариантов компонентов и изолированного состояния.

Я бы даже сказал, что многие реактивные компоненты — это антипаттерн. Реактивность обычно означает логику, и очень часто это приводит нас в область «бизнес-логики» и общего состояния на уровне контейнера или приложения. Простая реактивность на уровне компонента часто необходима — представьте кнопку, которая показывает спиннер загрузки, пока что-то обрабатывается, и возвращается в исходное состояние, когда всё готово, — но добавление тонн состояний и реактивности в изолированном коде компонента всегда кажется мне красным флагом.

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

Максимально устойчиво к будущему

Устоявшиеся фреймворки со временем становятся устаревшими технологиями. Учитывая всю работу по «переписыванию Angular-проектов на React», на которой некоторые из нас спокойно прожили целых два года, мы должны это понимать. Сам React становится (можно спорить, уже стал) устаревшей технологией, а «переписывание нашего React-приложения на Solid/Svelte» — теперь обычное дело. Я вполне ожидаю, что это будет повторяться до тошноты.

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

Фреймворки тоже по-настоящему замечательны, когда используются правильно. Говоря по опыту, попытка написать состоятельные, реактивные приложения на ванильном HTML, CSS и JS — закаляющая, но в конечном счёте неразумная задача. Однако примитивные компоненты — это не сложные, состоятельные, реактивные веб-приложения. Это маленькие куски атомарного веб-кода, и создавать их со всеми накладными расходами и своеобразиями полноценного фреймворка — это просто приглашение к будущему устареванию.

Создавая непосредственно с помощью веб-стандартов, мы получаем более низкоуровневое понимание того, как работают наши компоненты, встроенную защиту от будущего, избегая модного фреймворка, и по сути более прогрессивную, доступную (или, по крайней мере, более легко делаемую доступной) и нативную для веба библиотеку компонентов.

Разделяя ваши атомарные компоненты дизайн-системы от ваших компонентов приложения, вы получаете лучшее из обоих миров: переносимые, примитивные компоненты на уровне системы; сложные и реактивные компоненты и обёртки на уровне приложения.

Таким образом, когда вам действительно понадобится переписать приложение на Solid/Svelte, вам хотя бы не придётся переписывать всю библиотеку компонентов вместе с ним.

Принимать решения в коде

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

Как человек, который по сути больше дизайнер, чем разработчик, я создал и работал с более чем дюжиной «дизайн-систем» в Figma. Как человек, который также проводит гораздо больше времени в коде, чем в инструментах дизайна, я считаю себя вправе сказать, что ни одна из них не отражала того, чем должна быть хорошая системная основа. Это не укол в сторону дизайнеров, которые не пишут код, скорее просто показывает, насколько сложной сами инструменты делают эту часть нашей работы.

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

Так же и браузер, но я рискую укрепиться на том самом холме.

Окончательные системные дизайнерские решения должны приниматься в браузере. Токены цвета могут использовать современные цветовые пространства. Токены размеров и отступов должны выражаться в относительных единицах, где это возможно. Почти каждый тип токена может выиграть от какой-либо математики, включая логарифмические шкалы для типографики или программные сдвиги оттенка и светлоты для цветов. API компонентов также следует строить с помощью надёжных, хорошо типизированных определений. Инструменты дизайна могут предложить лишь подобие этих концепций.

Если вы начинаете с Figma — это вполне нормально, но это ужасный источник истины. Воспринимайте свой инструмент дизайна как точный инструмент прототипирования, а не как конечную цель для дизайнерских решений.

Документировать по ходу разработки

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

Мне нравится идти дальше и разворачивать библиотеку компонентов прямо в документирующем фреймворке вроде VitePress, активно создавая человекочитаемую документацию параллельно с разработкой самих компонентов. Это не только в итоге станет «официальной» документацией дизайн-системы, но и позволит проверить, насколько переносимы ваши компоненты.

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

Давайте создадим (и задокументируем)

Ладно, хватит болтать, давайте на самом деле создадим что-то практичное. Мы соберём основы для централизованной, независимой от фреймворка библиотеки компонентов. Мы будем прорабатывать документацию по мере создания компонентов, что даст нам действительно чистый тестовый стенд для самих компонентов. Настоящий порочный круг, если таковой вообще был.

Вот что у нас будет в конце этой статьи:

• Основа для нашей гибридной библиотеки компонентов/документации «всё-в-одном» дизайн-системы
• Стильная, хорошо задокументированная кнопка как веб-компонент
• Развёртываемый сайт документации, который показывает, как замечательна наша кнопка
• Готовая к продакшену библиотека компонентов, которую можно опубликовать в вашем любимом пакетном менеджере

Нам действительно нужно беспокоиться только о двух инструментах: Elena для сборки и распространения нашей библиотеки компонентов и VitePress для создания нашей документации.

Elena

Клей для всего этого проекта — Elena. Фантастическая библиотека от непобедимого Ariel Salminen для создания прогрессивных веб-компонентов. Я не буду углубляться в философию того, что означает «прогрессивный» в этом контексте, потому что это уже исключительно хорошо задокументировано самим Ariel.

Elena — это крошечная библиотека, которая делает Just Enough Abstraction™ поверх стандартных веб-компонентов. Мы получаем такие вещи, как props (отражаемые как пользовательские атрибуты), изолированную реактивность, методы жизненного цикла и даже классные штуки вроде миксинов для компонуемости. Мы не будем углубляться слишком сильно в Elena, но следите за ходом мысли и, если вам понравятся основы, я очень рекомендую погрузиться во всё, что она предлагает. Это круто.

Цитата из документации Elena:

[Elena] берёт на себя межфреймворковую сложность (синхронизация prop/атрибута, делегирование событий, совместимость с фреймворками), чтобы вы могли сосредоточиться на создании компонентов, а не на инфраструктуре.

Именно этого я и хочу от такого инструмента: позвольте мне писать код, не абстрагируйте веб-стандарты, разберитесь со всей странной ерундой, которую я не хочу трогать.

VitePress

Я не буду тратить много времени на VitePress, потому что, честно говоря, это просто самое удобное готовое решение для документации, которое не называется Storybook. Пара npm install — и у нас есть надёжное, основанное на Markdown решение для документации, готовое к работе.

Позже мы сделаем несколько классных штук с VitePress, JSDoc и нашим сгенерированным Elena манифестом пользовательских элементов, что поможет ускорить процесс документирования, но, честно говоря, иметь где-то документировать гораздо важнее, чем то, во что мы документируем.

Структура проекта

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

У нас по сути будет что-то вроде монорепозитория: Elena будет делать своё дело на уровне компонентов, а сам сайт документации будет статически генерироваться с помощью VitePress.

Создание каркаса проекта

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

Для начала создадим папку проекта:

Замените my-ds на любое название, которое хотите дать своему проекту.

Затем инициализируем npm:

Команда npm init -y создаст файл package.json в корне проекта. Эта корневая папка напрямую ничего не будет делать — она просто склеивает наши компоненты и документацию вместе в монорепозитории.

Приведём в порядок наш package.json:

Здесь происходит кое-что, что пока не имеет особого смысла (и даже не будет работать) — это станет понятно чуть позже. Настройка workspaces позволит нам обращаться со сборкой библиотеки компонентов как с пакетом, не публикуя его, а скрипты dev, а также различные watch и build позволят нам отслеживать и собирать либо документацию, либо компоненты (либо оба варианта одновременно с помощью команды dev).

Кстати, давайте установим пару штук:

Это установит concurrently, который позволит нам запускать команду watch Elena и команду dev VitePress одновременно. Мы будем держать её запущенной, пока работаем. Также установится VitePress и его тема по умолчанию. Если хотите заморочиться — можете использовать другую тему.

Настройка VitePress

Настроим документацию. Для начала создадим папку docs:

Затем создайте docs/.vitepress/config.mjs:

Проверьте расширение!Обратите внимание: мы используем .mjs, а не .js — это заставляет Node трактовать файл как ESM. Это необходимо, потому что мы импортируем из vitepress. Вам не обязательно знать, что это значит. Честно говоря, я не уверен, что сам это понимаю. Просто убедитесь, что используете .mjs. Ладно, спасибо.

Здесь мы используем postIsolateStyles, чтобы ограничить область действия встроенных стилей .vp-doc VitePress и не дать им просочиться в наши примеры компонентов. Без этого встроенные стили VitePress могут переопределять стили ваших компонентов (включая инкапсулированные сбросы) из-за того, как Vite внедряет таблицы стилей во время выполнения.

Далее создайте минимальный docs/index.md, чтобы у VitePress была домашняя страница:

Сейчас хороший момент, чтобы проверить, всё ли работает:

Вы должны увидеть очень простой локальный сайт на VitePress! По умолчанию он будет доступен по адресу http://localhost:5173/.

Настройка Elena

Теперь, для MVP нашей дизайн-системы, давайте установим Elena. Мы будем использовать Elena для создания компонентов и в конечном итоге распространять их в виде пакета. Именно здесь некоторые вещи из корневого package.json начинают обретать смысл.

Начнём с создания папки компонентов и инициализации npm для нашего пакета компонентов:

Далее отредактируйте packages/components/package.json:

Затем установите Elena:

Это установит Elena, её бандлер и CLI-инструмент.

Мы будем использовать CLI-инструмент Elena для создания каркаса наших компонентов. По сути, он проведёт нас через создание компонента, позволяя запустить команду, которая генерирует нужную папку и создаёт js- и css-файлы для любого компонента, который мы захотим создать. Подробнее об этом позже!

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

Создайте конфиг Elena по пути packages/components/elena.config.mjs:

Это говорит Elena, где искать наши компоненты (src), куда выводить собранные компоненты (dist) и где искать точку входа нашей библиотеки (src/index.js). Обратите внимание: все эти пути относительны директории packages/components, а не корня проекта. Наши инструменты Elena и библиотека компонентов самодостаточны.

Эта точка входа важна, если мы хотим импортировать все наши веб-компоненты через bundle.js, который генерирует Elena. Пока что создадим пустую.

Создайте packages/components/src/index.js. Пока что он может быть просто пустым или содержать комментарий-заглушку:

По мере создания компонентов мы сможем добавлять соответствующие export в этот файл, чтобы они попадали в наш production-бандл.

Убедитесь, что Elena работает: перейдите в корень проекта и выполните:

К сведениюЕсли вы запускаете это на Mac с Apple Silicon, то, скорее всего, столкнётесь с ошибкой. По моему опыту, это из-за зависимости Elena (lightningcss), которая немного кривая (простите за такую техническую терминологию). Если при попытке сборки вы получаете ошибку 'MODULE_NOT_FOUND', выполните следующее из корня проекта: Code languagebashCopy to clipboard rm -rf node_modules packages/components/node_modules package-lock.json && npm install Это уничтожит папку node_modules и переустановит зависимости, разложив всё по своим местам. Если эта ошибка случилась однажды, то, скорее всего, придётся запускать это каждый раз при установке новой зависимости. Мне жаль. Управление пакетами — как всегда, Очень Приятное Занятие.

И выдохнем…

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

Наша корневая папка по сути просто контейнер, так что особо беспокоиться о ней не стоит.

Наша папка docs — это место, где будет жить всё, связанное с VitePress. В конечном итоге это станет полноценной документацией дизайн-системы, и мы будем использовать её для предпросмотра и документирования наших компонентов по мере их создания.

Наша папка packages/components — это место, где мы будем работать со всем, связанным с компонентами. Папка packages/components/src — это место, где мы будем создавать компоненты, а index.js в ней — точка входа нашей библиотеки, где мы просто будем export'ировать любые компоненты, которые хотим включить в бандл.

Наша папка dist в packages/components — это место, где будут храниться собранная библиотека компонентов и манифест кастомных элементов. Затем мы сможем импортировать отсюда в наш проект VitePress так, будто это установленный пакет.

Однако чтобы дойти до этого, нам нужны какие-то реальные компоненты для распространения.

Создаём наш первый компонент

Теперь, когда всё настроено, мы наконец-то можем начать создавать компоненты! В этой статье мы будем держать всё просто и сосредоточимся на, возможно, самом распространённом компоненте: прекрасной кнопке.

По невероятному стечению обстоятельств ваш собственный веб-мастер Piccalilli, Andy Bell, уже написал великолепную статью о создании компонентов кнопок на стандартном HTML и CSS. Мы будем опираться на эти принципы здесь, с небольшими изменениями, чтобы получить максимум от нашей настройки веб-компонентов.

Статья Andy отлично объясняет почему стоят за многими семантическими и структурными решениями, касающимися самих кнопок, поэтому я не буду углубляться в это слишком сильно. Andy прошёл путь, чтобы мы могли бежать. Какой человек.

Композитные, примитивные и декларативные компоненты

В основе концепции Elena «прогрессивные веб-компоненты» лежит разделение компонентов на три основные категории: композитные, примитивные и декларативные. Документация Elena прекрасно объясняет различия подробно, но важно помнить, что все это всё ещё просто веб-компоненты. Нас не заставляют принимать нестандартные концепции или методы, скорее нас поощряют думать о наших компонентах в этих терминах.

Я позволю документации Elena сделать основную работу с этими определениями, но вот основные моменты:

• Композитные компоненты оборачивают и расширяют свой внутренний HTML. Они отлично подходят для таких вещей, как слайдеры, аккордеоны, карточки и многослойные макеты — там, где вы чаще всего позволяете HTML и CSS делать основную работу и расширяете возможности с помощью JS в нужной области. Композитные компоненты также отлично подходят для паттернов, где мы можем захотеть объединить примитивные компоненты и HTML в переиспользуемые «макро» компоненты с определённым поведением. Подумайте о таких вещах, как диалоги, fieldsets и баннеры уведомлений — там, где структура и поведение фиксированы, но содержимое внутри остаётся гибким и определяется потребителем.
• Примитивные компоненты объявляют и рендерят свой собственный HTML и поставляются с собственной функцией render(). Это, вероятно, самые распространённые компоненты, которые мы будем использовать в дизайн-системе — подумайте о таких вещах, как кнопки, поля ввода, индикаторы загрузки, бейджи и т.д.
• Декларативные компоненты — это комбинация обоих типов и могут объединять Light DOM и декларативный Shadow DOM. Если мы не знаем, что нам действительно нужна инкапсуляция с Shadow DOM, мы можем практически игнорировать его для библиотек компонентов. Я не углублялся слишком сильно в это, но мои первые мысли таковы, что декларативные компоненты были бы отличны для полностью инкапсулированных компонентов, таких как веб-редакторы контента или блоки кода с подсветкой синтаксиса/редакторы, где инкапсуляция и изоляция часто критичны.

На этот раз мы строим примитивный компонент. Наша кнопка будет объявлять и рендерить свой собственный HTML, и мы будем стилизовать её с помощью CSS в ограниченной области.

Создаём каркас компонента

Мы будем использовать CLI-помощник Elena для генерации папки и файлов, которые нам нужны для нашего компонента.

Пространства имён компонентов и пользовательские элементыМы используем сугубо учебный префикс my- для нашей кнопки, но зачем вообще нужен префикс? Это возвращает нас к тому, как пользовательские элементы требуют наличия - в имени тега, чтобы избежать конфликтов с нативными HTML-элементами. Если бы у нас был полный контроль, и мы создали компонент <button>, мы бы конфликтовали с настоящим HTML-элементом <button>, и у нас было бы Очень Плохое Время. Поэтому мы просто не можем этого делать — все наши пользовательские элементы должны быть в формате <{prefix}-{component}>.Жёсткого требования, чтобы наши файлы тоже были с дефисом, нет, но лично мне нравится аккуратность, когда имена файлов и папок совпадают с нашим фактическим элементом. Так что выберите префикс и придерживайтесь его. Для моей дизайн-системы Mindful Design я использую префикс md- — так что все мои пользовательские элементы выглядят примерно как <md-button>, <md-card> и т.д. Web Awesome использует wa-. Вы можете использовать всё, что пожелает ваше сердце. Главное — будьте последовательны.

Из папки packages/components выполните:

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

• Props
• CSS-переменные
• CSS-инкапсуляция
• Комментарии в коде

Нажмите Enter, затем выберите JavaScript в качестве языка.

Установите выходную директорию в src/. По умолчанию Elena использует src/components/, но нам не нужен такой уровень вложенности.

Это создаст каркас наших файлов с несколькими примерными значениями и комментариями, так что мы не будем смотреть на пустые файлы. Нажмите Enter после выбора функций, языка и директории, и Elena сгенерирует папку my-button с соответствующими JS и CSS файлами. О стилизации мы позаботимся позже, сейчас мы хотим спроектировать API нашего компонента.

Откройте следующий файл:

Здесь происходит много всего для простого boilerplate, но мы разберём каждый раздел по мере продвижения!

Добавление props

Компонентные props позволят нам управлять стилизацией и поведением компонента декларативным образом. Затем мы можем использовать эти props для создания вариантов наших компонентов. Для нашей кнопки давайте упростим и используем следующие props:

• variant: стилевой вариант нашей кнопки, например «primary», «danger»
• disabled: отключена ли кнопка или нет
• href: куда должна вести кнопка, также определяет, будет ли кнопка рендериться как ссылка или как кнопка

Это небольшое подмножество props, которые потребуются кнопке в продакшене, но этого достаточно, чтобы двигаться дальше. Если после этого вы почувствуете себя уверенно, можете вернуться и добавить больше props — size или icon prop были бы отличной отправной точкой!

Давайте добавим эти props в наш компонент кнопки:

Объявление static props позволяет нам определить конечный массив props, которые будет принимать наш компонент. По умолчанию все эти props будут отражаться на нашем отрендеренном компоненте как HTML-атрибуты. Вам почти всегда нужно, чтобы это было так, особенно если вы используете нестандартные атрибуты вроде disabled, download и т.д.

Прямо под этим массивом вы найдёте заготовленные значения props по умолчанию, каждое с небольшим комментарием сверху. Давайте последуем примеру Elena и установим значения по умолчанию для добавленных нами props:

Комментарии над каждым определением — это JSDoc-комментарии. Они могут выглядеть немного непривычно, но позволяют документировать наши компоненты и props и могут служить источником истины для документирования API наших компонентов. Это также даёт нам немного «мягкой типизации» без необходимости использовать TypeScript. Большинство IDE будут подсвечивать или предупреждать вас, если вы установите prop в значение/тип, не указанный в синтаксисе JSDoc.

В приведённом выше примере мы определяем наш prop variant, задаём ему значение по умолчанию «default» и мягко типизируем его с помощью определения @type. В данном случае мы принимаем только одно из четырёх перечисленных значений.

На этом этапе это может показаться немного бессмысленным, но следите за своими JSDoc-комментариями по мере создания компонентов. Мы будем использовать их позже. Пока мы на этом, мы могли бы также задать более точное описание для нашего компонента.

Измените верхний комментарий в следующем файле:

Мы также удалили определения @cssprop из этого комментария. Они были сгенерированы, потому что мы выбрали «CSS Variables» при создании нашего компонента, и позволяют нам раскрыть кастомные свойства, используемые для стилизации наших компонентов. Если вы работаете над темизируемой или headless библиотекой компонентов, вы, возможно, захотите оставить их, в противном случае я предпочитаю пропускать определение этих свойств и не раскрывать их в своей документации.

Давайте взглянем на нашу функцию render():

Если у вас нет тяжёлого случая React Brain, вы, возможно, заметите хотя бы одну из пары проблем: во-первых, button — это не div. Дико, правда? Это не вина Elena, мы просто создали базовый компонент, и div — это, безусловно, самый распространённый HTML-элемент. Нам нужно самим отрендерить правильную, семантическую, доступную разметку.

Во-вторых, мы только что добавили href как prop, а это атрибут a, а не button. Нам нужно условно рендерить либо a, либо button в зависимости от того, установлен ли href.

Условный рендеринг

Дискуссия «должны ли ссылки когда-либо стилизоваться как кнопки?» старше, чем бородка вашего отчима, и точно так же как-то ещё сохраняется сквозь века. Я слишком стар и устал, чтобы беспокоиться об этом, а реальность такова, что кнопки-ссылки CTA — одна из самых распространённых вещей, которые вы увидите на сайте, в конкуренции только с баннерами cookie и плохой доступностью в своей повсеместности.

Так что вы будете делать это, нравится нам это или нет, и вам лучше делать это правильно.

Самый чистый подход к этому — абстрагировать наш рендеринг, добавив две новые функции:

Затем мы можем заменить функцию render() нашего компонента:

Супер просто: если href присутствует, это ссылка, если нет — это кнопка. Нам не нужно добавлять новые props, просто используем тот, что у нас уже есть.

Мы используем nothing в этой функции, и если вы попробуете собрать/запустить watch прямо сейчас, вы получите ошибку. Это потому, что nothing — это помощник Elena для безопасного рендеринга, ну, ничего.

Давайте импортируем его в начало нашей кнопки. Отредактируйте первую строку следующего файла:

Теперь давайте соберём нашу библиотеку компонентов, чтобы включить нашу новую кнопку в продакшенный bundle.js. Отредактируйте packages/components/src/index.js:

Затем из корня проекта выполните:

Если повезёт, сборка пройдёт без проблем, и мы наконец-то сможем встроить нашу кнопку в документацию.

Предпросмотр нашей кнопки

На данный момент у нас есть всё необходимое, чтобы отрендерить нашу кнопку и увидеть её на странице. Потребовалось немного настроек, чтобы дойти до этого, но мы сделали это!

Благодаря тому, как наш проект настроен, мы теперь можем подключать наши собранные компоненты так, как будто они являются отдельным пакетом. Нам просто нужно настроить VitePress для импорта бандла, который генерирует Elena, и сказать ему обрабатывать наши импортированные компоненты как веб-компоненты (по умолчанию VitePress ожидает Vue-компоненты).

Создайте docs/.vitepress/theme/index.js:

Это говорит нашей теме VitePress импортировать файлы бандла, которые сгенерировала Elena. @my-ds/components загружается асинхронно, так как это клиентская часть, а VitePress по умолчанию использует серверный рендеринг. @my-ds/components/dist/bundle.css импортируется напрямую в начале нашего файла, потому что это просто старый добрый CSS.

Примечание о серверном рендеринге (SSR)Если вы знаете, что вам нужен SSR, есть несколько способов включить его с Elena. В зависимости от вашего фреймворка/генератора сайта на выбор, вам, возможно, потребуется выполнить несколько дополнительных шагов конфигурации. Обратитесь к документации Elena за советами по SSR и на страницу интеграций с фреймворками для более продвинутых интеграций.

Далее обновите docs/.vitepress/config.mjs:

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

Теперь давайте соберём нашу фактическую документацию по кнопке. Создайте docs/components/button.md:

Это должно дать нам всё необходимое для предпросмотра нашей кнопки! Запустите процесс разработки, если вы ещё этого не сделали:

Это запустит документацию VitePress в режиме разработки и одновременно запустит скрипт watch Elena, давая нам довольно удобный опыт live-reload. Перейдите на http://localhost:5173/components/button.html, и вы должны увидеть свою прекрасную кнопку!

Держите сервер разработки запущеннымКоманда npm run dev запустит ваш dev-сервер документации и будет держать Elena в фоне, отслеживая изменения компонентов. Вы будете получать live reloads всякий раз, когда вносите изменения, и теперь вы можете плавно вносить и тестировать изменения компонентов и документации.

Если вы откроете инспектор браузера и посмотрите на отрендеренную кнопку, вы увидите что-то вроде этого:

Наш хост-элемент <my-button> оборачивает разметку из своей функции render(), и мы имеем наш первый веб-компонент, отрендеренный в браузере! Я знаю, я знаю. Это выглядит совсем не круто, но оно там есть! Давайте придадим ему стиль.

Стилизация нашей кнопки

Если вы дошли до этого места, то, возможно, заметили явное отсутствие дискуссий о дизайн-токенах. Не потому, что они неважны, а потому что управление токенами и их распространение — это крайне объёмная тема, а эта статья и без того получается очень уж длинной. Скорее всего, мы разберём рабочие процессы с токенами в отдельном посте!

Пока что мы будем придерживаться простого подхода и использовать стили с ограниченной областью видимости Elena. Это позволяет нам частично нейтрализовать каскад в CSS и гарантировать, что стили не выйдут за пределы оформления отдельного компонента.

Мы также сделаем кое-что, чего я не рекомендую для production-компонентов, особенно если вы хотите строить темизируемые дизайн-системы, наследующие разумные глобальные стили (спойлер: вы хотите), — а именно, сбросим стили компонента перед применением собственных. В итоге мы получаем компонент, который не пропускает стили наружу (благодаря ограниченной области видимости) и не позволяет глобальным стилям проникать внутрь (благодаря сбросу на уровне компонента).

Стили с ограниченной областью видимости

Откройте следующий файл:

По умолчанию Elena генерирует at-правило @scope для любого создаваемого компонента. Вы не обязаны использовать стили с ограниченной областью видимости. Важно помнить: это всё обычный CSS. Мы не делаем ничего дикого или хрупкого вроде CSS-in-JS, мы просто используем конкретную стандартную возможность CSS. Вы с таким же успехом можете писать неограниченный CSS с пространствами имён и получить в целом те же результаты.

Более того, если вам нужно поддерживать браузеры, которые не поддерживают @scope, то использование пространств имён может быть тем самым подходом, который вам нужен. Для этого примера (и для моей собственной production-работы) меня вполне устраивает @scope — я считаю его гораздо более чистым способом стилизации компонентов.

Поскольку при создании компонента мы выбрали «CSS Encapsulation», вы видите, что Elena сгенерировала следующее:

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

Примечание об инкапсулированном сбросеИспользование all: unset и display: revert сбросит любые стили, определённые до тех пор, пока эти правила не встретятся. Это не предотвратит применение дальнейших неограниченных стилей в файлах или тегах

Это не дословный перевод, а авторский разбор на основе исследования Nicolas Laurent (norswap), дополненный практическими примерами для enterprise-разработки на TypeScript.

Что такое вывод типовых переменных

В TypeScript, когда вы вызываете функцию с дженериком function foo<T>(x: T), компилятор должен понять, чему равен T. Этот процесс называется type variable inference — выводом типовой переменной. Он происходит в две фазы: сначала TypeScript собирает «кандидатов» из типов аргументов и контекста возврата, а затем «сворачивает» список кандидатов в единственный тип.

Звучит просто, но на практике алгоритм полон тонкостей: covariant и contravariant позиции, приоритеты кандидатов, странное поведение пересечений и неочевидные ограничения. Разберём всё по порядку.

TypeScript выводит типовые переменные в две фазы: сбор кандидатов из аргументов и контекста, затем свёртка списка в единственный тип.

Кандидаты делятся на ковариантные (выходные позиции) и контравариантные (входные позиции); контравариантный результат обычно побеждает.

При свёртке TypeScript ищет общий супертип в списке кандидатов, но никогда не выбирает тип, которого нет в списке.

Пересечения типов ведут себя непредсказуемо: иногда TypeScript «снимает» литеральный тип, иногда захватывает весь объект.

В generic-контексте условные типы (extends ? :) не вычисляются, что ломает инференс через Exclude и подобные утилиты.

NoInfer<T> (с TypeScript 5.4+) позволяет блокировать вывод типа из конкретной позиции — полезно для API со значениями по умолчанию.

Фаза 1: сбор кандидатов

Когда TypeScript видит вызов функции с дженериком, он сопоставляет типы аргументов (source types) с типами параметров функции (target types). Каждый раз, когда «прогулка» по типам доходит до «голого» type parameter в target, соответствующий source type записывается как кандидат.

Ковариантные и контравариантные кандидаты

Кандидаты собираются в два списка. Если type parameter находится в позиции аргумента функции или возвращаемого значения — это ковариантный (output position) кандидат. Если type parameter находится в позиции параметра callback-функции — это контравариантный (input position) кандидат.

Условные типы и infer

Когда TypeScript встречает условный тип, кандидаты собираются только из той ветки, которая теоретически может сработать. Но важно: само условие не добавляет кандидатов. Запись T extends Foo НЕ добавляет Foo как кандидат для T.

Это классическая ловушка: кандидаты собираются из одной ветки, а типовая проверка — из другой. TypeScript не вычисляет условные типы на этапе инференса.

Распределение по union

Если source type — union, а target — не «голый» type parameter, TypeScript проходит по каждой ветке union отдельно и собирает кандидатов из всех веток в один список.

Что НЕ учитывается при сборе

• Условие условного типа (только ветки).
• Constraints (<T extends Foo>) — они проверяются позже, на этапе разрешения.
• Дефолтные значения type parameter (<T = unknown>) — используются только если список кандидатов пуст.
• Супертипы source type.

Фаза 2: разрешение кандидатов

После сбора TypeScript сворачивает каждый список в единственный тип. Алгоритм зависит от вариантности и содержимого списка.

Ковариантные кандидаты

1. Если все кандидаты — литералы одного базового типа, они объединяются в union.
2. Иначе ищется кандидат, который является строгим супертипом всех остальных. Если найден — он выбирается.
3. Если нет — выполняется left-reduce: начинаем с первого кандидата, идём по списку, заменяя текущий на супертип, если встречаем его.

Важно:
Если в списке кандидатов нет общего супертипа, TypeScript выбирает первый элемент. Это частая причина неожиданных ошибок при передаче разнородных аргументов одного дженерика.

Контравариантные кандидаты

Для контравариантных кандидатов логика зеркальная: ищется общий подтип, иначе — left-reduce с подтипами. Если оба списка (ковариантный и контравариантный) непусты, контравариантный результат обычно побеждает — за исключением случаев, когда ковариантный результат является подтипом контравариантного.

Приоритеты кандидатов

Каждый кандидат помечается приоритетом. Кандидат с более высоким приоритетом стирает все кандидаты с более низким приоритетом. Основные приоритеты: None (0), NakedTypeVariable (1), MappedTypeConstraint (32), ReturnType (128), LiteralKeyof (256).

Приоритеты MappedTypeConstraint, ReturnType и LiteralKeyof — «комбинационные»: при них результатом становится union или intersection всех кандидатов, а не единственный тип.

Пересечения: загадочное поведение

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

Почему так? Это эвристики компилятора, направленные на максимизацию полезности захваченного типа. В первом случае полезнее получить весь объект, во втором — сохранить литеральную точность строки. Порядок операндов пересечения не влияет на результат.

Вывод в generic-контексте

Когда инференс происходит внутри другой generic-функции, условные типы не могут быть вычислены, потому что type variables ещё не связаны. Это ломает паттерны вроде Exclude, если вызывать их через generic-обёртку.

В типовых enterprise-проектах, где активно используются типовые утилиты для валидации API (например, в проектах на NestJS или с Zod), это ограничение часто приводит к необходимости явно прописывать generic-аргументы или реструктурировать типы.

NoInfer: как управлять выводом

Начиная с TypeScript 5.4, в языке есть встроенный вспомогательный тип NoInfer<T>. Он блокирует сбор кандидатов для T из той позиции, где используется NoInfer<T>.

Это особенно полезно в библиотечном коде, где нужно разделить «источник истины» для вывода типа и позиции, которые должны ему подчиняться.

FAQ

Выводы

Теперь вы знаете, как TypeScript выводит типы переменных: через сбор кандидатов из аргументов, свёртку списка с учётом вариантности и приоритетов, а затем проверку результата на соответствие constraints. Алгоритм вывода типовых переменных — это тщательно продуманная, но не лишённая сюрпризов система. Две фазы (сбор и разрешение), вариантность, приоритеты и эвристики для пересечений создают поверхность, которую сложно угадать интуитивно, но которую можно понять, зная правила.

Ключевые практические выводы для разработчиков:

1. Если функция принимает несколько аргументов одного дженерика — убедитесь, что они совместимы, иначе TypeScript выберет первый кандидат и отвергнет остальные.
2. Не полагайтесь на супертипы для инференса: они не попадают в список кандидатов.
3. В generic-контексте условные типы «замораживаются» — проектируйте API с этим ограничением.
4. Используйте NoInfer<T> в библиотечном коде для точного контроля над источниками вывода типов.
5. При странном поведении с пересечениями — перепишите типы явно или добавьте constraint.

Понимание алгоритма вывода типовых переменных позволяет писать более надёжные типовые абстракции и тратить меньше времени на отладку сложных generic-конструкций.

Источники:

• How TypeScript infers type variables — Nicolas Laurent (norswap)
• How TypeScript distributes unions — Nicolas Laurent (norswap)
• TypeScript Handbook: Generics

Если у вас есть примеры неожиданного поведения TypeScript с дженериками — делитесь в комментариях. Соберём коллекцию «типовых загадок» вместе.

Cloudflare приобрела VoidZero — компанию-основателя Vite, Vitest, Rolldown, Oxc и Vite+.

Вся команда VoidZero переходит в Cloudflare, включая Эвана Ю.

Проекты сохраняют открытый исходный код, лицензию MIT и независимость от поставщика.

Cloudflare выделяет $1 млн на фонд экосистемы Vite для поддержки сопровождающих.

Vite набирает около 129 млн загрузок в неделю; плагин Cloudflare для Vite — 14 млн.

Дашборд Cloudflare уже работает на Vite, а CLI компания переведёт на него в будущем.

VoidZero появилась как попытка собрать в единую экосистему наиболее востребованные инструменты фронтенд-разработки. Vite — система сборки, ставшая фактическим стандартом для современных JavaScript-приложений. Vitest отвечает за тестирование, Rolldown заменяет Rollup на Rust, а Oxc — это платформа инструментов для JavaScript/TypeScript на Rust, включающая компилятор, линтер Oxlint, форматировщик и другие компоненты.

Cloudflare подчёркивает, что не собирается перекраивать планы развития проектов под свои нужды. По аналогии с приобретением Astro ранее в этом году, команды сохраняют автономию, а код остаётся открытым. Главное отличие в том, что Vite — это не просто фреймворк, а фундамент, на котором строятся Vue, SvelteKit, Nuxt, Astro, Solid, Qwik, Angular, React Router, TanStack Start и даже Next.js — в экспериментальном проекте vinext.

Что меняется для разработчиков

В краткосрочной перспективе — ничего. Vite, Vitest, Rolldown, Oxc и Vite+ продолжат развиваться по прежним планам. Эван Ю и команда VoidZero остаются лидерами проектов. Cloudflare обещает направлять инженерные ресурсы на развитие инструментов, а не на их смену бренда или закрытие.

В долгосрочной перспективе Cloudflare намерена построить собственный CLI cf поверх Vite. Цель — чтобы команды cf dev, cf build и cf deploy чувствовали себя как расширение привычного vite dev. Это должно упростить развёртывание Vite-приложений на платформу Cloudflare Workers, сохранив при этом переносимость кода между любыми хостингами.

Почему это важно

Vite сегодня — один из немногих инструментов, которые объединяют всю JavaScript-экосистему. По данным Cloudflare, Vite набирает 129 млн загрузок в неделю, а официальный плагин @cloudflare/vite-plugin — 14 млн. С ростом ИИ-агентов, которые генерируют код и выполняют итерации с ним в цикле, скорость сборки, тестирования и линтинга становится критичной. Весь стек VoidZero оптимизирован для таких сценариев: Rust-инструменты работают на порядок быстрее аналогов на JavaScript.

Кроме того, Cloudflare выделяет $1 млн в фонд экосистемы Vite. Деньги пойдут на поддержку сопровождающих и участников — администрировать фонд будет ядро команды Vite. Это редкий случай, когда крупная инфраструктурная компания инвестирует напрямую в открытый исходный код, не пытаясь монополизировать его.

Выводы

Приобретение VoidZero — значимый корпоративный вклад в открытую инфраструктуру JavaScript. Cloudflare получает влияние на инструмент, который используют миллионы разработчиков, а сообщество — гарантии независимости и $1 млн на развитие экосистемы.

Для разработчиков практических изменений в ближайшие месяцы не предвидится: команды — на месте, а плагин для Cloudflare продолжит развиваться. Долгосрочная ставка — на унификацию CLI и углубление интеграции Vite с пограничной платформой Cloudflare.

Источник: Cloudflare Blog — VoidZero is joining Cloudflare

Хотите попробовать Vite на Cloudflare прямо сейчас — выполните npm create vite@latest, а затем npx wrangler deploy.

ESLint — это де-факто стандарт статического анализа JavaScript-кода. Инструмент работает поверх Node.js и V8, поддерживает сотни плагинов и позволяет настраивать правила под любой проект. По данным опроса State of JavaScript 2025, ESLint остаётся самым популярным вспомогательным инструментом среди фронтенд-разработчиков.

Новый проект развивается в рамках экосистемы Oxc, поддерживаемой командой VoidZero.

Oxlint на Rust обгоняет ESLint в 50–100 раз на крупных репозиториях вроде Vue Core и React Router.

Из коробки включено 107 правил, тогда как ESLint требует ручной настройки даже для базовых сценариев.

Поддержка ESLint-плагинов экспериментальная, но список доступных правил постоянно растёт.

Миграция возможна постепенно: оба линтера можно запускать параллельно.

Если ваш проект завязан на редкие плагины или пользовательские правила — спешить не стоит.

Почему ESLint начинает раздражать

Несмотря на зрелость экосистемы, у ESLint накопился приличный багаж архитектурных ограничений:

• Производительность. Код ESLint выполняется в однопоточном режиме поверх JavaScript-движка. В небольших проектах это незаметно, но в монорепозиториях с сотнями тысяч строк проверка легко растягивается на две минуты и больше.
• Конфигурационный ад. Новичкам приходится разбираться в иерархии конфигов, flat config, shared presets и compatibility layers. Документация исчерпывающая, но порог входа остаётся высоким.
• Минимум из коробки. Базовая установка ESLint практически ничего не проверяет. Для получения хоть какой-то пользы нужно ставить плагины, изучать правила и собирать конфигурацию с нуля — в отличие от Prettier или Biome, которые работают сразу после установки.

Чем Oxlint лучше привычного линтера

Скорость, которую можно измерить

Главное преимущество Oxlint — скорость. В тестах на репозитории Vue Core с type-aware правилами Oxlint справляется за 1,3 секунды, тогда как ESLint с typescript-eslint тратит 133,8 секунды. Это почти в 100 раз быстрее. На репозитории React Router разрыв меньше, но всё равно впечатляет: 435 мс против 29,5 с — ускорение в 68 раз.

Type-aware линтинг без тормозов

ESLint для type-aware правил использует typescript-eslint, который перед проверкой запускает полный анализ через tsc. Это наследует все накладные расходы компилятора TypeScript. Oxlint делает это иначе: type-aware функциональность реализована через oxlint-tsgolint на Go, который в связке с TypeScript 7 и компилятором tsgo работает в 20–40 раз быстрее привычного пайплайна.

Настройка за минуту, а не за час

После установки Oxlint сразу активирует 107 правил. Конфигурация проще, документация понятнее, а сообщения об ошибках структурированы так, что и человек, и LLM-ассистент разберутся с первого взгляда.

Постепенная миграция без боли

Oxlint не требует выбросить ESLint в один день. Инструменты можно запускать параллельно: Oxlint берёт быструю проверку на pre-commit, а ESLint остаётся в CI до полного перехода. Экспериментальная поддержка JavaScript-плагинов ESLint уже работает, хотя и не покрывает всю экосистему.

Реальные цифры: бенчмарки на популярных репозиториях

Автор оригинального материала воспроизвёл тесты на ноутбуке HP EliteBook 1040 G7 (16 ГБ ОЗУ, 4 физических ядра, 8 потоков). Результаты для Vue Core с type-aware правилами:

Результаты для React Router (без type-aware правил):

Цифры подтверждают заявленные разработчиками 50–100-кратное ускорение. Для разработчика это разница между «пойду за кофе, пока линтер работает» и «результат на экране мгновенно».

Когда ESLint всё ещё нужен

Несмотря на впечатляющие цифры, спешить со сносом ESLint не всегда разумно. Вот сценарии, где старый инструмент остаётся предпочтительнее:

• Редкие плагины и пользовательские правила. Если ваш проект завязан на специфические ESLint-плагины, которых ещё нет в Oxlint, миграция потребует дополнительной работы.
• Малые проекты. В репозиториях до 10–20 тысяч строк разница между 1 секундой и 30 секундами линтинга не критична.
• Сложные рабочие процессы. Глубокая интеграция ESLint в CI/CD, пользовательские форматтеры и специфические пайплайны могут быть дорого переносить.
• Сообщество и экосистема. ESLint остаётся доминирующим линтером. Вокруг него больше обучающих материалов, примеров конфигураций и поддержки со стороны LLM-ассистентов.

Как мигрировать с ESLint на Oxlint

Команда Oxlint подготовила утилиту @oxlint/migrate, которая автоматически преобразует конфигурацию ESLint в формат Oxlint. Выбор пути зависит от текущего состояния проекта:

1. Для ESLint v9/v10+ с flat config: запустите npx @oxlint/migrate — утилита преобразует поддерживаемые правила и сообщит о несовместимых.
2. Для ESLint v8 и старше (в v10 поддержка legacy-конфигов полностью удалена): сначала мигрируйте на flat config через npx @eslint/migrate-config, затем примените @oxlint/migrate.
3. Если нужны type-aware правила: добавьте флаг --type-aware к команде npx @oxlint/migrate и установите oxlint-tsgolint.
4. Для экспериментальной поддержки JS-плагинов: используйте флаг --js-plugins в команде npx @oxlint/migrate.
5. Не уверены в безопасности? Запустите оба линтера параллельно на несколько недель и сравните результаты.

Совет:
Начните миграцию с новых модулей или микрофронтендов, а не с устаревшего кода, где линтер и так давно отключён.

Выводы

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

Для большинства современных проектов Oxlint — это уже не перспективная альтернатива, а вполне зрелый инструмент по умолчанию.

Источник: LogRocket — Retire ESLint: How (and why) to migrate to Oxlint

Репозиторий проекта: github.com/oxc-project/oxc. Документация: oxc.rs.

Попробуйте запустить npx @oxlint/migrate на своём проекте и сравните цифры. Возможно, вы больше никогда не захотите ждать, пока закончится npm run lint.

Что такое поля форм

Поля форм — это интерактивные элементы HTML, через которые пользователь взаимодействует с веб-страницей. Браузер отображает их по-разному в зависимости от типа: для email показывает клавиатуру с символом @, для даты — календарь, для файла — диалог выбора документа.

Главное правило: под каждую задачу существует своё поле. Использовать универсальный <input type="text"> везде — значит лишать пользователя встроенных удобств браузера.

{'id': 'a94adbf9d2', 'data': {'text': 'Правильный тип input — залог удобства: браузер сам подставит нужную клавиатуру и проверит формат.'}, 'type': 'paragraph'}

{'id': 'd3748dda0e', 'data': {'text': 'Label обязателен для каждого поля: связывайте его через атрибут for с id поля.'}, 'type': 'paragraph'}

{'id': 'c924682827', 'data': {'text': 'Группируйте связанные поля в <fieldset> с <legend> — это помогает средствам чтения с экрана и структурирует форму.'}, 'type': 'paragraph'}

{'id': '49afc5a27c', 'data': {'text': 'Не забывайте name: без него данные не попадут в запрос при отправке формы.'}, 'type': 'paragraph'}

{'id': 'ab33c8052b', 'data': {'text': 'Используйте <button type="submit"> вместо устаревшего <input type="submit"> — это гибче и семантичнее.'}, 'type': 'paragraph'}

Основные элементы форм

input — универсальный инструмент ввода

Элемент <input> — самый распространённый в формах. Его внешний вид и поведение полностью зависят от атрибута type. Браузер поддерживает свыше 20 типов: от классического text до специализированных date, tel, range и даже color.

Когда вы выбираете конкретный тип, браузер берёт на себя три задачи: отображает подходящий интерфейс, показывает оптимальную экранную клавиатуру на мобильных устройствах и применяет встроенную проверку. Например, type="email" проверит наличие символа @ до отправки на сервер.

Вот типы input, которые стоит знать каждому фронтенд-разработчику:

• text — текстовая строка, базовый тип.
• email — проверяет наличие @ и домена, показывает email-клавиатуру.
• tel — цифровая клавиатура на мобильных устройствах.
• number — ограничивает ввод числами, добавляет стрелки.
• date — нативный календарь браузера.
• checkbox и radio — выбор одного или нескольких вариантов.
• file — загрузка файлов с нативным диалогом выбора.
• range — ползунок для выбора значения из диапазона.
• color — нативный выбор цвета.
• search — поле поиска с кнопкой очистки.

Атрибут required делает поле обязательным для заполнения, а pattern позволяет задать регулярное выражение для проверки введённых данных без JavaScript.

label — связываем текст с полем

Без подписи поле ввода теряет смысл. Элемент <label> решает эту задачу и одновременно делает форму доступной для пользователей с ограничениями зрения.

Есть два способа связать label с полем. Первый — явный: атрибут for на label должен совпадать с id на input. Второй — вложенный: input размещается внутри label. Оба варианта работают, но явная связь через for гибче: позволяет располагать label и input в разных частях разметки.

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

textarea — когда одной строки мало

Для длинных текстов — комментариев, отзывов, описаний — используйте <textarea>. В отличие от <input>, он поддерживает переносы строк и растягивается по содержимому. Атрибуты rows и cols задают начальные размеры, а CSS — финальное оформление.

select и datalist — выбор из вариантов

Когда нужно предложить пользователю готовый список вариантов, на помощь приходит <select>. Он отображает выпадающий список, в котором можно выбрать один или несколько пунктов. По умолчанию выбран первый элемент, но через атрибут selected можно задать другой.

Альтернатива — <datalist>. Он работает как автодополнение: пользователь может как выбрать вариант из списка, так и ввести свой собственный текст. Это удобно для полей вроде «профессия» или «название компании», где невозможно предусмотреть все варианты.

fieldset и legend — группируем поля

Формы с десятком полей выглядят как стена текста. Чтобы структурировать их, используйте <fieldset> с обязательным дочерним элементом <legend>. Такая группировка помогает пользователям ориентироваться и критична для средств чтения с экрана: они объявляют legend перед каждым полем в группе.

ARIA-атрибуты для сложных форм

Для скринридеров и пользователей с ограничениями зрения важно не только правильное использование label, но и дополнительные ARIA-атрибуты. Например, aria-required="true" сообщает о необходимости заполнения, а aria-describedby связывает поле с текстом подсказки или сообщения об ошибке.

Атрибут aria-live="polite" на контейнере с ошибками позволяет скринридеру озвучить сообщение без прерывания текущего действия пользователя. Это особенно важно для динамических форм, где ошибки появляются после асинхронной проверки на сервере.

Как отправить форму

Для отправки данных используйте <button type="submit">. Это семантично, стилизуется гибче, чем <input type="submit">, и поддерживает вложенный HTML-контент — например, иконку рядом с текстом.

Важно:
Если у кнопки не указан атрибут type, браузер считает её кнопкой отправки по умолчанию. Чтобы избежать случайной отправки, всегда явно указывайте type="button" для кнопок, которые не должны отправлять форму.

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

Чек-лист: правильная форма за 5 минут

• Каждое поле имеет связанный <label> через for и id.
• Выбран подходящий type для <input> — не везде text.
• У всех полей есть атрибут name, иначе данные не уйдут на сервер.
• Связанные поля объединены в <fieldset> с <legend>.
• Для длинных текстов используется <textarea>, а не многострочный input.
• Кнопка отправки — <button type="submit">, а не устаревший input.
• Форма работает без JavaScript: базовая проверка и отправка происходят на уровне HTML.

Выводы

Поля HTML-форм — это не просто визуальные элементы, а полноценный интерфейс взаимодействия пользователя с вашим приложением. Правильный выбор типов input, связь через label, группировка в fieldset, ARIA-атрибуты и семантичная кнопка отправки — всё это влияет на удобство, доступность и конверсию.

Доступность не добавляется в проект в конце — она закладывается на этапе разметки. Правильно свёрстанная форма работает для всех пользователей без дополнительных усилий.

Если хотите углубиться в тему — изучите полный курс по формам от Google. Там разбираются проверка данных, оформление, доступность и даже usability-тестирование поведения пользователей при заполнении форм.

Источник: web.dev — Help users enter data in forms

317 npm-пакетов скомпрометированы через взломанный аккаунт atool: под угрозой echarts-for-react (3,8 млн загрузок/мес), size-sensor (4,2 млн) и более 250 пакетов @antv.

Вредонос — тот же тулкит Mini Shai-Hulud, что три недели назад атаковал SAP: одинаковая архитектура сканера, те же регулярные выражения для поиска учётных данных.

Payload объёмом 498 КБ крадёт учётные данные AWS (включая EC2 metadata и ECS), GitHub PAT, токены npm, SSH-ключи, данные 1Password и Bitwarden.

Двойная эксфильтрация: через публичные GitHub-репозитории с зашифрованными Git-объектами и HTTPS-запросы к t.m-kosche[.]com под видом OpenTelemetry-трейсов.

Вредонос перехватывает AI-агентов: внедряет SessionStart-хуки в Claude Code и Codex, а также задачи runOn:folderOpen в VS Code.

Масштаб атаки

Аккаунт atool на npm поддерживает 547 пакетов. Атакующий опубликовал вредоносные версии двумя волнами: первая — с 01:39 до 01:56 UTC (~317 версий), вторая — с 02:05 до 02:06 UTC (~314 версий). В результате 309 пакетов получили по два заражённых релиза каждый.

• size-sensor — 4,2 млн загрузок/мес
• echarts-for-react — 3,8 млн загрузок/мес
• @antv/scale — 2,2 млн загрузок/мес
• timeago.js — 1,15 млн загрузок/мес
• @antv/x6, @antv/g, @antv/g6 и более 250 других пакетов @antv

Важно: атакующий не переставил тег latest — но это не защищает. npm выбирает наибольшую версию, удовлетворяющую semver-диапазону, независимо от тега. Проект с "echarts-for-react": "^3.0.6" при следующей чистой установке получит вредоносную 3.2.7.

Как работает вредонос

498-килобайтный обфусцированный Bun-скрипт запускается через preinstall-хук. Дополнительно 630 из 637 версий добавляют в optionalDependencies ссылку на «сиротские» коммиты в репозитории antvis/G2 на GitHub с поддельным авторством. Этот механизм позволяет доставить payload даже при блокировке preinstall-хуков: npm резолвит github:-зависимости по SHA без проверки истории ветки.

Скрипт собирает учётные данные по всей цепочке AWS: переменные окружения, файлы конфигурации, EC2 Instance Metadata Service (169.254.169.254), ECS container metadata (169.254.170.2), Secrets Manager. Помимо этого — токены Kubernetes, HashiCorp Vault, GitHub PAT, токены npm, SSH-ключи и хранилища паролей: 1Password, Bitwarden, pass, gopass.

Эксфильтрация идёт двумя параллельными каналами: украденные данные коммитятся как Git-объекты в публичные GitHub-репозитории с названиями в формате Dune-вселенной (sardaukar-sandworm-42, fremen-stillsuit-7 и т.п.), а также отправляются RSA+AES-зашифрованными POST-запросами к t.m-kosche[.]com — замаскированными под данные OpenTelemetry.

Для закрепления в системе вредонос устанавливает systemd-сервис kitty-monitor (или LaunchAgent на macOS), который каждый час опрашивает GitHub Commit Search API в поиске RSA-PSS-подписанных команд по ключевому слову firedalazer. Это классический GitHub dead-drop C2-бэкдор.

Связь с атакой на SAP

Исследователи SafeDep идентифицировали payload как Mini Shai-Hulud — тот же тулкит, который три недели назад был использован в компрометации SAP. Совпадают архитектура сканера, набор регулярных выражений для поиска учётных данных и паттерны обфускации. Название отсылает к Дюне Фрэнка Герберта: Shai-Hulud — гигантский песчаный червь, пожирающий всё на своём пути.

Что делать

1. Проверить package-lock.json или yarn.lock — найти версии из списка скомпрометированных пакетов (полный список в источнике).
2. Удалить node_modules и переустановить зависимости после того, как npm отзовёт вредоносные версии.
3. Проверить наличие kitty-monitor.service (Linux) или com.user.kitty-monitor.plist (macOS).
4. Проверить файл ~/.claude/settings.json — не должно быть SessionStart-хуков, запускающих node .claude/setup.mjs.
5. Ротировать все учётные данные: AWS IAM, GitHub PAT, npm-токены, SSH-ключи — если машина устанавливала заражённые пакеты.

Индикаторы компрометации

Источник: SafeDep — Mini Shai-Hulud Strikes Again: 317 npm Packages Compromised

Vite+ — бесплатный open-source CLI от VoidZero, объединяющий Vite, Vitest, Oxlint, Oxfmt, Rolldown, tsdown, Vite Task и менеджмент версий Node.js в одном инструменте.

Vite+ объединяет 7+ инструментов (Vite, Vitest, Oxlint, Oxfmt, Rolldown, Vite Task, vp env) под единым CLI-бинарником vp.

Требует Node.js 20.19+ или 22.12+. При более старой версии обновление обязательно.

Для новых Vite-проектов — удобен сразу. Для крупных production-кодовых баз с кастомными ESLint-плагинами — тестировать осторожно.

Единая точка конфигурации: vite.config.ts вместо .eslintrc, .prettierrc, vitest.config.ts и .nvmrc.

Команда vp check запускает форматирование, линтинг и проверку типов за один шаг.

Что входит в Vite+

Vite+ спроектирован так, чтобы один CLI заменил набор привычных команд. Вот что он консолидирует:

• Vite — дев-сервер и production-сборка через vp dev / vp build
• Rolldown — bundler следующего поколения, используемый Vite 8 вместо Rollup
• Oxlint — быстрый линтер для JS/TS, совместимый с большинством ESLint-правил
• Oxfmt — форматтер кода, заменяющий Prettier для большинства проектов
• Vitest — тесты, интегрированные с Vite-экосистемой
• Vite Task — запуск задач в монорепозитории с кэшированием (альтернатива Turborepo)
• vp env — управление версиями Node.js без NVM или FNM

Ключевое преимущество — не только скорость, но и согласованность: меньше конфиг-файлов, меньше точек, в которых что-то может разъехаться.

Когда Vite+ имеет смысл

Vite+ подходит не для каждой ситуации. Вот ориентир:

• Используйте, если начинаете новый Vite-проект — меньше конфигурации с самого старта
• Используйте, если хотите единую команду для форматирования, линтинга и проверки типов
• Используйте, если нужно pin-нуть Node.js-версию в проекте без NVM/FNM
• Осторожно, если production-кодовая база зависит от нишевых ESLint-плагинов или кастомных правил
• Осторожно, если в монорепозитории уже настроен Turborepo или Nx
• Осторожно, если поведение Prettier жёстко зафиксировано и команда не готова к разнице в форматировании

Что нужно для начала

Важная версионная оговорка: Vite 8 требует Node.js 20.19+ или 22.12+. Если на машине установлена более старая версия — обновите перед установкой Vite+.

Для работы с этим гайдом понадобится:

• Node.js 20.19+ или 22.12+
• Базовое знакомство с командной строкой
• Терминал на macOS, Linux или Windows
• Существующий Vite-проект, если хотите протестировать миграцию

ESLint, Prettier, Vitest, NVM или FNM глобально устанавливать не нужно — Vite+ берёт это на себя.

Установка Vite+

Vite+ устанавливается как единый бинарник vp. На macOS или Linux: Официальный сайт проекта: vite.plus.

На Windows в PowerShell:

После установки перезапустите терминал и проверьте CLI:

Создание проекта

Для создания нового проекта используется команда vp create. Интерактивные подсказки предложат выбрать фреймворк, шаблон и пакетный менеджер:

После создания проекта переходим в директорию и запускаем дев-сервер:

Команда vp dev делает то же, что npm run dev, pnpm dev или yarn dev — только теперь команда единая для всей команды, независимо от пакетного менеджера.

Конфигурация в vite.config.ts

Вся конфигурация Vite+ собирается в одном файле — vite.config.ts. Вместо разбросанных .eslintrc, .prettierrc, vitest.config.ts и .nvmrc — один типизированный файл. Базовая конфигурация выглядит так:

Форматирование с Oxfmt

Добавьте секцию fmt для настройки форматирования:

Запуск форматирования: vp fmt. Для большинства проектов Oxfmt заменяет Prettier — но перед миграцией production-кодовой базы прогоните его на отдельной ветке и проверьте diff: Oxfmt может форматировать иначе в отдельных случаях.

Линтинг с Oxlint

Oxlint работает быстро и поддерживает большинство ESLint-совместимых правил. Главное ограничение — совместимость плагинов. Если проект зависит от нишевых ESLint-плагинов или кастомных правил, перед полной заменой ESLint нужна тщательная проверка.

Тесты с Vitest

Запуск тестов: vp test. Vitest хорошо интегрируется с Vite-экосистемой и переиспользует ту же ментальную модель и инструментарий.

Единая проверка с vp check

После настройки форматирования, линтинга и тестов — запустите единую проверку качества:

Команда прогоняет форматирование, линтинг и проверку типов за один вызов. Если введена ошибка типа:

Vite+ сообщит о проблеме в терминале. Для автоматического исправления того, что можно исправить автоматически:

Важная оговорка: --fix не чинит всё подряд. Форматирование и часть lint-проблем — да, ошибки типов и логические баги — нет. Это инструмент автоисправления, а не замена ревью кода.

Проверка staged-файлов перед коммитом

В традиционном стеке для pre-commit проверок используют Husky и lint-staged. Vite+ консолидирует часть этого рабочего процесса через конфигурацию staged:

Vite+ предоставляет команду и конфигурацию staged-файлов — git hook при этом нужно настроить самостоятельно (Vite+ не делает это автоматически). После настройки это предотвращает попадание проблем с форматированием и типами в основную ветку.

Миграция существующего Vite-проекта

Для уже существующего Vite-проекта есть команда миграции:

Она переносит конфигурацию Oxlint, Oxfmt и lint-staged в vite.config.ts. Важно: не воспринимайте это как финальный шаг. Миграция — начало ревью, а не конец. Рекомендуемый порядок:

1. Запустить vp migrate
2. Запустить vp check
3. Проверить изменения через git diff
4. Просмотреть сгенерированный конфиг, изменения в package.json и diff форматирования
5. Только после ревью — мёржить

Управление версиями Node.js через vp env

Vite+ включает менеджмент версий Node.js через vp env. Зафиксировать конкретную версию для проекта:

Это гарантирует одинаковую версию рантайма у всех разработчиков и снижает риск environment-специфичных багов, особенно когда требования Vite к Node.js меняются между мажорными версиями. Можно заменить .nvmrc или FNM для команд, хотящих управлять всем через Vite+.

Vite+ против традиционного инструментария

Вот как Vite+ соотносится с привычным стеком по ключевым задачам:

• Дев-сервер: npm run dev → vp dev
• Production-сборка: Vite + Rollup-конфиг → vp build
• Форматирование: Prettier + .prettierrc → Oxfmt через vite.config.ts
• Линтинг: ESLint + конфиг плагинов → Oxlint через vite.config.ts
• Тесты: отдельный vitest.config.ts → vp test
• Проверка качества: несколько package.json-скриптов → vp check
• Версия Node.js: .nvmrc или FNM → vp env pin
• Staged-проверки: Husky + lint-staged → staged-конфиг Vite+ с ручной настройкой hook'а
• Задачи монорепозитория: Turborepo/Nx → vp run через Vite Task

Текущие ограничения

Vite+ перспективен, но не является универсальной заменой для всех JavaScript-проектов. Перед широким внедрением важно учесть:

• Зрелость экосистемы — Vite+ новее инструментов, которые он консолидирует
• Совместимость ESLint — Oxlint поддерживает большинство правил, но не каждый плагин и кастомное правило
• Форматирование — Oxfmt может давать не полностью идентичный Prettier вывод в отдельных случаях
• Фреймворк-специфичность — Vite+ наиболее силён в Vite-экосистеме; framework-специфичное поведение нужно тестировать
• Размер установки — Vite 8 тяжелее Vite 7 из-за lightningcss и Rolldown
• Изменения рабочего процесса — замена привычных скриптов на vp требует документирования и адаптации команды

Vite+ — не волшебная замена каждого JavaScript-инструмента. Это серьёзная попытка сократить фрагментацию frontend-инструментария, сделав Vite точкой входа в более интегрированный рабочий процесс разработки.

Выводы

Vite+ делает практическую ставку: JavaScript-инструментарий легче поддерживать, когда бандлер, линтер, форматтер, тест-ранер, task runner и менеджер рантайма спроектированы работать вместе. Для новых Vite-проектов это сразу даёт меньше конфиг-файлов, меньшую поверхность команд и единый vp check для стандартных проверок.

Для крупных production-приложений лучший подход — постепенное внедрение: протестировать на ветке, проверить diff форматирования, убедиться в покрытии линтинга, проверить поведение CI. Инструмент не ставит точку в эволюции frontend-инструментария — он указывает направление: меньше фрагментации, больше интеграции.

Источник: Vite+ guide: One CLI for JavaScript tooling — LogRocket Blog, Emmanuel John, 12 мая 2026 г. Репозиторий Vite+: github.com/voidzero-dev/vite-plus.

Это одна из крупнейших координированных атак на реестры пакетов в 2026 году, и первая, которая в одной кампании задела сразу и npm, и PyPI. StepSecurity и Socket трекают её как «mini-shai-hulud». Разбираемся, что произошло, кто пострадал и что делать.

• 404 вредоносные версии в 170+ npm-пакетах и 2 PyPI-пакетах, опубликованы в течение пятичасового окна 11 мая.
• Под удар попали: @tanstack (42 пакета роутера для React, Vue, Solid), @mistralai (3 SDK), @uipath (65 пакетов автоматизации), @opensearch-project/opensearch (1,3 млн загрузок в неделю), Guardrails AI.
• Два механизма триггера в npm: preinstall-хук (@mistralai) и optionalDependency с prepare-скриптом (@tanstack). На PyPI — инжекция в __init__.py, срабатывает при импорте, а не при установке.
• Payload крадёт GitHub-токены, npm-токены, AWS IAM-credentials и HashiCorp Vault-credentials. Эксфильтрация — через onion-routed мессенджер Session, поэтому C2-домен заблокировать нельзя.
• Самораспространение: payload использует украденный GitHub-токен, чтобы закоммитить .claude/settings.json и .vscode/tasks.json в feature-ветки чужих репозиториев через GraphQL-мутацию createCommitOnBranch.
• Безопасные версии: mistralai ≤ 2.4.5, guardrails-ai ≤ 0.10.0. По npm — пиньте версии и регенерируйте lockfile.

Что произошло

В ночь с 11 на 12 мая 2026 года автоматическая система детекта SafeDep засекла массовый burst странных публикаций на npm. Атакующий действовал не точечно, как в случае с axios в марте 2026, а целыми scope-ами: внутри одного scope падали сразу все пакеты. К утру стали известны границы кампании — 170 npm-пакетов, 404 вредоносные версии, плюс 2 PyPI-пакета.

Кого затронуло

• TanStack (42 пакета, 84 версии): целый экосистем роутера — @tanstack/react-router, @tanstack/vue-router, @tanstack/solid-router, их devtools, SSR-плагины и build-инструменты. У @tanstack/react-router — 3 миллиона загрузок в неделю.
• Mistral AI (3 пакета, 9 версий): core SDK @mistralai/mistralai и его обёртки под Azure и GCP. По три вредоносные версии на каждый.
• UiPath (65 пакетов, 65 версий): весь scope @uipath — SDK агентов, оркестратор, инструменты RPA, пакеты для интеграции.
• OpenSearch (@opensearch-project/opensearch): официальный JavaScript-клиент, 4 затронутые версии — 3.5.3, 3.6.2, 3.7.0, 3.8.0. 1,3 миллиона загрузок в неделю.
• Guardrails AI (guardrails-ai==0.10.1 на PyPI): фреймворк validation guardrails для Python.
• Mistral AI на PyPI (mistralai==2.4.6): официальный SDK; легитимного релиза 2.4.6 не существовало, последняя версия — 2.4.5 от 7 мая.

Как работает атака

На npm — два механизма триггера

Для Mistral AI атакующий заменил блок scripts в package.json на preinstall-хук. Этот хук скачивает Bun runtime и запускает payload setup.mjs, который, в свою очередь, запускает основной обфусцированный бинарь router_init.js.

Для TanStack атакующий пошёл хитрее. В легитимный package.json добавлен optionalDependency, указывающий на вредоносный коммит в реальном репозитории tanstack/router на GitHub (коммит #79ac49eedf774dd4b0cfa308722bc463cfe5885c). В этом коммите лежит prepare-скрипт, который снова тянет Bun и запускает тот же payload.

Преимущество атакующего: коммит в публичном репозитории, который ссылается из optionalDependency, не вызывает алертов автоматических сканеров — внешне это легитимная зависимость.

На PyPI — инжекция в __init__.py

PyPI устроен иначе: sandboxed install через pip download и pip wheel не выполняет код пакета. Поэтому атакующий не стал прятать payload в install-хуке. Вместо этого в __init__.py добавили 15 строк, срабатывающих при первом import:

Никакой обфускации: URL, путь и команда выполнения — открытым текстом. Проверка sys.platform запускает dropper только на Linux. macOS- и Windows-сборки несут трояны, но dropper там не сработает. Cloudflare помечает домен git-tanstack.com как phishing-сайт.

Что крадёт payload

Внутри обфусцированного router_init.js — модульный credential stealer с дедикейтными провайдерами под разные источники секретов:

• GitHub PAT, OAuth и App-installation токены: паттерны ghp_*, gho_*, ghs_*.
• GitHub Actions OIDC JWT — формата ghs_NNN_xxx.yyy.zzz.
• npm publish tokens (npm_*).
• AWS IAM credentials через зондирование metadata-эндпоинта 169.254.169.254/latest/meta-data/iam/security-credentials/.
• HashiCorp Vault — пробу на localhost:8200.

Сканер регулярок прогоняется по содержимому переменных окружения, файлам конфигурации и истории shell. Цель — максимизировать lateral movement из CI/CD-окружений и dev-машин в публичное облако.

Самораспространение через Claude Code и VS Code

Самая интересная и пугающая часть payload — self-replication механизм. Имея украденный GitHub-токен, payload использует GraphQL-мутацию createCommitOnBranch, чтобы закоммитить вредоносные файлы в репозитории жертвы:

• .claude/settings.json и .claude/setup.mjs — конфиг для Claude Code, запускающий payload при открытии проекта.
• .vscode/tasks.json и .vscode/setup.mjs — то же самое для VS Code.
• .claude/router_runtime.js — полная копия 2,2-мегабайтного payload, чтобы следующая стадия не зависела от внешнего хоста.

Цели коммитов выбираются хитро: payload запрашивает до 50 веток через GraphQL и отфильтровывает main, master, develop и release (типичный набор). Коммиты идут в feature- и topic-ветки, где меньше шансов нарваться на ревью. В коммит-сообщении добавляется случайный Co-authored-by, чтобы выглядеть «коллективно».

Итог цепочки: любой разработчик, который git pull заражённую ветку и откроет проект в VS Code или Claude Code, запустит payload без явного действия. Затем его токены крадутся — и цикл повторяется.

Эксфильтрация через Session — почему домен не закрыть

Атакующий не использовал классический C2-домен. Вместо этого payload содержит полную реализацию клиента Session — onion-routed мессенджера на сети Oxen. Payload связывается с pre-pinned seed-нодами (seed1.getsession.org, seed2.getsession.org, seed3.getsession.org), получает список snode-ов и отправляет украденные креды через peer-to-peer-сеть.

Для больших данных payload использует filev2.getsession.org/file/ — централизованный файловый сервер Session. Это единственная фиксированная точка инфраструктуры; всё остальное — динамическое peer-to-peer-разрешение через swarm. Защитники не могут отозвать swarm так, как отзывают домен.

Шифрование на ed25519 и x25519, перебор snode-адресов в рантайме — блокировка C2 на уровне DNS или firewall здесь не работает.

Что делать прямо сейчас

Для npm-проектов

Проверьте lockfile на наличие вредоносных версий по затронутым scope-ам:

Если что-то найдено — запиньте пакеты на известные безопасные версии и перегенерируйте lockfile. После этого ротейтьте все секреты, к которым имела доступ ваша dev-машина или CI: GitHub PAT, npm-токены, AWS-ключи, Vault-токены.

Для Python-проектов

Проверьте установленные версии:

Если у вас mistralai==2.4.6 или guardrails-ai==0.10.1 — окружение скомпрометировано. Безопасные версии: mistralai ≤ 2.4.5 и guardrails-ai ≤ 0.10.0.

Дополнительная гигиена

• Проверьте feature- и topic-ветки своих репозиториев на свежие коммиты с подложенными файлами в .claude/ и .vscode/ — особенно если у вас под рукой Claude Code или VS Code с активным GitHub-токеном.
• Запретите автоматический запуск preinstall- и postinstall-скриптов через флаг --ignore-scripts.
• Просканируйте репозитории на наличие .claude/router_runtime.js — это копия payload, размер около 2,2 МБ.

Indicators of Compromise (IoC)

FAQ

Выводы

Эта атака подсветила два архитектурных риска, которые мы коллективно проигнорировали. Первый — preinstall/postinstall-скрипты в npm по дефолту запускаются от лица пользователя; одно зависимое дерево из 100 пакетов даёт атакующему 100 шансов запуститься на dev-машине. Второй — IDE-конфиги в репозиториях. Удобство «открыл проект и сразу работает» оборачивается атакующим прямо тем же удобством: пушнул .claude/setup.mjs в feature-ветку — и payload запускается у каждого, кто склонирует ветку.

Защита здесь — это --ignore-scripts в npm, изолированные среды для install (контейнеры, devcontainers), review-обязательность для всех веток, отслеживание незапланированных .claude/- и .vscode/-файлов в pull-requests.

Полный технический разбор с дизассемблированным payload, swarm-логикой и appendix-ом со всеми пакетами — в посте SafeDep.

Разбираем ситуацию по материалу Pragmatic Engineer — охватывает технические подробности vinext, экономику и последствия для коммерческого open source.

Cloudflare выпустила vinext — замену Next.js на базе Vite, которая деплоится в Cloudflare Workers одной командой.

Один инженер + ИИ-агент OpenCode + Opus 4.5 = одна рабочая неделя вместо нескольких лет инженерного труда.

По заявлению Cloudflare: сборка до 4 раз быстрее, клиентские бандлы на 57% меньше.

vinext покрывает 94% API Next.js, но официально экспериментальна: не прошла нагрузочного тестирования.

ИИ удешевил переписывание сложного ПО примерно в 100 раз — под угрозой оказались проприетарные «рвы» коммерческих open source-проектов.

Vercel ($9 млрд оценка) потеряла ключевое конкурентное преимущество: уникальный формат билда Next.js.

Next.js и Vercel: как устроен коммерческий «ров»

Next.js — самый популярный полностековый React-фреймворк. По данным Stack Overflow Developer Survey 2025, его используют около половины разработчиков на React. Проект открытый, но содержится преимущественно силами Vercel.

Хитрость в том, что Next.js собирает проекты с помощью Turbopack — опционального инструмента Vercel, написанного на Rust (используется прежде всего в dev-режиме). Результат сборки — проприетарный, недокументированный формат. Инженер Netlify Эдуардо Боукаш объяснял это так:

Формат вывода сборки Next.js является проприетарным и недокументированным — он используется в деплоях Vercel для инициализации нужной инфраструктуры. Это означает, что любые другие хостинг-провайдеры вынуждены опираться на недокументированные API, которые могут менять поведение без предупреждения в минорных и патч-релизах.

В итоге сложилась система: Next.js бесплатен и открыт, но наилучший опыт разворачивания — только на Vercel. Альтернативные провайдеры вынуждены угадывать поведение недокументированного формата. Это умная стратегия, превращающая open source-проект в воронку монетизации.

Чтобы сломать эту схему, нужно заменить Turbopack на стандартный инструмент — например, Vite, который лидирует в экосистеме JS по данным State of JS 2025. Именно это и сделал Cloudflare.

Что такое vinext и как его создали

Идея проста: убрать Turbopack, поставить Vite, сделать так, чтобы приложения на Next.js собирались в стандартный формат и деплоились на любой платформе — в том числе на Cloudflare Workers.

Cloudflare публично заявила, что на это ушла одна рабочая неделя одного инженера, который использовал агент OpenCode (open source coding agent) совместно с моделью Claude Opus 4 (в источнике — «Claude Opus 4 (в источнике — «Opus 4.5»)»; такой модели в публичном портфеле Anthropic нет, по всей видимости имеется в виду Opus 4):

На прошлой неделе один инженер и модель ИИ с нуля пересобрали самый популярный front-end фреймворк. Результат — vinext (произносится «ви-некст»): drop-in замена Next.js на Vite, которая деплоится в Cloudflare Workers одной командой. В ранних бенчмарках сборка production-приложений ускорилась до 4 раз, а клиентские бандлы уменьшились до 57%. И у нас уже есть клиенты, которые запустили его в production. Вся работа обошлась примерно в $1 100 на токены.

Ядро Next.js за 10 лет выросло примерно до 194 000 строк кода. vinext занимает около 67 000 строк — более компактная реализация, которая не поддерживает устаревшие API и охватывает 94% публичного API Next.js. Оставшиеся 6% — сложные граничные случаи.

Что именно сделал Cloudflare

• Взял публичный API Next.js
• Переписал поведение через Vite
• Создал формат вывода сборки, совместимый с поведением оригинала
• Добавил Agent Skill для миграции существующих Next.js-проектов одной командой

Миграционный скилл — отдельная деталь, показательная для эпохи ИИ. Он работает с Claude Code, OpenCode, Cursor, Codex и другими агентами:

Cloudflare не только использовала ИИ для создания vinext, но и встроила ИИ в процесс его распространения — чтобы миграция клиентских проектов тоже была автоматической.

ИИ делает «невозможное» тривиальным

До появления современных ИИ-агентов переписать Next.js «с нуля» было теоретически возможным, но практически исключённым. Это требовало бы многолетних усилий команды инженеров. При этом сообщество сомневалось бы в долгосрочной поддержке любого форка — Vercel доказывала свою надёжность 10 лет, а любой новый игрок не имеет этого кредита доверия.

Теперь ситуация изменилась. По оценке Pragmatic Engineer, ИИ ускорил создание vinext примерно в 100 раз. Cloudflare завершила проект, измеряемый в инженерных годах, за одну инженерную неделю.

Важно, что всеобщий рост продуктивности от ИИ в среднем куда скромнее. По данным The Pragmatic Summit (Сан-Франциско, 2026), самооценка разработчиков даёт около 10% прироста. Ключевое условие для 100-кратного ускорения — наличие полного тестового покрытия, которое позволяет ИИ-агентам верифицировать каждый шаг.

ИИ во много раз эффективнее на «механических» задачах, где корректность можно проверить тестами, по сравнению с открытыми задачами или теми, что требуют творчества.

Сам факт, что Next.js имеет исчерпывающее тестовое покрытие — это одновременно его сила и слабость: ИИ использовал тест-сюит как спецификацию для переписывания. Cloudflare даже поблагодарила команду Vercel в объявлении:

Мы хотим отметить команду Next.js. То, что их API хорошо задокументирован, а тест-сюит настолько полный, — один из главных факторов, которые сделали этот проект возможным.

Качество под вопросом: экспериментальность vs маркетинг

Cloudflare открыла своё объявление сильным тезисом: «клиенты уже запустили в production». Vercel немедленно указала на уязвимости в безопасности, а CEO Гильермо Рауч связал проект со стереотипом «вайб-кодинга» — небрежной работы без понимания деталей.

Претензия оказалась обоснованной: важная деталь про «production» была закопана в тысяче слов после начала объявления:

Мы хотим быть честными: vinext экспериментален. Ему ещё нет недели, и он не прошёл реального нагрузочного тестирования. (...) Мы работаем с National Design Studio на одном из их бета-сайтов, CIO.gov.

«Клиент в production» у Cloudflare — это бета-сайт без значимого трафика. Это нетипично для компании, обычно отличающейся точностью формулировок. Vercel имела право поднять вопрос безопасности.

Тем не менее это не отменяет главного вывода: ИИ способен снизить стоимость разработки примерно в 100 раз и выдать работоспособный результат за приемлемую сумму. Доработка безопасности и надёжности потребует дополнительного времени — но это уже другой разговор.

Новая угроза для коммерческого open source

Cloudflare и Vercel — известные соперники в борьбе за платформу разработчиков. CEO обеих компаний регулярно обмениваются ударами в публичном пространстве.

Но реальная ставка здесь — бизнес-модель коммерческого open source. Стратегия Vercel была классической:

1. Создать и поддерживать Next.js, обеспечив лучший developer experience.
2. Оптимизировать Vercel под специфический (и недокументированный) формат вывода Next.js.
3. Большинство разработчиков, выбравших Next.js, деплоят на Vercel — ради лучшей интеграции.
4. Повторять годами, пока бизнес не оценят в $9 млрд (оценка октября 2025 года).

В основе стратегии лежали два предположения: (1) переписать Next.js дорого и (2) даже если кто-то это сделает, разработчики усомнятся в жизнеспособности альтернативы. ИИ обнулил оба предположения.

Аналогия с WordPress и WP Engine

Похожая история произошла с WordPress и WP Engine в 2024 году. WP Engine «пиратила» усилия Automattic: почти не вкладывалась в R&D, зато продавала WordPress как managed service — дешевле, чем Automattic, тратящая на разработку сотни миллионов.

Разница в том, что Vercel удавалось избегать «фрирайдеров» — благодаря проприетарному формату билда. Теперь этого барьера больше нет: Cloudflare будет синхронизировать каждое обновление Next.js с vinext через ИИ-агентов, и это не потребует серьёзных инвестиций.

Как защититься: стратегии для коммерческих open source-проектов

Если ИИ позволяет конкурентам тривиально переписать ваш продукт, каковы варианты защиты?

Закрыть тест-сюит

Один из очевидных ответов — сделать тесты приватными. SQLite, например, держит свой наиболее полный тест-сюит (TH3) закрытым и продаёт доступ к нему как сервис. Open source-проект для визуального редактирования tldraw объявил о переносе тестов в закрытый репозиторий (хотя потом оказалось, что это была шутка).

Саймон Виллисон прокомментировал тренд:

За последние несколько месяцев стало очевидно, что полный тест-сюит достаточен для написания совершенно новой реализации любой open source-библиотеки с нуля — потенциально на другом языке.

Другие варианты защиты

• Уменьшить open core, увеличить закрытую часть. Перенести расширенные сервисы из source available в полностью закрытый код.
• Профессиональный support. ИИ может повысить качество поддержки при правильном применении — а это сложно скопировать.
• Живое сообщество. Meetup'ы и реальная аудитория создают связь, которая выходит за рамки кода. Трудно представить встречи vinext-пользователей — а встречи Next.js-разработчиков уже существуют.
• Инфраструктура как ров. В мире, где ПО легко скопировать, владение и управление инфраструктурой становится важнейшим преимуществом: меньшая задержка, выше надёжность, лучшая цена.

Что это значит для индустрии

Для не-коммерческого open source перспективы выглядят иначе. ИИ упрощает создание и поддержку форков, перенос проектов на другие языки и добавление новых функций. Это может означать расцвет открытых проектов, которые не зависят от коммерческой логики.

С другой стороны, появится класс «миграционных агентов», которые провайдеры будут создавать для перетягивания клиентов. Cloudflare уже встроила такой агент в vinext. Это «AI-native» стратегия захвата рынка, которую скопируют другие.

Конкуренция в технологической индустрии становится жёстче и быстрее. По словам Laura Tacho с The Pragmatic Summit:

ИИ — это ускоритель, мультипликатор, и он движет организации в разных направлениях.

В частном случае vinext — пока неясно, насколько популярным он станет и насколько глубок «ров» Vercel вокруг экосистемы Next.js в целом. Переписать фреймворк — не то же самое, что стать жизнеспособной платформой-as-a-service. Доверие, стабильность, поддержка и developer experience накапливались 10 лет.

Выводы

Cloudflare переписала Next.js не из любви к open source, а чтобы разрушить конкурентное преимущество Vercel. Это честная бизнес-война. Но побочный эффект оказался важнее самого конфликта: стало ясно, что ИИ-агенты превращают переписывание сложного ПО из многолетней инвестиции в задачу одной недели.

Для разработчиков это хорошая новость: экосистема Next.js получила стандартизированный формат сборки, а деплой на разные платформы станет проще. Для компаний, строящих бизнес на коммерческом open source, — сигнал тревоги: проприетарные технические «рвы» больше не защищают так, как раньше.

Что по-настоящему защищает — живое сообщество, инфраструктура мирового класса, качество поддержки и репутация, накопленная годами. vinext может стать удобной альтернативой деплоя. Но стать полноценной заменой экосистемы Next.js — задача несравнимо более сложная.

Как вы оцениваете угрозу, которую ИИ создаёт для коммерческого open source? Читайте также: другие материалы об ИИ и open source на tproger.ru.

Источники: Pragmatic Engineer — The Pulse; Cloudflare блог — объявление vinext; State of JS 2025.

Заметка короткая и практическая. Сначала — краткий вывод, потом полный текст Julia.

• Что в посте: рабочий минимум для тестирования Vue-компонентов в браузере без Node, Deno и сборки. Тесты запускаются на отдельной странице через QUnit (тестовый фреймворк, который рендерится прямо в браузере), компоненты экспортируются в window._components, рендерятся через mountComponent в скрытый div вне viewport.
• Как ждать DOM: Julia пишет свою функцию waitFor(), которая раз в 20 мс проверяет условие и сдаётся через 2 секунды. Без sleep()-затычек, обычным опросом DOM — паттерн, к которому рано или поздно приходит любая фронтенд-команда.
• Заполнение форм требует событий: в Vue недостаточно присвоить value или checked — нужно диспатчить событие (input для текстов, change для чекбоксов), иначе реактивность Vue не отслеживает изменение.
• Test coverage — Chrome это умеет из коробки: панель Coverage показывает покрытие JS и CSS-кода. Чтобы хорошо работало, Julia рекомендует выключить sourcemaps в DevTools и смотреть покрытие по бандлу.
• Открытые вопросы: как запускать те же тесты в CI, как уйти от привязки к CSS-классам в селекторах (правильнее — getByRole или data-testid), и стоит ли переехать на Testing Library/Vue Test Utils.

Контекст: я хочу тестировать без Node

Привет! Один из моих долгосрочных проектов — выяснить, как писать frontend-JavaScript без Node и любого другого серверного JS-рантайма.

Главная проблема, в которую я постоянно упираюсь в своих frontend-проектах: я не знаю, как писать для них тесты. Раньше я пробовала Playwright, но он казался медленным и неуклюжим — всё время приходилось запускать новые browser-процессы, и оркестрация требовала Node-кода.

В итоге я просто не тестирую свой frontend, и это неприятно. Обычно я и не обновляю проекты особо часто, поэтому болезненность не сильно проявляется, но было бы хорошо вносить изменения с большей уверенностью!

Так что подходящий способ frontend-тестирования давно лежит у меня в списке желаний.

Идея: просто запускать тесты во вкладке браузера

Alex Chan когда-то написал отличный пост — «Testing JavaScript without a (third-party) framework» — в ответ на одну из моих предыдущих заметок этой серии. Там он показал, как сделать крошечный фреймворк юнит-тестирования, который запускается прямо со страницы в браузере.

Мне тогда очень понравился подход, но в посте речь шла только про unit-тесты, а мне нужны были end-to-end интеграционные тесты для моих Vue-компонентов, и я не знала, как это сделать.

Поэтому, когда на днях знакомый Marco в разговоре сказал «знаешь, ты же можешь просто запускать тесты Vue-компонентов в браузере», я подумала: «эй, надо попробовать ещё раз!»

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

Это было слегка непросто: документация Vue обычно предполагает, что вы используете Node как часть build-процесса (там много «шаг 1: npm install ЧТО-ТО»), а я не хотела использовать Node, Deno и так далее. Но на практике оказалось не очень сложно.

Проект, который я буду здесь тестировать, — это сайт фидбэка по моим зинам, который я написала в 2023.

Тестовый фреймворк: QUnit

Я использовала QUnit — тестовый фреймворк для JavaScript, который умеет запускаться прямо со страницы в браузере без Node-окружения (когда-то именно его использовала команда jQuery). Он отлично работает, но рассказать про его внутреннее устройство мне особо нечего — поэтому ограничусь этим. Думаю, подход Alex с самописным фреймворком тоже сработал бы. Я следовала официальной инструкции.

Что я оценила в QUnit — кнопка «rerun test», которая запускает только один конкретный тест. У меня в тестах много network requests, поэтому возможность запустить только один тест сильно облегчает дебаг.

Шаг 1: подготовить компонент к тестированию

Первое, что я сделала — настроила свои Vue-компоненты для тестового окружения.

В основном приложении я положила все компоненты в window._components, примерно так:

Затем смогла написать функцию mountComponent, которая делает то же самое, что мой обычный mount-код в production (рендерит крошечный шаблон с нужным компонентом).

Отличия только два:

• Можно опционально передать дополнительные данные, чтобы использовать их как props.
• Компонент монтируется во временный невидимый div, который удаляется из DOM по завершении теста. Div позиционирован за пределами viewport (position: absolute; top: -10000, ...), так что его не видно.

Вот как выглядит вызов mountComponent:

А вот её код. Здесь qunit-fixture — это служебный div, который QUnit добавляет в тестовую страницу и автоматически очищает после каждого теста (его id зашит в QUnit, нужно только положить <div id="qunit-fixture"></div> в HTML тестовой страницы):

Результат — div, в котором можно программно кликать, заполнять формы, проверять, что появился нужный контент, и так далее. (Примечание переводчика: в оригинальной версии у Julia функция возвращала просто div, но дальше во всех вызовах используется const {div} = mountComponent(...). С return div такая деструктуризация даст undefined — поэтому мы поправили на return {div}. И добавили явный app.mount(div), который тоже опущен в оригинале.)

Шаг 2: добавить fixture-данные

Поскольку я писала end-to-end интеграционные тесты, в которых клиентский JS должен работать в связке с сервером, в БД нужны были тестовые данные. Я написала ~25 строк SQL для подготовки тестовых данных и добавила endpoint в dev-сервер, который запускает этот SQL и сбрасывает тестовые данные в известное состояние.

Затем просто вызываю await reset() в начале каждого теста, которому нужны тестовые данные.

Моя reset() на самом деле не всегда полностью сбрасывает всё — не очень хорошо, но для старта рабочий вариант, и его всегда можно улучшить.

Шаг 3: базовый тест

Так выглядит базовый тест! По сути мы рендерим div и проверяем, что в нём есть приблизительно правильные данные.

Это все базовые кирпичики! А теперь — несколько проблем, на которые я наткнулась по ходу.

Как ждать рендера: проблема и waitFor()

В моих тестах много сетевых запросов, и нужно время, чтобы они завершились, а Vue потом сделал с результатами своё дело и обновил DOM.

Думаю, мы давно усвоили: вставлять sleep()-затычки и надеяться, что тайминги совпадут, — медленно, нестабильно и доводит до бешенства. Поэтому нужен другой способ.

Насколько я понимаю, обычный путь — найти способ по DOM понять, можно ли двигаться дальше. Что-то вроде «если эта кнопка видна — значит, можно действовать».

Поэтому я написала маленькую функцию waitFor(), которая опрашивает условие каждые 20 мс. Таймаут — 2 секунды.

Версия в посте Julia не показана прямо — приведём свою, минимально работающую (и идейно соответствующую её описанию):

Использование выглядит так:

Похоже, существует много реализаций этой идеи, и они продуманы лучше моей (беглый поиск в Google: qunit-wait-for, Playwright expect.poll).

Понять, чего именно ждать, — нетривиально

Иногда мне казалось, что я нашла правильную точку для ожидания в DOM («просто дождись, пока появится этот textarea!»), но на практике из-за внутренних деталей программы нужно было ждать чего-то другого, что было сложно зацепить.

В итоге я добавила в один компонент произвольное значение в DOM, когда он завершал важное действие (вроде data-this-thing-is-ready=true). Это не очень-то красиво.

Думаю, правильный способ починить такую проблему теста — рефакторинг, который заодно делает приложение более надёжным для пользователя. Если в DOM есть элемент, с которым пользователю на самом деле ещё нельзя взаимодействовать — может быть, его и не стоит показывать?

Добавлять CSS-классы для селекторов? Спорный вопрос

В итоге я добавила несколько классов на HTML-элементы — нужно было их находить в тестах, чтобы кликать или ждать появления в DOM.

Я могу позже изменить этот подход — тестовые фреймворки для frontend обычно советуют избегать CSS-классов и использовать что-то вроде getByRole (выбор по семантической роли элемента, например «кнопка» или «поле формы») или, в крайнем случае, data-testid (специальный data-атрибут, который добавляют исключительно ради тестов и игнорируют в production-стилях).

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

Заполнение форм — отдельная боль

Чтобы заполнить форму, недостаточно просто выставить value — нужно ещё диспатчить событие, чтобы Vue понял, что элемент изменился. И для checkbox, и для textarea нужны разные события.

Это слегка раздражает — и заставляет понять, зачем вообще могут понадобиться UI-тестовые библиотеки. Например, Testing Library (набор фреймворк-агностичных утилит для тестирования UI с упором на доступность) и Vue Test Utils (официальная библиотека Vue для unit-тестов компонентов). Их подходы к формам выглядят иначе:

• Пример заполнения формы из Testing Library выглядит совершенно иначе, чем то, что делаю я.
• У Vue Test Utils раздел про работу с формами выглядит так, будто сильно упрощает всё это.

Test coverage — Chrome это умеет из коробки

Мне хотелось понять, какое у меня test coverage, и оказывается, в Chrome есть встроенная функция code coverage для JS и CSS!

Мой JS собирается в один файл bundle.js через esbuild — поэтому я могу просто посмотреть на bundle.js и увидеть, какие строки не покрыты тестами.

Процесс получился чуть капризный: пришлось выключить sourcemaps в Chrome DevTools, чтобы заработало, и есть специфическая, не самая очевидная последовательность действий, чтобы увидеть данные покрытия.

Это было прикольно

Как обычно с такими постами: я никогда особо не работала frontend- или backend-разработчиком (кроме как для себя!) и чувствую, будто постоянно учусь делать совсем базовые штуки.

Мне реально кайфовалось от этого. Мои frontend-проекты всегда кажутся хрупкими, потому что они без тестов; и, может быть, однажды у меня появится тест-сьют, в котором я буду уверена.

Что я ещё обдумываю:

• Пока писала пост, нашла frontend-библиотеку Testing Library — у неё много рекомендаций, как писать тесты, которые сильно отличаются от моих первоначальных идей. Я попробовала переписать всё на Testing Library — получилось неплохо, посмотрим, что из этого выйдет. Они распространяют .umd.js файл, который работает без Node.
• Не до конца понимаю, как относиться к тому, что эти тесты никак не запускаются из командной строки. Может быть, есть простой способ работать в основном в браузере, но иметь возможность погонять и в CI, если нужно?

Что забрать с собой

Мои frontend-проекты всегда кажутся хрупкими, потому что они без тестов. Может быть, однажды у меня появится тест-сьют, в котором я буду уверена.

Главный вывод поста: для маленьких персональных или библиотечных проектов «тестовая страница в браузере» — совершенно рабочий путь. Не нужно тащить Node, build-сервер и jsdom только ради того, чтобы у вас были тесты. Чек-лист минимальной настройки:

1. Положить компоненты в window._components (или другое глобальное пространство имён).
2. Подключить QUnit (или другой фреймворк, который умеет запускаться прямо со страницы) в HTML-файл с тестами.
3. Написать mountComponent(template, data), которая создаёт временный div и монтирует туда Vue-app.
4. Опционально (если у компонента есть бэкенд): сделать endpoint /api/reset_test_data на dev-сервере для сброса БД к фикстуре.
5. Реализовать waitFor(condition, timeout=2000) для ожидания DOM-условий вместо sleep().
6. Для форм диспатчить input (текстовые поля) и change (чекбоксы) после изменения свойств элементов. Для кликов хватит обычного .click() на элементе.
7. Для покрытия — Chrome DevTools, вкладка Coverage; sourcemaps выключить.

Оригинал поста Julia Evans — на jvns.ca. Альтернативы для тех, кто хочет больше готового: Vue Test Utils (через jsdom в Node), Testing Library (с UMD-сборкой работает без Node).

ИИ я использую. Но в этом проекте он был исключительно быстрой документацией — особенно когда добрался до selection/range API, про которые до этого знал чуть меньше чем ничего. Реализация все равно была за мной.

Так вот — ReadGen. Блочный конструктор README-файлов. Месяц, 2-3 часа в день, React и TypeScript и небольшая пачка дополнительных библиотек для разумного облегчения жизни. Важно понимать что это не коммерческий продукт и не претендует на решение чьей-то боли. Просто техническая задача которую я давно хотел разобрать.

Демо: readgen-eight.vercel.app

Репозиторий: github.com/islamxm/readgen

Почему

contenteditable — старый добрый дед среди браузерных API. То что он старый - это да, а вот доброта - под вопросом.

Он искренне хочет помочь, сам расставляет <div> и <br>, сам решает что делать с Enter, сам форматирует как считает нужным. Проблема в том что его никто не спрашивал. Когда тебе нужен предсказуемый блочный редактор с контролируемой структурой данных — такая самодеятельность становится основным источником боли.

Готовые текстовые движки эту боль скрывают. Я хотел её почувствовать лично. Понять где именно браузер начинает делать по-своему и что с этим делать. Это и был настоящий вопрос проекта.

Поначалу казалось что задача не супер сложная, но довольно быстро понял что полноценный текстовый редактор это бесконечные edge cases которые не влезут ни в какой месяц. Граница была проведена жёстко: плоская структура блоков, никакой иерархии. Всё остальное — потом, в другой жизни.

Так задача сузилась до честного и реалистичного объёма, блочный конструктор README без вложенности, с предсказуемым ядром и нормальным экспортом.

Три OM

Между реальным DOM и виртуальным DOM React затесался ещё один — MOM, Markdown Object Model. Пафосное название для того что по сути является flat map структурой документа. Но только по сути — на деле это целое ядро, состоящее из парсера, валидатора, гардов, движка, сериализатора. Это по сути модули без внешних зависимостей (кроме dexie.js в подмодуле storage) которые принимают данные, делают свое дело и отдают, впрочем как и принято в среде порядочных разработчиков.

Архитектурно MOM живёт как отдельный изолированный модуль — ведёт себя как shared слой в FSD, но это не набор утилит а самостоятельное ядро. Всё остальное приложение построено на гибриде FSD и layered подхода, но MOM существует по своим правилам.

Один DOM, два хозяина

Вот где настоящий конфликт. Структурой документа, порядком блоков, состоянием UI управляет React. Но внутри редактируемых блоков он полностью отступает. Там нет react рендеринга, только innerHTML и чистый DOM. Синхронизация происходит в эффекте, источник истины — содержимое contenteditable, и именно оттуда формируется MOM.

Два хозяина поделили территорию. React взял всё снаружи, DOM взял всё внутри. С одной стороны казалось бы все круто, так и должно быть, но на самом деле это порождает новый пласт проблем.

Отдельная история внутри этой истории — курсор. Позицию нужно постоянно сохранять и восстанавливать через selection/range API, и синхронизировать это с React. Это отдельная боль внутри общей боли.

Деструктивная синхронизация DOM — innerHTML = '' перед каждой манипуляцией выглядит грубо, зато работает. Можно было конечно написать свой reconciliation но учитывая исходные рамки по времени я решил отказаться.

Генераторы в сериализаторе

Экспорт документа в .md — финальная точка всей архитектуры. MOM → Serializer → файл. Впервые за все время своего осознанного программирования я решил тут применить генераторы в деле.

Каждый тип узла имеет свою функцию-генератор. Первый yield — контент блока, второй yield "" — пустая строка-разделитель. Тут мы избавляемся от аккумулятора который нужно тащить в глубь и код делаем более плоским и понятным. Array.from(gen).join("\n") в конце собирает всё в строку.

Drag and drop на Pointer Events

Кастомный drag and drop с анимацией как отдельный хук. И тут я познакомился с довольно таки мощными событиями класса pointer

о существовании которого я знал но почему то всегда обходился с touch

и mouse ивентами.

Pointer Events унифицируют всё что раньше требовало отдельных mouse и touch обработчиков. Без pointercancel drag зависает если браузер решает прервать жест сам. setPointerCapture — чтобы события не терялись когда курсор уходит за пределы контейнера.

Компромиссы

MOMRaw — честное признание границы. Все что не попало в текущую версию движка (таблицы, инлайн-картинки, инлайн-код и т.д.) живёт в одном компромиссном блоке. Вставляй сырой Markdown или HTML, смотри превью через внешнюю библиотеку в изолированном Shadow DOM.

То же самое с блоком кода - MOMCode. Для этого я подключил библиотеку uiw, думаю в будущем заменю его на более современное и понятное решение.

Виртуализации нет, README на 10 000 блоков не существует в природе, проблема надуманная ну или просто не успел (выбирайте сами).

Мелочи которые просто есть и работают: менеджер глобальных шорткатов, тултипы для вставки блоков, эмодзи и форматирования текста, миниатюры документов через modern-screenshot, хранение в IndexedDB без бэкенда.

Заключение

Месяц закончился. contenteditable я теперь знаю лично — и он знает меня. Selection/Range из страшного незнакомца превратился в рабочий инструмент. Понял где React уместен, а где лучше отойти и дать DOM делать своё дело. Нашёл наконец задачу где генераторы оказались не паттерном ради паттерна а реально лучшим решением.

Демо: readgen-eight.vercel.app

Репозиторий: github.com/islamxm/readgen

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

в своей БД вместо текста — стало понятно, что модель наконец работает правильно: сервер создал сообщение, доставил его, сохранил метаданные, но так и не узнал содержимое.

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

Когда пользователь регистрирует устройство, он загружает на сервер пакет публичных ключей:

На сервер уходят только публичные части. Приватные ключи сериализуются и хранятся локально в браузере — и никогда не покидают устройство в сеть.

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

, чтобы приватный ключ жил внутри браузерного crypto runtime и его нельзя было экспортировать в байты. Но у этого подхода есть практическая сложность: ключи нужно переживать между перезагрузками страницы, синхронизировать с IndexedDB, аккуратно восстанавливать состояние устройства и не сломать UX.

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

Сервер в этот момент видит только публичные ключи и зашифрованный конверт. Он помогает устройствам найти друг друга, но не участвует в вычислении секрета.

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

Первый неочевидный момент: в E2EE сообщение адресуется не просто пользователю, а конкретным устройствам пользователя.

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

Простое решение. Но чтобы к нему прийти нужно было полностью принять идею что сервер здесь просто не при делах — и перестать пытаться решить задачу на его стороне.

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Меня зовут Рамазан, я Frontend-разработчик и энтузиаст, который любит искать свежий взгляд на привычные вещи в Web-разработке.

Думаю, что вы слышали когда-либо про функциональное программирование (далее - ФП). Это парадигма для которой характерно применение чистых функций и сохранение иммутабельности данных. Существует ряд языков, в которых принципы ФП преобладают: Haskell, OCaml и Elixir. Однако и другие языки вроде JavaScript, Python, C++ поддерживают этот подход, хотя только им не ограничиваются.

Но внимательный читатель посмотрит на название и спросит: "Функциональное программирование - это хорошо. А причём здесь Atomic CSS?". Сейчас отвечу! Всё дело в том, что ещё на заре появления атомарного подхода у него существовало и другое название - Functional CSS. Кто-то довольно часто использует его и сейчас, чтобы не путать с одноимёнными терминами. Но почему этот подход к CSS-стилизации называют функциональным?

Именно на этот вопрос я постараюсь ответить в данной статье! Сначала я опишу вам базовые принципы ФП, а затем расскажу про основы Atomic CSS (далее - ACSS), проводя аналогии с функциональным программированием. Кроме того, я постараюсь на простых примерах показать, какие проблемы решаются, если применять Atomic CSS при стилизации. Когда я готовил материалы для этой статьи, я много опирался на этот и на этот доклады. Наконец, хотел заметить, что это перевод моей оригинальной статьи на английском языке — так что можете глянуть и её.

Ну что, держитесь крепче - мы начинаем!

Что нужно знать

Чтобы разобраться в этой статье, все, что вам нужно, - это базовое понимание HTML, CSS и JavaScript. Также в статье имеется несколько примеров, в которых мы будем использовать Atomic CSS фреймворк [mlut](https://mlut.style/), но вам не обязательно знать его синтаксис, потому что я привёл расшифроку его утилит в рукописном CSS.

Базовые принципы ФП

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

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

Давайте я приведу основные понятия, через которые попытаюсь раскрыть суть данного подхода:

1) Чистые функции;

2) Иммутабельность;

3) Композиция функций.

Чистые функции

Функция называется чистой, если она:

- при одних и тех же входных параметрах возвращает одно и то же значение;

- не имеет побочных эффектов (изменений внешних значений или сущностей).

Приведу для наглядности пару примеров.

Первая функция чистая, ведь, если мы будем вводить одни и те же аргументы, то будем получать один и тот же результат. Кроме того, никакие глобальные переменные эта функция не меняет, а объекты не мутирует.

Вторая функция не попала в понятие чистоты по обоим пунктам. Она меняет внешнюю переменную `s` и использует для вычислений другую внешнюю переменную `c`, которая может меняться.

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

Иммутабельность

Иммутабельность - это принцип, в соответствии с которым объекты данных не должны меняться после создания. Чтобы произвести изменения над данными, необходимо создать новый их экземпляр и работать с ним.

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

Вот довольно простой пример: возьмём компонент React, который отображает задачу в списке дел. Состояние задачи описывается объектом. И чтобы React правильно перерисовал состояние компонента задачи, когда пользователь что-то в нём изменяет, необходимо передать в качестве нового состояния не измененный старый объект, а новый экземпляр объекта с текущим состоянием. Вот пример, где для состояния задачи используется иммутабельный объект:

Здесь мы увидим, что нажатие на кнопку приведёт к изменению состояния задачи и вызовет повторную прорисовку компонента. Однако мы могли бы определить функцию `toggleDone()` иным способом, используя мутации объекта:

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

Композиция функций

Композиция функций подразумевает применение результата выполнения одной функции в качестве аргумента другой функции. Приведём пример программы, которая делает первую букву каждого слова заглавной:

Здесь мы определили функцию `compose(f1, f2)`, которая возвращает композицию функций, переданных ей в аргументах. Дальше мы используем эту функцию для создания функции `capitalize()`, которая будет как раз делать только первые буквы слов заглавными посредством композиции функций `lower()` и `upperEveryFirst()`. Сначала выполняется первая из них, и она возвращает строку со всеми строчными буквами в аргумент второй функции. Вторая же функция делает первую букву каждого слова заглавной.

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

Как принципы ФП находят отражение в Atomic CSS

Теперь, когда мы узнали немного про функциональное программирование, попробуем ответить на вопрос: "А причём здесь Atomic CSS?". Проведём аналогию между этими подходами на уровне описанных выше принципов.

О том, что такое Atomic CSS

Но сначала уделим немного времени тому, что такое Atomic CSS. Это методология вёрстки, в которой мы используем маленькие атомарные CSS-правила, каждое из которых делает одно действие. Эти классы называют утилитами. Обычно они применяют одно CSS-свойство, но не обязательно одно. Например, во фреймворке [mlut](https://mlut.style/) утилите `Bgc-red` соответствует свойство `background-color: red`, а утилите `-Sz50p` - сразу два свойства `width: 50%` и `height: 50%`.

Современные Atomic CSS фреймворки, типа mlut и Tailwind, внутри используют так называемый JIT-движок. Это компонент, который генерирует CSS на основе только тех утилит, которые вы использовали в разметке.

Чистота

Чистота в CSS определяется тем, какими селекторами, а если конкретнее - классами, задаётся стилизация элементов. В чистом CSS поведение элемента должно определяться исключительно теми классами, которые привязаны к нему в атрибуте `class`. То есть в файле со стилями в идеале не должно быть селекторов вроде `section`, `div > ul`.

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

Во-вторых, нарушается чистота CSS для каждого конкретного элемента. Допустим, мы имеем следующую разметку:

А CSS будет таким:

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

Atomic CSS позволяет такого эффекта избежать. В этом подходе в большинстве случаев стили применяются только к тем элементам, для которых прописаны соответствующие классы. Если же необходимо сделать несколько одинаковых элементов, то одна и та же утилита прописывается в атрибут `class` каждого такого элемента.

Аналогичный пример можно переписать на mlut вот так:

Где JIT-движок mlut сгенерирует такие стили:

Здесь мы уже видим, что стили элементов в таком подходе будут зависеть только от классов, которые им приписаны.

Замечание: здесь, правда, стоит заметить, что синтаксис mlut позволяет делать вещи, которые отходят от строгого понятия чистоты CSS. Иногда это бывает необходимо для создания относительно более сложных эффектов. Допустим, мы хотим реализовать такую карточку, при наведении на которую меняется цвет фона у вложенной в неё кнопки. Тогда на mlut нужно будет написать следующее:

Иммутабельность

Под иммутабельностью CSS я буду подразумевать то, что стили элементов не переписываются. Иммутабельность в ACSS означает, что утилиты, как правило, не мутируют друг друга. Например, в BEM основные стили задаёт блок или элемент, а модификатор эти стили мутирует. А в других подходах, где используются комбинированные селекторы, это мутирование происходит чаще и менее явно.

Попробую привести простой пример. Пусть у нас есть карточка с товаром, которая может быть в своём дефолтном состоянии, либо в состоянии выделения. В BEM это бы выглядело примерно следующим образом:

В этом примере мы видим, что класс `product-card` задаёт красный цвет фона карточки по умолчанию. И, чтобы как-то обозначить выбранную карточку посредством другого цвета фона, нам приходится добавлять класс-модификатор, который изменяет цвет с красного на зелёный. И делает он это посредством переписывания свойства `background-color`, то есть с помощью мутирования стилей блока.

В подходе Atomic CSS эта проблема решается, так как утилиты позволяют задавать CSS-свойства независимо друг от друга и задавать модификации, не прибегая к мутации. Вот так будет выглядеть данный пример, если использовать mlut:

Композиция

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

Для примера покажу простой смайлик, который сделан посредством только лишь Atomic CSS:

Так будет выглядеть наш результат:

Таким образом, применяя утилиты одну за другой, мы получили даже небольшой CSS-арт.

Заключение

Подводя итоги, скажу, что Atomic CSS действительно воплощает в себе базовые принципы функционального программирования. Конечно, не буквально, но в том смысле, который актуален для Frontend-разработчиков и верстальщиков. Я был бы рад услышать ваши дополнения и возражения в комментариях - будет интересно их почитать и над ними подумать!

Напоследок скажу: смотрите на привычные вещи свежим взглядом!

И, как обычно, успехов вам в увлекательном пути Frontend-разработки!

Я хочу поделиться всем, что знаю про предложение оператора пайплайна, который сейчас находится на stage 2 в TC39 (это значит «спецификация утверждена в общих чертах, но детали и финальный синтаксис ещё могут меняться»). Это будет, конечно, в какой-то мере предвзятый рассказ — статья моя — но я постараюсь представить обе стороны, при этом отстаивая свою позицию. Если заметите, что я что-то упустил, — напишите мне в DM в Twitter, я стараюсь отвечать на все.

ВАЖНО. Перед тем как мы погрузимся в это: есть люди, включая меня, у которых очень сильные чувства по этому поводу. Пожалуйста, придерживайте их. Те, кто работает над этими стандартами, — хорошие люди, пытающиеся сделать как лучше для сообщества, даже если мы с ними не согласны.

• Pipeline operator |> в TC39 решает одну боль: «передать значение через цепочку функций без вложенных вызовов». Сейчас в stage 2 принят Hack-вариант, F#-вариант — отклонён, хотя его поддерживала функциональная часть сообщества.
• Hack-вариант: 2 |> ^ ** 2 |> ^ - 1, где ^ — placeholder для значения слева. Работает с любым выражением, не требует higher-order functions, но плохо дружит с библиотеками типа RxJS.
• F#-вариант: 2 |> squared |> subtractOne, без специального символа. Передаёт значение последним аргументом функции справа. Идеально для библиотек с unary-функциями (RxJS, Ramda, fp-ts).
• Главная претензия Леша: библиотеки, которые годами популяризировали идею пайплайна функций (RxJS, Ramda), с Hack-оператором практически не получают выигрыша — там надо писать map(fn)(^) вместо просто map(fn).
• Альтернатива: продвигать F#-pipeline + дополнить proposal-ом partial application (тоже в TC39 на stage 1). Тогда получаем лучшее из обоих миров.

Что такое pipeline operator?

Если коротко, pipeline — это оператор, в данном случае |>, который позволяет разработчику «прокинуть» вычисленное выражение из левой части (LHS) в какую-то функцию или выражение справа (RHS). Этот приём реализован в куче языков мира программирования, и мы сейчас в удивительной ситуации, когда TC39 — комитет, который управляет стандартом ECMAScript, на котором основан JavaScript — рассматривает добавление такого оператора в стандарт. Конкурировало много proposals, два выделились больше всего: Hack pipeline (сейчас на stage 2) и F# pipeline (отклонён, несмотря на популярность).

Как сейчас «пайпят» функции в JS

Первое, что нужно понять, — что вообще значит «пайпить» функции. В сегодняшнем JavaScript есть, по сути, только один способ: через «функциональный пайп». Это распространённая утилита из функционального программирования, которая существует в библиотеках вроде Ramda и RxJS, и многих других.

Идея в том, чтобы применить к значению серию функций в указанном порядке, передавая возвращаемое значение каждой следующей. Сами утилиты делаются довольно просто.

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

Где это пригождается

Конечно, реальные сценарии для пайпинга функций сильно сложнее простой математики. Самый частый — повторное применение функций к разным наборам данных. Главный пример (и да, я о нём поговорю) — RxJS.

RxJS использует пайп-функции для трансформации observables. Раньше у Observable были только методы класса для трансформаций. Это работало в целом нормально, но при таком количестве возможных операций и того, что методы плохо «трясутся» (tree-shake) современными бандлерами, оказалось, что огромный набор методов не годится для сообщества. Мы пробовали «prototype patching», когда модули добавляют методы к Observable «по меню», но это породило кучу других проблем (об этом — в другой статье). В итоге мы остановились на пайп-функциях. Преимущество: вы платите бандл-сайзом только за то, что используете. Импортируете и применяете нужные операторы, остальное «вытряхивается».

В случае RxJS простая pipe-функция (как в первом примере) используется внутри метода pipe у Observable, где this передаётся первым аргументом. Все операторы — filter, map, concatMap — это higher-order functions: они принимают аргументы для настройки, а возвращают унарные пайпуемые функции вида (source) => result.

Это значит, что общая реализация RxJS-функций неизбежно сложная в плане функциональной композиции — все они в основном (arg) => (source) => result, чтобы внутреннее (source) => result можно было пайпить.

Hack pipeline (текущее предложение TC39)

Текущий вариант оператора, который TC39 продвигает, называется Hack pipeline. Назван по языку Hack (диалект PHP, созданный в Facebook), где есть оператор пайплайна, моделью для которого он и стал. Стоит отметить, что предложение находится на stage 2, и я описываю состояние на момент написания.

В Hack-варианте значение из LHS передаётся в выражение справа через специальный символ-плейсхолдер. В официальной спецификации в качестве presumptive token указан %, но финальный выбор не сделан — обсуждаются варианты %, ^, ^^, @@, #. В примерах ниже автор использует ^.

Базовый пример и тот же через именованные функции:

RxJS — обратите внимание на лишние (^) после каждого оператора:

Существующие non-unary API:

Внутри async-функции:

Throw внутри шага пайпа — приходится оборачивать в функцию (см. минусы ниже):

Плюсы Hack pipeline

• Эксплицитность. Многие сторонники Hack любят его за то, что он более явный, чем F#: видно, что именно выполняется.
• Не требует higher-order functions. Поскольку значение из LHS подаётся как специальный символ в RHS, нет необходимости создавать обёртки-функции, чтобы воспользоваться этим значением.
• Работает с любой существующей функцией. Hack pipeline можно применять к любой JavaScript-функции без дополнительной работы.
• Большинство выражений «просто работают». Хотите запайпить в ^ + ^? Пожалуйста.
• Можно await/yield из окружающего контекста. Если |> внутри async-функции — внутри него можно делать await. Внутри генератора или async-генератора — можно использовать yield в RHS.

Минусы Hack pipeline

• «Магический» символ нельзя переименовать. В текущем предложении нет способа переименовать ^, кроме как обернуть RHS в функцию.
• «Магический» символ нужно искать. Где именно используется значение из LHS, решает разработчик и куда поставит ^. В обычном текстовом редакторе вам, возможно, придётся играть в «найди шапочку», чтобы понять, где значение применяется.
• Некоторые выражения просто не работают. Запайпить можно в большинство выражений, но очевидно, что некоторые не сработают — например, выражение, в котором есть ещё один |>.
• Плохо работает с существующими функционально-пайпуемыми библиотеками. На мой взгляд — самый важный минус. Библиотеки, которые годами популяризировали пайпинг функций, выиграют от Hack pipeline куда меньше: например, RxJS пришлось бы вызывать map как source$ |> map(fn)(^).
• Нет прямого способа бросить исключение в шаге пайпа без функции. Тут много нюансов, но если вы решили, что не можете сложить значения через ^ + ^, нет чистого механизма выбросить TypeError, кроме как обернуть сложение в функцию или, может быть, в скобки (это не специфицировано). В async-контексте это может стать совсем мутно.
• Может убить proposal partial application. Иметь в языке сразу две похожие, но разные фичи — наверняка запутает. Partial application очень похож: тоже использует магический символ для применения значения к выражению, возвращая функцию, принимающую столько аргументов, сколько раз символ встречается. (Очень круто, хотя слегка путает.)
• Едва отличается от использования let и =. Тяжело объяснить без кода: по сути это слегка более эффективный способ написать примерно то же самое (см. ниже).

F# pipeline

F# pipeline — другой вариант предложения, у которого было много сторонников за пределами TC39, но его пропустили в пользу Hack pipeline (со ссылкой на «плюсы», описанные выше). Назван так по самой известной реализации — в языке F#.

Идея F# pipeline в том, что значение из LHS передаётся как последний аргумент функции справа. Это идеально работает с унарными функциями — точно с такими, что и при функциональном пайпинге выше.

Базовый пример и тот же через именованные функции:

RxJS — никаких дополнительных обвязок, операторы используются как есть:

Существующие non-unary API — через стрелочные обёртки, причём промежуточные значения можно именовать:

В async-функции прямого аналога нет — пишите как обычно:

Throw внутри шага пайпа — без всяких обвязок:

Плюсы F# pipeline

• Имплицитность. Передаёт значение из LHS в функцию справа предсказуемо и неявно. Нет вопросов «куда ушло значение» — оно всегда передаётся последним аргументом функции справа. А в самом частом случае унарной функции — единственным.
• Работает с существующими функционально-пайпуемыми библиотеками. Из коробки. Всё сообщество JavaScript, которое хотело пайпить функции и пайпило их, выиграет от нового оператора. Например, RxJS сможет вызывать map просто как source$ |> map(fn).
• Работает с любой функцией через arrow-обёртки. Если использовать стрелочные функции с F#-pipeline, можно использовать любой существующий API в точности так же, как с Hack — только с бонусом, что значение можно назвать.
• Не требует магического символа. Не нужно вводить в JavaScript специальный символ. Через стрелочные функции вы используете обычные аргументы.
• Разработчики, знакомые с функциональным программированием, получат дополнительную силу. Кто умеет создавать унарные higher-order functions (например, (...args) => (in) => out) — может строить интересные переиспользуемые паттерны, недоступные в Hack.
• Интересные паттерны с await/yield. С F#-pipeline можно асинхронно получить функцию, которая примет значение из LHS: value |> await getSomeFunc(). В генераторе можно получить ссылку на функцию через корутину с yield.
• Код в RHS переиспользуем. В отличие от Hack, всё что находится в правой части F#-оператора, можно положить в переменную и переиспользовать — потому что оно обязано вычисляться в реальную ссылку на функцию.
• Хорошо работает с records/tuples (тоже stage 2). Можно деструктурировать в RHS через обычные стрелочные функции. В Hack планов как работать с деструктуризацией из «магического» символа я не видел.
• Хорошо работает с partial application (stage 1). Partial application добавляет к F#-pipeline все «приятные» возможности Hack — и даёт лучшее из обоих миров. По моему мнению, если бы partial application уже существовал, Hack pipeline даже не было бы на столе.

Минусы F# pipeline

• Требует функцию в RHS. Чаще всего это будет стрелочная функция, но может быть и higher-order, если кто-то хочет переиспользовать.
• Не позволяет такое же использование await/yield. Использовать оба можно, но они должны разрешаться или yield-ить ссылку на функцию. Это не полное ограничение, но другое поведение. Кроме того, неочевидно, насколько полезен await после пайпа в принципе.
• Продвинутое использование разнесёт higher-order functions. Кто-то считает это минусом — упомяну. HOF — новая сложность для части людей. Я лично думаю, что это будет катализатором лучшего понимания HOF (которые на самом деле — просто другой способ замкнуться над состоянием через функцию, не через класс с методом). В любом случае, простые функции «просто работают» через стрелочную обёртку: |> (x) => plainFunc(x, x).

Резюме автора

Я знаю, что в статье много мнения, но надеюсь, этого хватит, чтобы заставить ещё несколько человек подумать над проблемой — и заставить очень важных и умных людей, работающих над предложением, остановиться и пересмотреть некоторые принятые решения. По-моему, жаль, что предложение в текущем виде уже на stage 2.

Можно получить лучшее из обоих миров одним из способов: (1) разрешить Hack pipeline неявно вести себя как F# pipeline, когда «магический» символ отсутствует; или (2) переключиться на F# pipeline и одновременно протолкнуть предложение partial application. На бумаге второй вариант даёт JavaScript-разработчикам куда более мощный набор инструментов.

Я долго ругаюсь на эту тему, это правда. Делаю что считаю лучшим для JavaScript-сообщества с тем небольшим влиянием, которое у меня есть. Если бы Hack-предложение «просто работало» с пайпуемыми унарными функциями — у меня не было бы к нему вопросов, и эта статья не была бы написана.

Надеюсь, обе стороны спора найдут информацию полезной. Также надеюсь, что мы решим вопрос так, чтобы «обеих сторон» больше не было, и мы все двигались вперёд вместе.

От переводчика

Статья написана в 2021 году, но за прошедшее время мало что изменилось: pipeline operator всё ещё на stage 2, проектное решение не пересматривалось. Hack-вариант остаётся официальным, F# — отклонён. Параллельный proposal partial application — на stage 1.

Если нужен пайплайн уже сейчас — Babel-плагин @babel/plugin-proposal-pipeline-operator поддерживает Hack и F# режимы. Для Hack обязательно указывать topicToken, иначе плагин упадёт:

Для российских команд практическая мысль: пока оператора нет в стандарте, не торопитесь добавлять Babel-плагин ради эстетики — это лишний build-step и потенциальная сложность поддержки. Чистый pipe(value, ...fns) из ramda или собственная утилита в 5 строк дают 90% выигрыша по читаемости без внешних зависимостей.

Оригинал статьи: benlesh.com.

• requestIdleCallback — запустить фоновую задачу, когда браузер простаивает
• :focus-within — стилизовать родителя, внутри которого есть элемент в фокусе
• navigator.onLine + события offline/online — детектировать пропажу интернета
• requestAnimationFrame — плавная анимация без рывков
• Container queries — адаптив относительно размеров контейнера, а не viewport
• crypto.getRandomValues — криптографически стойкие случайные ID без коллизий
• <dialog> — нативный модал с доступностью из коробки
• Web Speech API — распознавание речи без библиотек (только Chromium)
• @supports — CSS feature detection без костылей

1. «Запустим это потом» → requestIdleCallback

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

Поддержка: современные браузеры. В Safari исторически отсутствовал, так что fallback на setTimeout всё ещё полезен.

2. «Почему мой input не подсвечивается?» → :focus-within

Стилизовать элемент с фокусом — просто. А как стилизовать родителя, внутри которого какой-то элемент получил фокус, — задача, которую обычно решают сорока строками JavaScript со слушателями focus и blur. Всё это не нужно: :focus-within делает то же самое одной CSS-строкой.

Поддержка: везде, где это хоть сколько-нибудь важно.

3. «Покажем офлайн-режим» → navigator.onLine

Вечная боль любого PWA — что делать, когда у пользователя пропал интернет (он уехал в лес или зашёл в лифт). Можно писать сложные if-ы — а можно просто слушать события offline и online. На offline складываем данные в IndexedDB, на online отправляем на сервер.

Поддержка: широкая. Одна оговорка: «онлайн» не равно «ваш бэкенд доступен». Это проверка уровня сетевого соединения, а не доступности конкретного сервиса.

4. «Плавная анимация, но проклятая» → requestAnimationFrame

Хотите, чтобы анимация не дёргалась на слабых ноутбуках, а батарея садилась медленнее? Привычка «60 fps = setInterval каждые 16 мс» — плохая идея, и вот почему. Классика, которую все видели:

Интуитивно понятно, что это плохая идея. Лагает. К счастью, есть requestAnimationFrame — он синхронизирован с циклом перерисовки браузера, поэтому анимация действительно плавная.

Поддержка: везде.

5. «Карточка должна адаптироваться, но только здесь» → container queries

Одну и ту же карточку можно положить в узкий сайдбар, в основную ленту или в лайтбокс — и чтобы она корректно подстраивалась под каждое место без знания о том, на каком она экране. Раньше media queries были привязаны к размеру viewport, то есть «ко всей странице». Container queries позволяют применять стили в зависимости от размера конкретного контейнера. Компонент становится самодостаточным: куда положили — под то и подстроился.

Поддержка: современные браузеры. Если целитесь в старые — добавьте fallback через обычные media queries.

6. «Случайный ID, что может пойти не так?» → crypto.getRandomValues

Именно так рождаются баги:

Выглядит как «достаточно случайная» криптография с AliExpress — и работает, пока не перестаёт. Во-первых, всё зависит от реализации движка, мы не знаем, что происходит под капотом. Во-вторых, определённые паттерны вполне возможны, а при большом количестве ID вы фактически напрашиваетесь на коллизии.

К счастью, есть нативное решение. Не серебряная пуля, но crypto.getRandomValues заметно лучше: больше энтропии, нет странных паттернов, вероятность коллизий резко снижается. Браузер просто делает это правильно. А если вам нужен не произвольный набор байтов, а именно UUID, в современных браузерах есть ещё короче: crypto.randomUUID() выдаёт готовый UUID v4 одной строкой — тоже криптографически стойко и без ручной возни с байтами.

Поддержка: широкая.

7. «Нам нужен модал» → dialog

Больше не нужно ставить 12-килобайтную библиотеку ради модального окна, которое так любят пользователи. Нативный <dialog> даёт клавиатурную навигацию, фокус-трап и корректную работу со скринридерами прямо из коробки — всё то, что в самописных модалах обычно забывают или делают криво.

Поддержка: современные браузеры.

8. «Голосовой ввод был бы крутой фичей» → Web Speech API

Собирались ставить transformers.js, потому что понадобилось распознавание речи? У браузера для этого уже есть Web Speech API. Chromium-браузеры поддерживают его напрямую, Safari — через префиксную версию webkitSpeechRecognition (код ниже как раз это учитывает), в Firefox поддержки нет. Для демо и ассистивных фич — отлично, в проде лучше иметь запасной план на случай Firefox.

Поддержка: Chromium и Safari (через webkit-префикс), в Firefox до сих пор нет.

9. «Не сломает ли это CSS?» → @supports

Хотите выкатить backdrop-filter или :has() и при этом не сломать вёрстку в браузере, где фича ещё не поддерживается? Оборачиваем в @supports — и спокойны: браузер, который знает фичу, получит красивую версию, остальные — дефолтный fallback.

Поддержка: очень хорошая.

Когда всё-таки нужна библиотека

Библиотеки — это отлично, и иногда они действительно необходимы. Но иногда вы ставите зависимость на то, что браузер решил годы назад. Перед npm install полезно спросить себя (или поискать в MDN): «А браузер не умнее меня в этом вопросе?» Иногда ответ — да. И это нормально.

Источник: Sylwia Łask — 9 things you're overengineering: the browser already solved them.

• За 20 дней до утечки в баг-трекере Bun зафиксирован баг #28001: source maps отдаются в production mode, хотя документация утверждает обратное.
• Claude Code собирается и работает на Bun — рантайме, который Anthropic приобрела в декабре 2025 года.
• Утечка произошла через файл source map размером 59,8 МБ, попавший в npm-пакет @anthropic-ai/claude-code версии 2.1.88.
• Anthropic назвала инцидент «ошибкой при упаковке релиза, вызванной человеческим фактором». Формальный постмортем не опубликован.
• Прямого подтверждения связи между багом #28001 и утечкой нет, но техническое совпадение слишком точное, чтобы его игнорировать.

Хронология: от покупки Bun до утечки

2 декабря 2025 — Anthropic объявляет о покупке Bun, JavaScript-рантайма, на котором работает Claude Code. Создатель Bun Джаред Самнер (Jarred Sumner) переходит в Anthropic. Компания обещает сохранить Bun как open-source проект с MIT-лицензией. К этому моменту Claude Code уже приносит $1 млрд годовой выручки.

11 марта 2026 — в баг-трекере Bun появляется issue #28001: при использовании Bun.serve() с параметром development: false source maps всё равно генерируются и отдаются клиенту. Документация Bun явно указывает, что в production mode source maps должны быть отключены. Баг зафиксирован на версии 1.3.10.

31 марта 2026 — разработчик Чаофан Шоу (Chaofan Shou, @shoucccc) обнаруживает, что в npm-пакете @anthropic-ai/claude-code версии 2.1.88 лежит файл cli.js.map размером 59,8 МБ. Внутри — полный исходный код: более 500 000 строк TypeScript в ~1900 файлах. Твит набирает более 21 миллиона просмотров.

Что за баг в Bun

Баг #28001 зафиксирован в подсистеме Bun.serve() — встроенном HTTP-сервере Bun с функцией бандлинга. Суть проблемы: даже когда разработчик явно задаёт development: false, source maps всё равно генерируются и включаются в собранные файлы. Это противоречит документации Bun.

Claude Code собирается в один файл для публикации в npm через бандлер Bun. Формально баг #28001 описывает проблему в Bun.serve(), а не в автономном бандлере bun build. Однако обе подсистемы используют один и тот же механизм генерации source maps, и сообщество считает вероятным, что проблема затрагивает обе. На момент утечки issue оставался открытым и без фикса.

Само по себе наличие source map в сборке — ещё полбеды. Проблема в том, что в конвейере публикации Claude Code не было ни записи *.map в .npmignore, ни ограничения поля files в package.json. Если бы любой из этих защитных механизмов работал, source map не попала бы в npm-пакет даже при наличии бага. Сочетание двух факторов — баг в рантайме и отсутствие фильтрации при публикации — привело к утечке.

Почему сообщество обратило на это внимание

На Reddit и Hacker News историю обсуждают не столько из-за технической сложности бага — он тривиален. Внимание привлекла ирония ситуации:

• Anthropic купила Bun в декабре 2025 года. Claude Code — главный продукт компании, и он работает именно на Bun.
• Баг в Bun, связанный с source maps, был известен за 20 дней до утечки, но не был исправлен.
• Anthropic позиционирует себя как «safety-first» ИИ-компанию — и при этом допустила два инцидента с утечками за одну неделю: утечка черновиков блога о модели Mythos 26 марта и source map 31 марта.
• Компания активно рассказывает, что её ИИ пишет значительную часть кода Bun — и именно в этом коде нашёлся баг, приведший к утечке кода ИИ.

Случайно отправить source map в npm — ошибка, которая кажется невозможной, пока не вспомнишь, что значительная часть кодовой базы, вероятно, была написана тем самым ИИ, которого ты релизишь.

Что нашли внутри: краткая сводка

Мы подробно разбирали содержимое утечки в предыдущем материале. Ключевые находки:

• KAIROS — нерелизованный режим автономного фонового агента, который работает как демон, подписывается на GitHub-вебхуки и «видит сны» ночью, консолидируя память.
• Undercover Mode — режим, при котором Claude скрывает свою природу ИИ и убирает атрибуцию Co-Authored-By в коммитах. Принудительного отключения нет.
• ANTI_DISTILLATION — внедрение фейковых инструментов в API-запросы для отравления обучающих данных конкурентов.
• BUDDY — тамагочи в терминале с 18 видами существ, уровнями редкости и RPG-характеристиками.
• Внутренние бенчмарки, кодовые имена моделей (Capybara, Fennec, Numbat) и 44 фича-флага.

Реакция Anthropic

Anthropic удалила npm-пакет в течение нескольких часов и заявила, что утечка — «ошибка при упаковке релиза, вызванная человеческим фактором, а не брешь в безопасности». Пользовательские данные, ключи API и учётные записи не были скомпрометированы. Компания начала рассылать DMCA-уведомления зеркалам на GitHub, но формальный постмортем не опубликовала.

Тем временем корейский разработчик Сигрид Джин (Sigrid Jin) создал clean-room переписку архитектуры Claude Code на Python под названием claw-code. Репозиторий набрал 50 000 звёзд за два часа — по заявлению авторов, это рекорд GitHub. Сейчас проект переписывается на Rust.

Что это значит для разработчиков

Если вы используете Bun для сборки production-кода, стоит проверить свой конвейер публикации:

1. Проверьте, не попадают ли файлы .map в ваши npm-пакеты. Используйте npm pack --dry-run для аудита содержимого перед публикацией.
2. Добавьте *.map в .npmignore или явно перечислите разрешённые файлы в поле files в package.json. Второй вариант надёжнее — вместо списка исключений вы задаёте список включений.
3. Следите за issue #28001 в репозитории Bun — на момент публикации баг не исправлен.
4. Если публикуете пакеты через CI/CD — добавьте шаг валидации, который проверяет отсутствие source maps в артефакте.

Итог

История с утечкой Claude Code — наглядный пример того, как цепочка мелких упущений приводит к масштабному инциденту. Возможный баг в рантайме, отсутствие фильтрации при публикации, недостаточный аудит CI/CD-пайплайна — по отдельности каждая из этих проблем тривиальна. Вместе они обнажили более 500 000 строк проприетарного кода компании с оценкой выше $100 млрд.

Для разработчиков урок простой: не доверяйте дефолтам инструментов сборки и всегда проверяйте, что именно попадает в ваши пакеты. Команда npm pack --dry-run занимает секунды и может предотвратить утечку, которая изменит историю вашего продукта.

Скомпрометированы версии axios@1.14.1 и axios@0.30.4 — обе ветки, актуальная и легаси. Вредоносный код устанавливает кроссплатформенный RAT, который работает на macOS, Windows и Linux. Пакеты были доступны в npm-реестре около 3 часов, прежде чем npm их удалил.

— Скомпрометированы axios@1.14.1 и axios@0.30.4 через взлом npm-аккаунта мейнтейнера

— Вредоносная зависимость plain-crypto-js устанавливает RAT-троянец на все ОС

— axios — самый популярный HTTP-клиент в JS-экосистеме: более 100 млн загрузок в неделю

— Безопасные версии: 1.14.0 (для 1.x) и 0.30.3 (для 0.x)

— Все секреты на затронутых системах нужно ротировать немедленно

Axios — HTTP-клиент для Node.js и браузеров с более чем 100 миллионами загрузок в неделю. Атаки на цепочки поставок (supply chain attacks) — это компрометация инфраструктуры распространения ПО: вместо атаки на конечную цель злоумышленник внедряет вредоносный код в доверенный пакет, который жертва сама устанавливает.

Как произошла атака

Злоумышленники получили доступ к npm-аккаунту jasonsaayman — основного мейнтейнера axios. Email аккаунта был изменён с легитимного адреса на ifstap@proton.me. Предположительно, был украден долгоживущий классический npm access token.

Легитимные релизы axios публикуются через GitHub Actions с криптографической привязкой npm OIDC Trusted Publisher и содержат SLSA-провенанс (Supply chain Levels for Software Artifacts — стандарт подтверждения целостности сборки). Вредоносные версии были опубликованы вручную через npm CLI — без привязки к GitHub, без SLSA-провенанса, без соответствующего тега в репозитории.

Атака была подготовлена заранее: за 18 часов до компрометации axios в npm был опубликован пакет-приманка plain-crypto-js — клон легитимного crypto-js с тем же описанием и именем автора. Сначала чистая версия 4.2.0, затем вредоносная 4.2.1 с постустановочным скриптом.

Хронология атаки

Все события — по UTC, 30–31 марта 2026 года:

• 30 марта, 05:57 — атакующий публикует чистый plain-crypto-js@4.2.0 для формирования истории публикаций
• 30 марта, 23:59 — выходит вредоносный plain-crypto-js@4.2.1 с постустановочным скриптом
• 31 марта, 00:05 — Socket детектирует вредоносный пакет — через 6 минут после публикации
• 31 марта, 00:21 — публикуется axios@1.14.1 со скомпрометированного аккаунта
• 31 марта, 01:00 — публикуется axios@0.30.4 — обе ветки поражены за 39 минут
• 31 марта, ~03:15 — npm удаляет обе вредоносные версии, dist-tag latest откатывается к 1.14.0
• 31 марта, 04:26 — npm публикует заглушку безопасности для plain-crypto-js — пакет заблокирован

Итого: axios@1.14.1 был доступен около 2 часов 53 минут, axios@0.30.4 — около 2 часов 15 минут.

Что делает вредоносный код

В исходном коде axios изменений нет — добавлена только зависимость plain-crypto-js@^4.2.1. Сам пакет никогда не импортируется в коде; он существует исключительно для запуска postinstall-хука при npm install.

Дроппер setup.js

Файл setup.js весит 4209 байт и использует двухслойную обфускацию: сначала reversed Base64-декодирование (с подстановкой символов), затем XOR-шифр с ключом OrDeR_7077. Дроппер определяет ОС и загружает платформенный payload с C2-сервера.

Payload по платформам

macOS: AppleScript-дроппер скачивает бинарный RAT с C2-сервера и сохраняет его как /Library/Caches/com.apple.act.mond — замаскирован под системный демон Apple. Запускается через /bin/zsh.

Windows: PowerShell копируется в %PROGRAMDATA%\wt.exe (маскировка под Windows Terminal). VBScript-дроппер запускает скрытый PowerShell-скрипт с обходом Execution Policy.

Linux: Python-скрипт RAT скачивается в /tmp/ld.py и запускается через nohup в фоновом режиме.

Возможности RAT

При первом запуске RAT отправляет на C2-сервер «отпечаток» системы: hostname, имя пользователя, версию ОС, архитектуру CPU, часовой пояс, время установки ОС и загрузки, список процессов, а также содержимое директорий /Applications, ~/Library и ~/Application Support. Затем RAT опрашивает C2 каждые 60 секунд. Поддерживаемые команды:

• runscript — выполнение произвольных shell-команд и Python-кода
• peinject — загрузка и запуск дополнительных бинарных payload
• rundir — перечисление содержимого директорий
• kill — самоуничтожение процесса

Антифорензика

После выполнения дроппер удаляет себя (setup.js) и подменяет package.json чистой версией без postinstall-секции. При инспекции node_modules после заражения следов вредоносного скрипта не остаётся.

Это означает, что проверка node_modules постфактум бесполезна. Единственный надёжный способ определить компрометацию — проверить package-lock.json на наличие вредоносных версий и IoC-пути на файловой системе (см. ниже).

Кто обнаружил

Атаку независимо обнаружили несколько компаний: Socket задетектировал вредоносный plain-crypto-js через 6 минут после публикации. StepSecurity подтвердил компрометацию через AI Package Analyst и инструментирование GitHub Actions-раннера. Детальный технический разбор также опубликовала SafeDep.

Индикаторы компрометации (IoC)

Файловая система:

Сеть:

SHA256 хеши:

Что делать прямо сейчас

Быстрая проверка — есть ли вредоносные версии в вашем lockfile:

Если команда ничего не вернула — ваш проект не затронут. Если нашлись совпадения:

1. Откатить axios: npm install axios@1.14.0 (для 1.x) или npm install axios@0.30.3 (для 0.x) — это автоматически удалит plain-crypto-js
2. Проверить IoC-пути на файловой системе для вашей ОС (см. выше)
3. Заблокировать C2 на сетевом уровне: sfrclak[.]com / 142.11.206.73
4. Ротировать все секреты на затронутых системах: npm-токены, SSH-ключи, API-ключи, переменные из .env
5. Проверить CI/CD-логи за 30–31 марта — ротировать все secrets из затронутых пайплайнов
6. Перейти на npm ci --ignore-scripts в CI/CD как постоянную политику

Если обнаружены артефакты RAT — считайте систему полностью скомпрометированной и пересоберите из заведомо чистого состояния.

Защита от транзитивных зависимостей

Если axios используется как транзитивная зависимость (его тянет другой пакет), прямой npm install axios@1.14.0 не поможет — нужно зафиксировать версию через overrides в package.json:

Поле overrides работает в npm 8+, resolutions — в Yarn.

Выводы

Инцидент с axios — один из самых масштабных supply chain атак в npm по потенциальному охвату: при 100 миллионах загрузок в неделю даже 3-часовое окно доступности вредоносных версий критично. Для сравнения: компрометация event-stream в 2018 году затронула пакет с 2 миллионами загрузок в неделю.

Скорость реакции экосистемы впечатляет: Socket обнаружил вредоносный plain-crypto-js через 6 минут, npm отозвал пакеты менее чем за 3 часа. Но сам факт, что атакующему хватило одного украденного токена для публикации от имени доверенного мейнтейнера, ставит вопрос о необходимости обязательного использования OIDC Trusted Publishing для критической инфраструктуры npm.

Проверьте свои зависимости, ротируйте секреты и убедитесь, что ваш CI/CD-пайплайн защищён от автоматической установки непроверенных версий.

Исследователь под ником Sveba опубликовал разбор двух способов детектировать headless-браузеры через Chrome DevTools Protocol (CDP). Оба метода работают в одну строку JavaScript, не требуют никаких разрешений и срабатывают синхронно — без замеров тайминга. Второй способ по состоянию на март 2026 года не закрыт и, по заявлению автора, не может быть закрыт без изменения поведения ECMAScript.

Ключевые выводы:
— Оба сигнала срабатывают, когда активен CDP Runtime domain — то есть одновременно при открытых DevTools и при работе Puppeteer/Playwright
— Сигнал 1 (май 2025): кастомный getter на stack у объекта Error — частично закрыт патчем V8, но обходится через прототипы
— Сигнал 2 (март 2026): Proxy в прототипе объекта + console.groupEnd() — не закрыт, корень проблемы в спецификации ECMAScript
— Детектирование синхронное, без тайминга, без permissions — один вызов console.*
— Runtime.enable одинаково активируется и DevTools UI, и автоматизацией

Что такое CDP и почему он нас выдаёт

Chrome DevTools Protocol (CDP) — это API, через который DevTools общается с браузером. Когда вы открываете инструменты разработчика, браузер активирует домен Runtime внутри V8. То же самое происходит, когда Puppeteer или Playwright вызывают Runtime.enable — с точки зрения V8 это неотличимо.

В режиме Runtime.enable инспектор подписывается на все вызовы console.* и начинает сериализовывать аргументы для отображения в панели DevTools. Именно эта сериализация и создаёт side effects, которые становятся детектируемыми.

Сигнал 1: кастомный getter на stack (май 2025, частично закрыт)

Первый вектор, который широко использовался среди вендоров bot-detection, выглядит так:

В нормальном браузере console.debug(e) просто логирует объект. Никто не читает .stack, getter не вызывается, detected остаётся false.

При активном Runtime.enable инспектор перехватывает вызов и прогоняет аргумент через функцию descriptionForError() в v8/src/inspector/value-mirror.cc. Эта функция обращается к свойствам name, stack и message через object->Get() — а C++ API V8 при обращении к свойству честно вызывает getter, если тот определён. Getter срабатывает. detected становится true.

Патч V8 и его неполнота

В мае 2025 года в V8 приземлились два коммита (7 и 9 мая), которые ввели обёртку getErrorProperty(). Перед чтением свойства она проверяет ScriptId getter'а: если у него есть реальный ScriptId (то есть getter написан на JavaScript, а не является нативным C++-аксессором) — читать отказывается.

Проблема в том, что патч срабатывает только если GetOwnPropertyDescriptor на объекте возвращает дескриптор. Если нет — функция идёт по альтернативной ветке и вызывает object->Get() напрямую, до всякой проверки ScriptId. Getter, определённый не как собственное свойство экземпляра, а через прототип — обходит патч полностью.

Сигнал 2: Proxy в прототипе + console.groupEnd (март 2026, не закрыт)

Второй вектор аккуратнее и глубже:

obj — это не Proxy. Это обычный объект, у которого прототипом является Proxy. typeof obj === "object". Именно эта деталь позволяет обойти защиту.

Четыре слоя C++, которые приводят к срабатыванию trap

Автор прошёлся по всей цепочке выполнения в debug-сборке V8 и задокументировал каждый переход:

• Слой A — инспектор генерирует preview безусловно. Функция V8ConsoleMessage::wrapArguments вызывается для каждого аргумента любого console.*-метода с флагом generatePreview = true. console.groupEnd по спецификации не принимает аргументов — но JavaScript позволяет передавать аргументы любой функции, и V8 их исправно обрабатывает.
• Слой B — проверка Proxy работает только на поверхности. В buildObjectPreviewInternal есть цикл, который снимает обёртку Proxy через while(value->IsProxy()). Поскольку obj сам не является Proxy, цикл не выполняется ни разу. Инспектор считает объект «пассивными данными» и передаёт его дальше.
• Слой C — DebugPropertyIterator обходит цепочку прототипов заранее. При создании итератора через DebugPropertyIterator::Create() он сразу накапливает ключи — не лениво по запросу, а при конструировании. Итератор проходит по всей цепочке прототипов: объект без свойств → переход к прототипу (нашему Proxy) → запрос ключей.
• Слой D — спецификация ECMAScript требует вызова trap. Когда KeyAccumulator::GetKeys наконец добирается до Proxy, выбора нет: спецификация (§10.5.11 [[OwnPropertyKeys]]) прямо требует вызвать ownKeys trap, если он определён. V8 вызывает его через Execution::Call — граница C++/JavaScript пересекается. detected = true.

Корень проблемы: три разумных решения создают дыру

Автор подчёркивает: ни одна отдельная строка кода не является ошибкой. Уязвимость — это пересечение трёх архитектурных решений:

1. Безусловная генерация preview. Инспектор сериализует аргументы всех console.*-методов, даже тех, которые по спецификации аргументов не принимают.
2. Неполное раскрытие Proxy. Проверка IsProxy() в двух местах смотрит только на сам объект, но не на его прототипы. Полная защита потребовала бы обхода всей цепочки прототипов при каждом вызове — дорогая операция для того, что сейчас является однострочной проверкой.
3. Жадный сбор ключей при создании итератора. DebugPropertyIterator собирает все ключи заранее, включая из прототипов. Ленивый подход позволил бы вообще не трогать прототипы, если их ключи в итоге не нужны.

Паттерн — достичь управляемого пользователем trap через код инспектора, который защищает только непосредственный аргумент — вряд ли уникален для этих двух поверхностей.

Что это значит для автоматизации браузеров

Оба сигнала срабатывают в любой среде, где активен Runtime.enable: при открытых DevTools, при использовании Puppeteer, Playwright или любого другого инструмента, работающего через CDP. Среды без Runtime.enable — не детектируются.

Детектирование синхронное — никаких таймингов, никаких разрешений, никаких browser extensions. Один вызов console.groupEnd() с правильно подготовленным объектом даёт однозначный ответ.

Закрыть второй сигнал на стороне V8 сложно: любое решение либо потребует дорогого обхода цепочки прототипов, либо изменит поведение инспектора при работе с Proxy. Спецификация ECMAScript не оставляет пространства для манёвра — trap должен вызываться.

Частые вопросы

Что такое CDP Runtime domain и зачем его активируют?

Chrome DevTools Protocol (CDP) — это API для взаимодействия с внутренностями браузера. Домен Runtime отвечает за исполнение JavaScript и отображение объектов. DevTools активирует его, чтобы показывать переменные в консоли. Puppeteer и Playwright активируют его автоматически для управления страницей и выполнения скриптов.

Можно ли заблокировать детектирование на стороне Puppeteer/Playwright?

Для первого сигнала есть частичные обходы (не определять getter как собственное свойство Error, использовать прототипы). Для второго сигнала — нет. Вызов ownKeys trap при обращении к ключам Proxy является требованием спецификации ECMAScript и не может быть пропущен движком без нарушения совместимости.

Это касается только headless Chrome?

Нет. Сигналы срабатывают всякий раз, когда активен Runtime.enable — то есть в том числе при открытых DevTools в обычном браузере. Разница в том, что bot-detection интересует именно автоматизация, а не пользователи с открытой консолью.

Был ли сигнал 2 раскрыт вендорам bot-detection?

Статья опубликована в личном блоге исследователя. Отдельного responsible disclosure в Chromium не упоминается. Автор ссылается на пост castle.io, который задокументировал первый сигнал и майский патч 2025 года — именно он послужил вдохновением для этого исследования.

Выводы

Исследование наглядно показывает, как три независимых, разумно выглядящих инженерных решения образуют детектируемый side effect. V8 закрыл первый вектор патчем в мае 2025 года — но неполно. Второй вектор остаётся открытым и, по мнению автора, не может быть устранён без изменений либо в архитектуре инспектора, либо в поведении ECMAScript.

Если вы занимаетесь разработкой инструментов автоматизации или browser fingerprinting — полный разбор с исходниками V8 стоит прочитать целиком. Обсуждение развернулось в r/ReverseEngineering.

Поиграть прямо в браузере: cssdoom.wtf — полноценный первый уровень DOOM, целиком на CSS. Chrome или Safari, WASD + мышь.

Ленхер — автор нескольких экспериментальных проектов, включая DOOM на осциллографе 1980-х годов. Новый проект использует координаты из оригинального WAD-файла (формат хранения данных карт DOOM) 1993 года и современные CSS-функции: @property, shape() и clip-path (свойство CSS для обрезки элемента по произвольному контуру) с правилом evenodd (правило заливки SVG-путей: закрашиваются области, ограниченные нечётным числом линий). Исходная статья набрала 306 очков и 67 комментариев на Hacker News, а код опубликован на GitHub.

— CSS умеет считать тригонометрию: ширина стены через hypot(), угол через atan2()

— Камеры в CSS нет — двигается весь мир вокруг игрока через translate3d с инвертированными координатами

— Двери, лифты и снаряды анимируются через CSS transitions и CSS animations без JS animation loop

— Освещение секторов работает через filter: brightness(), наследуемый по каскаду

— @property регистрирует custom properties как числа, что позволяет анимировать их плавно

Как это работает — CSS как 3D-движок

Сцена строится из нескольких тысяч <div>-элементов. Каждый получает сырые координаты из оригинального WAD-файла DOOM в виде CSS custom properties: две пары x/y-координат, высоту пола и потолка. CSS сам вычисляет всё остальное.

Тригонометрия в CSS

Ширина стены — это расстояние между двумя точками, которое вычисляется по теореме Пифагора через функцию hypot(). Угол поворота — это арктангенс, вычисляемый через atan2(). Обе функции добавлены в CSS специально для подобных расчётов.

JavaScript передаёт сырые данные DOOM. CSS считает тригонометрию. Это разделение — ключевой архитектурный принцип проекта.

Движение мира вместо камеры

В CSS нет понятия камеры. Вместо этого используется классический трюк: перемещается весь мир в направлении, противоположном движению игрока. JavaScript задаёт всего четыре custom property — --player-x, --player-y, --player-z и --player-angle. CSS делает остальное:

Обратите внимание на инвертированные знаки: если игрок шагает вперёд — мир сдвигается назад. Если игрок поднимается по лестнице — лестница опускается вниз.

Полы, текстуры и клипы

DOM-элементы по умолчанию вертикальны — существуют в плоскости x/y. Чтобы превратить <div> в пол, достаточно rotateX(90deg) — элемент «ложится» горизонтально.

Сложные формы через clip-path

Секторы DOOM — это произвольные многоугольники: L-образные комнаты, неправильные формы, закруглённые коридоры. Для них используется clip-path с polygon(). Для секторов с отверстиями (колонны, платформы, окна) — clip-path с path() и правилом заливки evenodd.

Однако polygon() работает с процентами, а path() требует координат в пространстве CSS — что нарушает чистоту разделения. Решение нашлось в новой функции shape(), которая поддерживает проценты и evenodd одновременно.

Выравнивание текстур

Два соседних сектора с одинаковой текстурой пола должны бесшовно стыковаться. Поскольку background-image повторяется бесконечно, достаточно выровнять начало паттерна по мировым координатам:

Каждый сектор ссылается на одну и ту же текстурную сетку — независимо от того, где расположен его <div>. В результате переход между секторами выглядит бесшовным.

Анимации — двери, снаряды, спрайты

Прежде чем перейти к деталям — важный термин: billboarding. Это техника, при которой 2D-спрайт всегда повёрнут лицом к камере, независимо от положения игрока. В DOOM все враги, бочки и снаряды — billboarded-элементы.

Двери и лифты на CSS transitions

Открытие двери в DOOM — это поднятие потолка сектора. В CSS все элементы двери группируются в контейнер, а анимация запускается переключением атрибута data-state:

Никакого JS animation loop — достаточно установить атрибут состояния на элементе. CSS transitions берут анимацию на себя.

С лифтами всё сложнее: игрок едет вместе с платформой, поэтому --player-z должен обновляться синхронно с CSS transition. Но --player-z управляется из JavaScript. Поэтому для лифтов JS вынужден использовать функцию cubic ease-in-out (t² * (3 - 2t)), чтобы оставаться в синхронизации с CSS-анимацией — это признанное ограничение текущей архитектуры.

Снаряды на CSS animations

Ракеты и файерболы импов — это billboarded <div>. При создании снаряда JavaScript вычисляет конечную точку и длительность полёта, а CSS анимирует перемещение от точки A к точке B:

Благодаря разделению translate и rotate как отдельных CSS-свойств анимация управляет только позицией, а rotate реагирует на --player-angle — файербол продолжает смотреть на камеру при движении игрока.

Параллельно с CSS-анимацией игровой цикл на JavaScript рассчитывает позицию снаряда тем же линейным методом — для обнаружения столкновений (collision detection). Когда снаряд попадает в стену, пол, игрока или врага, JS удаляет элемент посреди полёта и порождает взрыв.

Спрайты с billboarding и mirroring

Враги в DOOM — 2D-спрайты, которые всегда повёрнуты к камере (billboarding). Оригинальная игра хранит 5 уникальных наборов кадров из 8 ракурсов — ракурсы 6-8 это зеркальные отражения 2-4. CSS воспроизводит это через scaleX(-1):

Анимация ходьбы — это spritesheet (набор кадров анимации в одном изображении) со сдвигом background-position-x через steps(). При атаке или смерти JavaScript меняет data-state, и CSS переключается на другой фрагмент spritesheet.

Одна из проблем: изначально все враги маршировали идеально в ногу — левая нога каждого зомби касалась земли в один и тот же момент. Решение — случайный animation-delay, задаваемый из JavaScript. Когда в браузерах появится CSS-функция random(), этот параметр можно будет перенести целиком в CSS.

Освещение и @property

DOOM хранит уровень освещённости для каждого сектора. В CSS это реализовано через custom property --light на контейнере сектора:

Каскад CSS идеально подходит для этого: все стены, полы и спрайты в тёмном секторе автоматически затемняются — без необходимости устанавливать яркость на каждом элементе отдельно. Мерцающие лампы — это @keyframes-анимации переменной --light.

Но анимировать custom properties можно только если они зарегистрированы через @property. Без этого браузер воспринимает их как строки:

Эта регистрация позволяет плавно анимировать --player-z — например, при падении игрока с уступа CSS сам создаёт плавный переход.

Что делает JavaScript, а что CSS

Автор чётко разделил ответственности:

• JavaScript — игровой цикл, состояние игры, коллизии, порождение и удаление DOM-элементов, установка custom properties и data-атрибутов
• CSS — все 3D-трансформации, вычисление геометрии (тригонометрия), анимации дверей и снарядов, освещение, CSS рендеринг спрайтов

По словам Ленхера, game loop на JavaScript — наименее интересная часть проекта. Исходный код DOOM на C доступен публично уже много лет, поэтому для портирования он использовал Claude, чтобы сосредоточиться на CSS-рендеринге.

Выводы

Я хотел найти границы того, на что способен браузер. Увидеть, насколько мощным стал современный CSS. И потому что это DOOM. На CSS. Вам правда нужна ещё какая-то причина?

Проект демонстрирует, как далеко продвинулся CSS за 30 лет. Функции вроде hypot(), atan2() и @property превращают каскадные таблицы стилей в полноценный инструмент для 3D-вычислений. Разделение на JS game loop и CSS-рендеринг оказалось не только возможным, но и элегантным.

Исходный код: GitHub. Подробный разбор: CSS is DOOMed.

По сути debounce делает одну простую вещь: собирает серию вызовов и превращает их в один вызов после паузы. Отлично подходит для «шумных» UI-событий.

Самый типичный пример — автодополнение в поиске. Но тот же паттерн работает для обработки resize, scroll, live-валидации, фильтров и хуков аналитики.

Классическая реализация выглядит так:

Выглядит дисциплинированно. Ощущается эффективно. Быстро доезжает до прода.

И вот тут начинается обман.

Проблема не в самом debounce. Проблема в связке «debounce + fetch», когда в уравнение входит реальная сеть.

Debounce создаёт ощущение, что запросы «под контролем». Но он не контролирует жизненный цикл запроса: порядок ответов, отмену устаревших запросов, поведение при ошибках.

Именно поэтому в продакшене debounce «врёт»: UI выглядит плавно, а сетевой слой по-прежнему хрупкий.

В этой статье мы оставим debounce для того, в чём он хорош (сглаживание UI), и укрепим сетевой слой отменой запросов, повторными попытками и корректной обработкой ошибок.

Ключевые выводы:
— Debounce — это паттерн UI, а не паттерн работы с сетью
— Он гарантирует только одно: «я не буду вызывать функцию слишком часто»
— Порядок ответов, отмена устаревших запросов и обработка ошибок — это то, что вам придётся решать отдельно
— AbortController отменяет устаревшие запросы на уровне сети
— Повторные попытки с экспоненциальной задержкой спасают от транзиентных ошибок сервера

Проблема 1 — гонка запросов (race conditions)

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

Представьте: пользователь печатает 12345678. Debounce пропускает запросы для 1234567 и 12345678. Ответ на 1234567 задерживается на сервере и приходит после ответа на 12345678. UI обновляется последним пришедшим ответом — и показывает устаревшие данные.

Это классическая гонка запросов, и debounce сам по себе её не предотвращает.

Решение — AbortController

Нам нужно гарантировать, что обрабатывается только ответ на последний запрос, а все предыдущие — отменяются. AbortController — это браузерный API, который позволяет отменять fetch-запросы. Создаём контроллер, передаём его signal в fetch, и вызываем abort(), когда нужно отменить запрос.

Что изменилось:

• Перед каждым запросом мы отменяем предыдущий через abort() и создаём новый контроллер
• В блоке catch проверяем, является ли ошибка AbortError — это ожидаемое поведение, а не реальный сбой

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

Проблема 2 — сетевые ошибки

Сеть непредсказуема не только по задержкам, но и по надёжности. Иногда запрос, который мог бы пройти при повторной попытке, просто падает. Причины: кратковременная перегрузка сервера, пики нагрузки, таймауты базы данных.

fetch не бросает исключение при HTTP-ошибках

Это одна из главных ловушек нативного fetch: он отклоняет промис только при сетевых сбоях (нет соединения). Коды 4xx и 5xx — это «успешные» ответы с точки зрения fetch. Если сервер вернёт 500, ваш код радостно вызовет response.json() и получит undefined вместо данных.

Исправляем проверкой response.ok:

Теперь 500-я ошибка выбрасывает исключение до того, как мы пытаемся разобрать тело ответа. Блок catch обработает её корректно.

Повторные попытки с экспоненциальной задержкой

Но простая проверка — это только начало. В реальном приложении стоит добавить автоматические повторные попытки для транзиентных ошибок. Если запрос упал из-за временной проблемы, лучше попробовать ещё раз с нарастающей задержкой, чем сразу показывать ошибку пользователю.

Писать логику повторов вручную — это циклы, счётчики попыток, тайминги, и всё это должно корректно работать с отменой. Нетривиально и неинтересно. Воспользуемся библиотекой @fetchkit/ffetch — это тонкая обёртка над fetch, которая решает именно эту задачу.

Есть и альтернативы: ky, axios или собственная обёртка. ffetch выбран за совместимый с fetch API и корректную работу с AbortController при повторных попытках.

Что нам это даёт:

• retries: 3 — при 500-й ошибке библиотека повторяет запрос до 3 раз
• shouldRetry — повторяем только при 5xx; всё остальное (сетевая ошибка, отмена) пробрасывается сразу
• throwOnHttpError: true — автоматически бросает исключение на HTTP-ошибки, не нужна ручная проверка response.ok
• Задержка между повторами учитывает AbortController — если abort() вызван во время ожидания, повтор немедленно прекращается

Последний пункт особенно важен. Без этого отмена запроса в середине серии повторов убила бы текущий fetch, но оставила бы таймер — и следующая попытка сразу бы упала с AbortError.

Полное решение

Собираем всё вместе: debounce для UI-сглаживания, AbortController для отмены устаревших запросов, ffetch для повторных попыток и автоматической обработки HTTP-ошибок.

Каждый слой отвечает за своё: debounce снижает частоту вызовов, AbortController гарантирует, что обрабатывается только актуальный запрос, а ffetch добавляет устойчивость к транзиентным сбоям.

Частые вопросы

Зачем AbortController, если debounce и так снижает количество запросов?

Debounce снижает частоту вызовов, но не контролирует, что происходит с уже отправленными запросами. Если два запроса ушли один за другим, более ранний может вернуться позже — и перезаписать актуальные данные. AbortController отменяет устаревший запрос на уровне сети, а не просто игнорирует ответ.

Можно ли обойтись без сторонней библиотеки для повторов?

Да, можно написать retry-логику вручную. Но это циклы, счётчики, экспоненциальная задержка и корректная обработка отмены. В продакшен-коде проще использовать готовое решение — ffetch, ky или axios — чтобы не изобретать велосипед и не допускать ошибок в edge-кейсах.

Работает ли этот подход с React / Vue / Angular?

Да. AbortController и retry-логика — это чистый JavaScript, независимый от фреймворка. В React, например, AbortController часто используется в useEffect для отмены запросов при размонтировании компонента. Принцип тот же: debounce для UI, отмена и повторы для сетевого слоя.

Выводы

Debounce — не проблема. Проблема — считать его полным решением для управления сетевыми запросами, когда он контролирует только одно измерение: частоту вызовов.

Debounce — это паттерн UI, а не паттерн работы с сетью. Чтобы построить надёжное приложение, нужно дополнить его управлением жизненным циклом запросов:

• Отмена устаревших запросов через AbortController
• Повторные попытки с экспоненциальной задержкой для транзиентных сбоев
• Корректная обработка HTTP-ошибок (проверка response.ok или автоматический проброс через библиотеку)

Тогда UI будет не только отзывчивым, но и точным — даже при непредсказуемых сетевых условиях.

Адаптированный перевод статьи Your Debounce Is Lying to You Габора Кооша (Gabor Koos).

WordPress часто не любят backend-разработчики, и у каждого на это есть свои причины. Кому-то не нравится функциональный стиль разработки, кто-то критикует form-builder и экосистему плагинов. У других WordPress как CMS и PHP как язык программирования до сих пор ассоциируются со стереотипами 10–15-летней давности - будто они устарели и уступают современным технологиям.

При этом реальность такова, что и PHP, и WordPress - отличные и современные инструменты, которые очень хорошо выполняют свои задачи. Опустим PHP - статья не об этом. Что же можно сказать про WordPress как про продукт и как CMS?

WordPress по‑прежнему остаётся самой популярной системой управления контентом. Согласно данным команды WordPress, платформа обслуживает более 43% всех веб-сайтов и занимает долю в 61% на рынке CMS. Также статистика показывает, что WordPress используется примерно на 59% сайтов, где известна CMS (это около 42% всего веба).

Данные были взяты из официального блога WordPress и сайта w3techs.com:

• https://wordpress.com/blog/2025/04/17/wordpress-market-share/
• https://w3techs.com/technologies/overview/content_management
• https://w3techs.com/technologies/details/cm-wordpress

При этом, традиционный WordPress объединяет CMS, шаблоны на PHP и монолитные темы. Такая связка усложняет разработку с использованием современных JS фреймворков, а также затрудняет независимое масштабирование фронтенда и бэкенда, и оптимизацию производительности и безопасности. Жёсткая связка страниц, устаревшие PHP‑функции и не самый удобный девелоперский опыт часто заставляют команды искать альтернативы.

Headless WordPress решает эти проблемы: CMS становится админ-панелью для управления контентом, а отдельный фронтенд отвечает за UI. Такое разделение обязанностей даёт несколько преимуществ: четкое разделение ответственности, независимое масштабирование интерфейса и CMS, упрощенную локальную разработку и CI/CD. CMS превращается в API‑ориентированное хранилище, а современные фреймворки вроде Next.js берут на себя маршрутизацию и рендеринг.

Headless WordPress с использованием WPGraphQL

Чтобы использовать WordPress как headless‑CMS, нужен API. Также есть интересный пост про headless wordpress в их официальном блоге.

В WordPress из коробки есть REST API, но для frontend и mobile приложений часто удобнее использовать GraphQL. WPGraphQL - это open source плагин, который добавляет GraphQL API в WordPress. Используя WPGraphQL, мы получаем:

• Гибкие запросы к таким сущностям, как посты, страницы, произвольным типам постов, таксономиям и пользователям.
• Систему расширений которая позволяет расширять функционал GraphQL бекенда и таким образом поддерживать популярные плагины, тем самым позволяя возвращать дополнительные поля которые не относятся к стандартным полям Wordpress.
• GraphQL API, который даёт очень удобный формат для интеграции фронтенд фреймворков таких как Next.js, Astro и SvelteKit.
• Оптимизацию производительности, поскольку клиент запрашивает только нужные поля и данные делая один запрос вместо группы REST запросов + отдельный фронтенд забирает на себя часть запросов.

В дополнение к доступному функционалу WPGraphQL можно добавлять дополнительные плагины-расширения, такие как WPGraphQL Yoast SEO и WooGraphQL (WPGraphQL для WooCommerce). Таким образом добавив несколько плагинов в базовую инсталляцию CMS можно из коробки получить полностью функциональный GraphQL бекенд, который может покрыть запросы для блога, сео функционал, онлайн-магазин и тд.

Важно отметить, что изначальная идея использовать WPGraphQL пришла из статьи в блоге Vercel.

Фронтенд на Next.js

Next.js - production-ready React-фреймворк, который разрабатывается компанией Vercel. Многие используют его по умолчанию для разных headless‑проектов. Наш пример headless-wordpress не исключение. Фреймворк предлагает удобную маршрутизацию на базе файловой системы, где любой файл в папке pages автоматически становится маршрутом и поддерживает несколько стратегий рендеринга:

• Server‑side rendering (SSR) позволяет генерировать HTML при каждом запросе.
• Статическая генерация (включая [Incremental Static Regeneration])
• React Server Components, стратегия которая дает гибкость в балансировании производительности и кэширования.

Это делает Next.js хорошей платформой для работы с GraphQL API и рендеринга страниц React‑компонентами. Если у вас нет опыта с Next.js и React, то это не повод не попробовать набросать POC в свободное время. Современные Next.js и React templates + хороший AI agent помогут адаптировать UI под GraphQL для вас.

Почему Cloudflare?

Vercel очень часто является платформой по умолчанию для Next.js‑приложений. Более того Next.js адаптирован для запуска из коробки на серверах Vercel. При этом нужно добавить, что идея этой статьи не в том чтобы как-то компрометировать Vercel. Что же нужно знать про Cloudflare чтобы обратить внимание на этот сервис с точки зрения альтернативы для хостинга Next.js?

Согласно статистике, реверс-прокси сервисы Cloudflare используются примерно на 21,9% всех сайтов в интернете, а это более 82% сайтов, где используется прокси‑сервисы в принципе. Такая распространённость говорит о масштабе, надежности и глобальном охвате сервиса. Но Cloudflare - это не только reverse-proxy. Компания разрабатывает целую группу облачных сервисов, включая такие сервисы, как Cloudflare Pages - альтернатива Github Pages, Workers - Serverless functions (по аналогии с AWS Lambda), Контейнеры, Очереди, AI сервисы, R2 Object Storage, и другие. В дополнение ко всему, компания предоставляет такие сервисы, как защита сайта (site-protection), VPN и капча (human-detection captcha). Такое разнообразие сервисов делает сервис очень распространенным.

Лимиты бесплатного тарифа Cloudflare

Одним из самых интересных аргументов в пользу Cloudflare можно считать их бесплатный тариф. Защита от DDoS, Universal SSL и глобальную CDN доступны бесплатно. Также бесплатный тариф включает большинство из вышеперечисленных облачных сервисов. Например, Cloudflare Workers, который можно использовать для хостинга Next.js-проектов, бесплатно даёт 100,000 запросов в день. Или R2 object storage - альтернатива S3 по умолчанию дает 10GB пространства, которое можно использовать для хранения статики или других данных. Этого более чем достаточно чтобы поэкспериментировать на выходных с новым стеком и вполне достаточно для того, чтобы бесплатно хостить ваш проект до тех пор пока у вас не пойдет серьезный трафик. Ниже приведена таблица с некоторыми из Cloudflare сервисов и что включено в бесплатный тариф.

Запуск Serverless функций на edge-серверах

Cloudflare Workers позволяют запускать серверлесс‑код по всей сети Cloudflare. Ниже приведено изображение показывающее как работает Edge CDN, когда например статика продублирована на все доступные сервера и таким образом пользователь получает ресурсы с самого близлежащего сервера.

Эта картинка хороша тем, что аналогично CDN статике на этих же серверах можно запускать и Workers (Lambda) функции, тем самым ускоряя вашу инфраструктуру еще больше.

Одной из интересных особенностей Workers-функций является отсутствие cold-starts. Любой cloud provider обычно подымает docker container или виртуализированное окружение в момент первого запуска программы, а это всегда задержка. Минусом Workers-функций является тот факт что их Runtime API требует чтобы код мог использовать их Web platform APIs. А это в свою очередь ограничивает выбор языка программирования: Javascript, Typescript и WebAssembly. Но благодаря такому подходу Workers используют изолированную модель запуска и могут быть прогреты еще до момента запуска кода этого воркера. Прогрев начинается еще на этапе TLS-соединения между клиентом и серверами Cloudflare. Полный текст статьи можно почитать в их блоге.

Воркеры выполняются на edge-серверах, которые находятся ближе всего к пользователям, тем самым уменьшая задержку и разгружая origin‑сервер (в нашем случае WordPress backend). По аналогии с другими cloud-провайдерами, код внутри Workers Runtime может использовать другие сервисы Cloudflare, такие как:

• Cache API - позволяет читать и записывать данные в глобальный edge‑кэш через caches.default, что удобно для кэширования GraphQL‑ответов или страниц Next.js.
• Workers KV - распределенное key‑value‑хранилище для конфигурации и небольших наборов данных; можно хранить и получать данные глобально с низкой задержкой.
• Cron Triggers - можно сопоставить cron‑выражение с обработчиком scheduled(), чтобы запускать периодические задачи, например, уборку кэша или обновление данных. Триггеры выполняются на малоиспользуемых машинах, максимизируя эффективность.

Наличие доступа к дополнительным сервисам, таким как базы данных (D1), объектное хранилище (R2), очереди и AI даёт свободу строить более сложные и гибкие архитектуры, что очень полезно в дальнейшем на больших масштабах.

OpenNext: мост между Next.js и Cloudflare

Самостоятельный деплой Next.js на разные платформы непрост, поскольку среда исполнения Vercel отличается от других. Можно поднять Next.js на Node‑сервере, но его работа отличается от edge‑режима Vercel. OpenNext - это проект с открытым исходным кодом, который адаптирует Next.js для разных серверлесс‑платформ. Важно сказать что у Next.js нет нативного способа само разворачивания на других платформах, кроме Vercel; существующие отдельные адаптеры разрознены и сложны в поддержке. OpenNext объединяет усилия в одном адаптере, переводя выход сборки Next.js в формат, совместимый с основными облачными платформами. Проект поддерживают сообщество SST (AWS), команда Cloudflare и Netlify. Соответственно, с помощью OpenNext можно развернуть Next.js на Cloudflare Workers, сохраняя SSR, статическую генерацию и API‑маршруты.

Cloudflare‑адаптер устанавливается через @opennextjs/cloudflare. Далее следует установить Wrangler, настроить wrangler.toml с вашим Account ID и создать open-next.config.ts для управления кэшем и ассетами. Адаптер собирает приложение Next.js под среду Cloudflare, создает edge‑воркер и конфигурирует кэш для статики и ISR‑страниц (например, используя R2). После публикации Git‑интеграция Cloudflare автоматически разворачивает приложение при каждом пуше в GitHub или GitLab, а для pull‑request создает превью.

Кэширование и уровни производительности

Архитектура headless WordPress + Next.js + Cloudflare обычно включает несколько уровней кэша:

1. Кэш браузера - стандартный HTTP‑кэш на стороне клиента.
2. Кэш edge‑рантайма - Cache API Cloudflare Workers сохраняет HTML‑страницы или GraphQL‑ответы рядом с пользователем; при попадании в кэш контент отдаётся мгновенно, а промахи идут к воркеру или origin.
3. Кэш ISR Next.js - технология Incremental Static Regeneration сохраняет отрендеренные страницы на сервере и обновляет их по запросу, снижая нагрузку на WordPress API.
4. Кэш GraphQL - API WPGraphQL может реализовывать кэширование по времени или тегам (например, через WPGraphQL Smart Cache), чтобы управлять сроком жизни ответов.

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

Пример конечной архитектуры показан на изображении ниже.

Автоматизация периодических задач

Headless‑сайтам часто требуются периодические действия - например, обновление кэша ISR или синхронизация данных. Cron Triggers Cloudflare позволяют планировать запуск воркера по cron‑выражению. Обработчик scheduled() срабатывает по расписанию и подходит для обслуживания и получения сторонних данных. Триггеры выполняются на малоиспользуемых машинах по всему миру и легко управляются через Wrangler или панель Cloudflare.

Модернизация PHP‑стека с Roots toolkit

Хотя headless WordPress переносит рендеринг на JavaScript, CMS всё ещё нужно поддерживать. В качестве бонуса хочется порекомендовать экосистему Roots, которая предлагает современный инструментарий для разработки на WordPress:

• Bedrock - шаблон WordPress, которая устанавливает ядро, плагины и темы через Composer. Таким образом Bedrock дает современную для PHP проектов структуру проекта, улучшает структуру папок, использует концепты Двенадцать факторов для конфигурации приложения с помощью .env‑файлы и тд. Более того, управление зависимостями через Composer повышает надежность и позволяет делать деплой приложения на разные сервера без страха что-то забыть или упустить.
• Sage - стартовая тема WordPress, использующая Blade от Laravel для шаблонов и интегрирующая Tailwind CSS. Sage автоматически генерирует theme.json из конфигурации Tailwind, поддерживает live preview блокового редактора с Vite и позволяет создавать компоненты на Blade. Это помогает фронтенд‑разработчикам отойти от устаревших подходов для разработки тем Wordpress с нуля.
• Trellis - DevOps‑инструмент на базе Ansible, который поднимает серверы и автоматизирует деплой. Trellis предоставляет LEMP‑стек (Ubuntu 24.04, Nginx, PHP 8.3, MariaDB), выполняет деплой без downtimes и из коробки поддерживает SSL‑сертификаты. CLI помогает создавать и настраивать серверы, а также разворачивать проекты с атомарными релизами и откатами.
• Acorn - интеграция, позволяющая использовать функционал Laravel в WordPress. С Acorn становятся доступны такие инструменты как Blade‑шаблоны, миграции, роутинг, кэширование и Artisan‑подобный CLI внутри WordPress. Это позволяет разработчикам строить плагины и фичи WordPress с использованием современных PHP‑подходов и современного фреймворка .

Эти инструменты показывают, что экосистема WordPress продолжает развиваться и хорошо сочетается с современными подходами. Иными словами, WordPress - отличное решение, если знать, как его правильно готовить.

Собираем всё вместе

Архитектура приложения headless WordPress + Next.js + Cloudflare выглядит приблизительно так:

1. WordPress (headless) - работает на традиционном сервере или в контейнере. Редакторы управляют контентом в админке. WPGraphQL и его расширения предоставляют GraphQL‑endpoint с данными, SEO и другой информацией, например данными о магазине.
2. Next.js фронтенд - React‑приложение, которое получает данные через GraphQL, рендерит страницы на сервере (SSR) или статически (ISR/SSG) и обрабатывает маршрутизацию и взаимодействие с клиентом. Код хранится в Git и автоматически разворачивается благодаря Git‑интеграции Cloudflare.
3. Cloudflare Workers - размещают приложение Next.js на edge через OpenNext. Workers исключают cold-starts и работают по аналогии с CDN как можно ближе к пользователю. Они также выполняют кэширование, обрабатывают API‑маршруты и запускают cron‑задачи.
4. Кэш на edge и в браузере - несколько уровней кэша гарантируют быструю отдачу статики и отрендеренных страниц. KV, R2 или D1 могут хранить дополнительные данные вроде сессий или объектов.

Заключение

Headless‑архитектура объединяет универсальность WordPress и гибкость современных JavaScript‑фреймворков. Экспонируя контент через WPGraphQL и потребляя его в Next.js, можно получить больше контроля над рендерингом и тем самым улучшить производительность. Размещение фронтенда на Cloudflare Workers через OpenNext позволяет приблизить фронтенд код к пользователям, устраняет cold-starts, позволяет использовать free-tier и продвинутые уровни кэширования. Инструменты вроде Bedrock, Sage, Trellis и Acorn модернизируют PHP/Wordpress‑сторону и делают CMS такой же удобной в работе, как и современный Next.js/React-фронтенд. Вместе эти технологии создают мощный стек для создания быстрых, масштабируемых и безопасных сайтов, будь то хакатон, pet‑проект или серьёзный продакшн.

Зачем это нужно?

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

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

Руководство построено на небольших примерах, чтобы понять технические детали и сформировать интуитивное понимание работы браузеров.

Чтобы материал оставался кратким и по существу, автор намеренно опустил многие критические детали: разные версии HTTP-протокола, SSL, TLS, нюансы работы DNS и многое другое.

Браузеры работают с URL

Вы можете ввести в адресную строку буквально что угодно. Но под капотом браузеры работают с URL:

• Случайный текст вроде «pizza» будет преобразован в поисковый URL типа https://google.com/search?q=pizza
• Доменное имя вроде example.com будет нормализовано в полный URL: https://example.com

Чтобы увидеть, как это работает на практике, попробуйте ввести «pizza» или «example.com» в адресную строку браузера.

Превращение URL в HTTP-запрос

Когда браузер знает точный URL, который нужно посетить, он может отправить запрос на сервер, чтобы получить ресурс и отобразить его. Браузеры общаются с серверами по протоколу HTTP.

Чтобы понять, как URL переводится в формат HTTP-запроса, рассмотрим пример с полным URL вроде example.com.

HTTP-запросы содержат заголовки в таком формате:

Один из заголовков — это заголовок Host. Он используется для идентификации сервера, на который отправляется запрос: example.com.

Определение адреса сервера

Браузеры не могут отправлять запросы на имена вроде example.com.

Компьютеры общаются с IP-адресами, поэтому браузер сначала обращается к системе DNS, чтобы преобразовать доменное имя в IP-адрес, прежде чем подключиться к серверу и отправить HTTP-запрос.

Например, если вы введёте в терминале команду для разрешения домена, DNS вернёт соответствующий IP-адрес:

Установка TCP-соединения

После того как DNS предоставил браузеру IP-адрес, всё ещё требуется надёжное соединение с сервером. TCP — это протокол, который устанавливает такое соединение до того, как будут отправлены любые HTTP-данные.

TCP устанавливает соединение с помощью трёхэтапного согласия, которое подтверждает, что обе стороны готовы отправлять и получать данные:

1. SYN: клиент отправляет свой порядковый номер (seq=1000), чтобы открыть соединение
2. SYN-ACK: сервер подтверждает пакет, добавляя свой порядковый номер (seq=5000) и подтверждая номер клиента, увеличивая его на 1 (ack=1001)
3. ACK: клиент подтверждает номер сервера, увеличивая его на 1 (ack=5001), и соединение готово

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

Когда вы начинаете отправлять пакеты и пытаетесь нарушить работу сети, вы можете увидеть, как TCP справляется с потерями данных и восстанавливает передачу.

HTTP-запросы и ответы

После установки TCP-соединения браузер может отправить HTTP-запрос на сервер.

Представьте, что вы наблюдаете за тем, как HTTP-запрос путешествует к серверу, а HTTP-ответ возвращается в браузер:

БРАУЗЕР (КЛИЕНТ)

СЕРВЕР

Когда приходит HTTP-ответ, браузер читает сырой HTTP-ответ и начинает рендеринг HTML-контента.

Парсинг HTML для построения DOM-дерева

После того как приходит HTTP-ответ, браузер отделяет заголовки от тела и направляет HTML-байты в парсер. Парсер превращает теги вроде <h1> в токены и строит DOM-дерево.

Посмотрите, как HTML-поток парсится в DOM-дерево:

DOM-дерево:

Парсинг происходит потоково и устойчив к ошибкам: браузер начинает строить узлы ещё до того, как документ полностью загружен, и вставляет недостающие теги, чтобы дерево оставалось валидным. Когда появляется тег <script>, парсинг может приостановиться, чтобы выполнить скрипт.

DOM-дерево затем объединяется с CSS, чтобы создать render tree (дерево рендеринга), которое используется для расчёта layout и отрисовки пикселей.

О важности DOM

DOM — это внутренняя модель документа в памяти браузера. Это общий контракт между HTML-парсером, движком CSS-селекторов и средой выполнения JavaScript. Изменения в DOM немедленно влияют на layout, стили и то, с чем пользователи могут взаимодействовать.

DOM обеспечивает всё: от выборки элементов до динамической стилизации и обработки событий. Попробуйте отредактировать JavaScript-код и посмотрите, как меняется DOM:

Редактируемый JavaScript:

Живой DOM:

Layout, Paint и Composite

После того как DOM и CSS готовы, браузер запускает конвейер рендеринга: Layout (reflow) для расчёта размеров и позиций, Paint для заполнения пикселей, затем Composite для сшивки слоёв на GPU.

Не каждое изменение запускает все этапы заново. Изменение цвета обычно требует только перерисовки (repaint), тогда как изменение размеров заставляет пересчитывать layout и paint.

Этапы рендеринга:

1. Layout — пересчёт размеров и позиций
2. Paint — заполнение пикселей в слои
3. Composite — сшивка слоёв на GPU

Пример DOM:

Composite всегда смешивает слои в финальный кадр.

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

Вот и всё! Если вы разобрались со всеми примерами, у вас должна сформироваться чёткая ментальная модель работы браузеров.

Теперь вы понимаете путь от ввода URL в адресную строку до отображения пикселей на экране: разрешение DNS, установку TCP-соединения, отправку HTTP-запросов, парсинг HTML, построение DOM и конвейер рендеринга с этапами Layout, Paint и Composite.

Новую волну вредоносных Android-приложений обнаружили специалисты Dr.Web.

Как работают «умные» трояны

В основе новой схемы — TensorFlow.js. Это open-source библиотека от Google, которая позволяет запускать модели машинного обучения прямо в JavaScript. Вместо заранее заданных правил, троян анализирует изображение экрана и сам определяет, куда «нажать».

Сценарий выглядит так:

• троян загружает обученную ML-модель с удаленного сервера;
• открывает сайт с рекламой во встроенном скрытом WebView;
• делает скриншоты виртуального экрана;
• модель распознает нужные элементы (кнопки, видео, баннеры);
• вредоносное ПО имитирует реальные действия пользователя.

За счет визуального анализа, троян лучше адаптируется к современным рекламным форматам: динамической верстке, iframe, видео и постоянно меняющимся шаблонам.

Два режима работы: автономный и ручной

По данным Dr.Web, трояны используют сразу два режима.

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

Signalling-режим. Это уже более опасный вариант, при котором через WebRTC троян транслирует экран виртуального браузера операторам атаки. Злоумышленники могут в реальном времени нажимать, скроллить и вводить текст, управляя устройством удаленно.

Где распространяется вредоносное ПО

Часть зараженных приложений попала даже в Xiaomi GetApps — официальный магазин приложений компании. Схема классическая: сначала на площадку загружается «чистая» игра, а вредоносный функционал появляется позже, через обновление.

Среди выявленных приложений — мобильные игры с десятками тысяч установок. Параллельно трояны активно распространяются через сторонние APK-сайты и «моды» популярных сервисов вроде Spotify и YouTube, а также через Telegram-каналы и Discord-серверы.

Почему это опаснее обычного кликфрода

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

• пользователь не видит подозрительных действий;
• ускоряется разряд батареи и износ устройства;
• растет расход мобильного трафика;
• рекламные системы получают фейковую «человеческую» активность, которую сложнее отфильтровать.

Главное же — это сигнал: ИИ все чаще используют не только для защиты, но и для атак. Вредоносное ПО постепенно перенимает те же инструменты, что и легальные разработчики.

Что делать пользователям

Рекомендации остаются простыми и банальными, но от этого не менее важными:

• не устанавливать APK из сторонних источников;
• избегать модов и бесплатных премиум-версий приложений;
• внимательно относиться даже к альтернативным официальным магазинам;
• регулярно обновлять систему и защитное ПО.

Подборка в этом материале опирается на TIOBE Index — международный рейтинг популярности языков программирования, который ежемесячно формируется на основе данных поисковых систем, количества обучающих материалов и активности профессионального сообщества. Некий индикатор того, где сейчас сосредоточен реальный спрос.

Разберём на примере семи самых рейтинговых языков, какие из них логично рассматривать в 2026 году (и логично ли) действующим разработчикам, и из каких стеков в них входить быстрее всего.

Python в 2026: универсальный усилитель для бэкенда, данных и ИИ

В 2026 году Python остаётся языком, который проще всего встроить в уже существующий стек. Он живёт в областях, где важны скорость разработки и плотность экспериментов: машинное обучение и прикладные AI-задачи, data engineering и ETL-процессы, автоматизация рутинных операций, разработка девтулов и утилит; а также в бэкенде, где критичнее гибкость, чем низкоуровневая оптимизация.

Переходить на Python проще всего тем, кто привык мыслить объектно и работать с динамикой. Самый оптимальный вариант — из JS, PHP и Java:

• Разработчики на JavaScript уходят в питон почти бесшовно: есть близкие модели данных, схожая философия быстрого прототипирования и огромная база библиотек.
• PHP-разработчики адаптируются к языку благодаря знакомому подходу к бэкенд-логике и работе с фреймворками, но есть принципиальная разница к подходам с типизацией.
• Преимущества для Java-специалистов в понятном синтаксисе и лаконичности Python, поэтому переход также возможен.
• Аналитики и тестировщики переходят на Python через практику: скрипты автоматизации быстро превращаются в продуктивные инструменты.

Порог входа низкий: синтаксис прямолинейный, в экосистеме есть готовые решения почти на каждый случай, а первые практические результаты появляются через считанные недели. Но это же создаёт риски. Так как вход в язык относительно лёгкий (это подтверждает первое место в рейтинге) — конкуренция высокая, особенно в прикладном ML. Кроме того, в высоконагруженных системах, где важна каждая микросекунда, асинхронное программирование и управление памятью требуют глубоких знаний, выходящих за рамки базового синтаксиса.

Python — не лучший выбор для тех, кто работает в системном программировании, embedded или инфраструктуре на C/C++. В этих задачах важна предсказуемость управления памятью, а не удобство разработчика.

C в 2026: опорный язык для embedded, драйверов и систем реального времени

В 2026 году С остаётся фундаментом там, где железо важнее абстракций. Он работает на микроконтроллерах, в промышленной автоматике, драйверах, прошивках и в RTOS-средах, где критична предсказуемость времени выполнения и полный контроль над ресурсами. Это язык, вокруг которого ещё долго будут строиться системы, способные жить десятилетиями.

Проще всего переход даётся тем, кто уже держал в руках низкоуровневый стек — в C можно войти из C++ и эмбеда:

• Переход с C++ на C естественен из-за общей модели памяти и необходимости понимать стоимость операций.
• Специалисты по встраиваемым системам (embedded) часто начинают с C/C++ и глубоко понимают аппаратную часть, что делает переход к чистому C логичным.

Вход кажется простым только внешне. Настоящая работа начинается там, где ответственность лежит за всё — от выделения памяти до обработки ошибок. Минимум встроенных защит и отсутствие автоматического управления ресурсами требуют инженерной дисциплины. Ошибки в C редко проявляются спокойно: они выливаются в падения, утечки, нестабильные устройства и долгие ночи с отладчиком.

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

Не стоит идти в C тем, кто работал только в веб-стеке и никогда не сталкивался с ограничениями железа. В отличие от Python, ориентированного на скорость разработки и обладающего автоматическим управлением памятью, C требует полного низкоуровневого контроля над ресурсами, что создаёт огромный разрыв в парадигмах программирования. Путь в продакшен может превратиться в затяжной стресс вместо профессионального роста.

C++ в 2026: высокопроизводительные системы, игры и сложная инженерия

В 2026 году C++ остаётся рабочей лошадкой там, где важны скорость, предсказуемость и возможность вручную управлять каждым уровнем системы. Он используется в игровых движках, графических пайплайнах, симуляторах, системах хранения и в любом ПО, где миллисекунды стоят денег или определяют игровой опыт. Это язык, который не потерял актуальность и вряд ли потеряет — слишком много инфраструктуры на нём держится.

Проще всего переходят те, кто уже понимает низкоуровневую модель — специалисты по C и Rust:

• Разработчики на C чувствуют себя здесь как дома, ведь не теряют контроль и получают больше инструментов.
• Тем, кто пришёл из Rust, знакомы принципы безопасности памяти, хотя в C++ они реализованы иначе.

Главное преимущество C++ остаётся неизменным: он позволяет строить системы, где скорость и контроль указаны в требованиях. Производительность, доступ к железу, возможность оптимизировать всё вручную — это сильные стороны, благодаря которым язык удерживает позиции в самых сложных доменах. Вместе с этим растёт и планка задач: на C++ редко делают что-то простое, и это превращает язык в сильный показатель инженерной зрелости.

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

Переход оправдан тогда, когда нужна работа в performance-доменах: игровой dev, real-time-системы, графика, симуляции, базы данных. Если задачи требуют скорости и полного контроля над процессом — C++ остаётся одним из самых мощных инструментов для этого уровня.

Java в 2026: стабильный корпоративный бэкенд и инфраструктура, которая не рушится

В 2026 году Java остаётся одним из самых устойчивых языков для корпоративных систем. Банки, страховые компании, платёжные сервисы, крупные ритейлеры и весь классический enterprise-сегмент продолжают работать на JVM-стеке, потому что он проверен, масштабируется и выдерживает десятки лет развития продукта.

Переход проще всего даётся тем, кто уже жил в объектно-ориентированной модели — C#, Kotlin.

• C#-спецы попадают почти в привычную среду, где меняются лишь инструменты, но не логика разработки.
• Kotlin-разработчики ощущают Java как чуть более формальную, но узнаваемую основу JVM.

Java остаётся рабочим языком по очень приземлённым причинам. Объём существующего кода огромный, и его нужно поддерживать, развивать, переписывать и интегрировать с современными сервисами. Стабильность и предсказуемость стека — редкая ценность в отрасли, где технологии меняются каждые пару лет. Java хорошо масштабируется, отлично ложится на корпоративные процессы, имеет зрелые фреймворки и помогает разработчикам быть востребованными в крупных компаниях, где команды десятилетиями развивают один продукт.

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

Язык подойдёт тем, кто хочет развивать крупные платформы, работать с надёжной архитектурой и видеть долгосрочный эффект от своих решений. Если цель — предсказуемый рост, корпоративный бэкенд и инфраструктура, Java в 2026 остаётся одной из самых практичных точек входа.

C# в 2026: универсальный стек для бэкенда, геймдева и кроссплатформы

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

Чаще всего C# живёт в web-бэкенде, корпоративных приложениях и десктопных продуктах — там, где важны производительность, предсказуемость и хорошая интеграция с инфраструктурой. Unity по-прежнему остаётся главным входом в геймдев для начинающих, и именно через него многие приходят в C#, а не наоборот.

Переходить сюда проще Java-разработчикам, из-за схожего объектно-ориентированного синтаксиса.

C# усиливается благодаря развитию .NET и всё более уверенной кроссплатформенности. Этому стеку уже не нужно доказывать свою жизнеспособность: он стабильно используется в компаниях разного масштаба, даёт хороший гарантированный спрос на рынке и регулярно обновляется без резких ломок экосистемы.

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

JavaScript в 2026: опора веба и самый быстрый путь в fullstack

В 2026 году JavaScript остаётся одним из главных рабочих языков для продуктовых команд: он ведёт фронтенд, закрывает часть бэкенда через Node.js и работает в мобильных приложениях.

Перейти сюда проще всего тем, кто уже работал с вебом — PHP и Python:

• PHP-разработчики смогут быстро адаптироваться к асинхронности и современным подходам.
• Python-разработчики оценят низкий порог входа и скорость, с которой можно развернуть рабочий прототип.

JavaScript остаётся одним из ключевых языков из-за ширины экосистемы и того, что браузер задаёт технические ограничения и возможности для всего фронтенда. Он хорошо масштабируется на фуллстек, что делает его удобным языком для продуктовых команд, которым важен быстрый цикл разработки.

Главный вызов — JS быстро меняется, и это требует регулярных вложений времени в поддержание компетенций.

JavaScript — лучший выбор, если нужен быстрый переход в другой домен без полной переучки: от фронтенда к бэкенду, от веба к мобильному приложению, от продуктового стека к созданию собственных инструментов.

Visual Basic в 2026: язык, который до сих пор жив

В 2026 году Visual Basic — это язык, который держится за счёт огромного слоя легаси-систем, внутренних корпоративных решений и автоматизаций вокруг Office. Он живёт там, где продукт работает много лет и стабильно приносит деньги, но уже устаревает.

Visual Basic всё ещё встречается в старых внутренних продуктах, отчётных системах, инструментах на базе Excel и в корпоративных контурах, которые строились до эпохи массовой веб-разработки.

Почему язык до сих пор всплывает в индексах и рейтингах? Потому что огромный пласт кода всё ещё выполняется в продакшене. Бизнес выбирает стабильность: если система работает, её не переписывают.

Входить в Visual Basic с нуля в 2026 году почти никогда не рационально. Это не инвестиция в карьеру, а узкая специализация, завязанная на конкретный контур внутри конкретной компании. Смысл появляется только в одной ситуации: вы уже работаете в организации, которая держит ключевую систему на VB, и переход даёт повышение или расширение роли. Но если слишком хочется, то ориентируйтесь на требования конкретной компании.

Почему не стоит слепо доверять общим рейтингам языков

Важно сделать оговорку: любые общие рейтинги языков программирования — включая TIOBE — дают лишь приближённую картину и не могут служить прямой инструкцией к выбору стека.

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

Именно поэтому у практикующих разработчиков рейтинги часто вызывают скепсис. В реальной работе языки живут внутри конкретных областей. Геймдев не переезжает на Python или TypeScript, мобильная разработка не отказывается от Swift и Kotlin, системное программирование, embedded и highload по-прежнему требуют C, C++ или Rust. Универсального списка «главных языков года» просто не существует — есть разные наборы под разные задачи.

Отдельный аргумент — рынок вакансий. Он часто даёт более приземлённую картину спроса, чем глобальные индексы. Например, как сообщает Евгений Красников, разработчик ПО, в лидерах оказываются совсем не те языки, которые традиционно доминируют в международных чартах: высокие позиции занимают 1С, Python, Java, JavaScript, PHP, Go. Это не отменяет глобальных трендов, но показывает, насколько сильно результаты зависят от региона и структуры экономики.

Ещё одна проблема рейтингов — они плохо учитывают влияние ИИ на разработку. Да, сегодня Python и JavaScript действительно выигрывают за счёт того, что на них проще и быстрее генерировать код с помощью AI-инструментов. Но это не означает, что весь новый софт будет писаться только на них. Языки по-прежнему выбирают под требования к производительности, безопасности, модели исполнения и жизненному циклу продукта — и эти требования никуда не исчезли.

Поэтому подборка языков в этом материале — не попытка назвать «лучшие языки 2026 года», а способ показать набор устойчивых стеков, которые логично рассматривать при обновлении навыков. Рейтинги здесь — отправная точка для разговора, а не истина в последней инстанции. В реальности язык почти всегда выбирается не по позиции в индексе, а по домену, типу задач и карьерной стратегии разработчика.

Как выбрать язык для перехода: дорожная карта

Обновление стека приносит пользу только тогда, когда связано с реальными задачами и карьерной траекторией. В 2026 году переходы лучше совершать горизонтально: оставаться в своём направлении, но расширять инструменты, чтобы работать быстрее и закрывать больше типов задач.

Основой выбора остаются три фактора: текущий стек; домен, в котором вы уже сильны; рынок, куда хотите сместиться (корпорации, международные компании или продуктовые команды).

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

Если выбирать наиболее безопасную стратегию, то это переход внутри текущего направления. Например:

– backend → backend на другом языке;

– data → data с расширением инструментов;

– frontend → fullstack как способ увеличить гибкость и ценность в команде.

Такой подход позволяет нарастить стек, не теряя опыт, и быстрее выйти на уровень, где новый инструмент начинает приносить отдачу (и деньги).

Ну и напоследок даем совет от Игоря Алентьева, продуктового разработчика и создателя агрегатора IT-вакансий hirify.me.

Нет никакого смысла учить в 2026 что то кроме питона и js/ts: весь новый софт пишется на них (не в последнюю очередь, потому что на них отлично пишет AI), поэтому если нет исключительной любви к легаси или какому-то определенному языку, просто берите их и не ошибетесь.
Если есть любовь к энтерпрайзному софту, всяким банкам/телекомам, то подойти могут java/kotlin/c#. Но это нисходящий тренд на горизонте 5-10 лет.
В целом, нужно учиться работать с AI, ведь через какое-то количество лет код не будут писать руками, только проектировать.

Желаем удачи в переходе на новый язык!

Большинство языков ушли в историю — но идея русскоязычного программирования неожиданно получила продолжение.

В 2025 году преподаватели Пензенского университетаперевелисинтаксис JavaScript на кириллицу и уже обучают студентов писать код без единой латинской буквы.

В статье рассказываем, как работали русскоязычные ЯП, почему они появились именно в СССР, какие задачи решали и что с ними стало после распада Союза — некоторые идеи актуальны до сих пор.

1. Рапира

Язык придумали в 1987 году в Институте систем информатики им. А.П. Ершова в Новосибирске. Название расшифровывается как «Русский Алгоритмический Процедурный Императивный Расширяемый Адаптируемый».

Рапиру создавали для обучения программированию школьников и студентов. Синтаксис использовал русские ключевые слова:

• проц вместо function,
• цел вместо int,
• вывод вместо print.

Язык поддерживал процедуры, функции, массивы, работу с файлами и базовые структуры данных.

Рапиру преподавали в советских школах и вузах с конца 1980-х до середины 1990-х годов. После распада СССР язык исчез из учебных программ — его вытеснили Pascal и Basic.

Сегодня язык не поддерживается, компиляторы не обновляются, сообщества разработчиков не существует. Исходный код программ на Рапире сохранился только в архивах и учебниках того времени.

2. ПЭВМ Искра-1256

Безымянный язык программирования для компьютера «Искра-1256» появился в конце 1980-х годов. Машину выпускал Ленинградский завод имени Светланы для автоматизации офисной работы — учёта, делопроизводства, составления отчётов.

Разработчики встроили интерпретатор языка в ПЗУ компьютера, чтобы пользователи писали программы без установки дополнительного софта. Целевая аудитория — бухгалтеры, секретари, экономисты без технического образования.

Синтаксис копировал структуру русских предложений. Программист набирал команды в диалоговом режиме, интерпретатор выполнял их сразу после ввода.

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

«Искра-1256» выпускалась ограниченной серией и поставлялась в государственные учреждения. После 1991 года производство прекратилось. Компьютеры заменили на машины с DOS и Windows. Язык исчез вместе с платформой — портирование на другие системы не проводилось.

Сегодня информация о языке сохранилась в технических описаниях «Искры-1256» и воспоминаниях пользователей.

3. Эль-76

Это разработка конца 1970-х годов родом из Института точной механики и вычислительной техники в Москве. Язык придумали специально для суперкомпьютера «Эльбрус-1».

Эль-76 использовал русские ключевые слова и кириллицу для всех операторов. Синтаксис поддерживал структурное программирование — последовательности, ветвления, циклы. Программы разбивались на подпрограммы. Система типов хранила информацию о переменной вместе с её значением в памяти.

Язык применяли на суперкомпьютерах в оборонных предприятиях и научных центрах СССР. Машины поддерживали суперскалярность — выполнение нескольких инструкций за такт — и защитное программирование для критичных систем.

После распада Союза производство суперкомпьютеров прекратилось, Эль-76 перестали использовать. Сегодня процессоры «Эльбрус» выпускаются для государственных нужд, но работают с современными языками — C, C++, Fortran.

4. КуМир

КуМир (Комплект Учебных МИРов) разработан в НИИСИ РАН в начале 2000-х годов. Его создали для обучения школьников. В отличие от Рапиры и Эль-76, КуМир пережил свою эпоху.

Синтаксис использует русские ключевые слова:

• алг (алгоритм),
• нач (начало),
• кон (конец),
• цел (целое),
• нц (начало цикла).

КуМир включает визуальных исполнителей — Робот, Чертёжник, Черепаха. Школьник пишет команды вправо, вперед, закрасить и видит результат на экране. Исполнители помогают понять циклы, условия и процедуры без абстрактных примеров с числами.

Язык входит в школьную программу по информатике. Задания ЕГЭ публикуют на псевдокоде, который копирует синтаксис КуМира. Ученики решают задачи в среде КуМир, готовятся к экзамену.

Практическое применение ограничено образованием. КуМир не используют в коммерческой разработке, библиотек для веб-разработки или работы с базами данных. После школы ученики переходят на Python, JavaScript или C++.

5. АЛМИР-65

Название расшифровывается как «Алгоритмический язык для машины инженерных расчётов». Язык работал на компьютерах серии МИР — настольных машинах размером с письменный стол.

Синтаксис копировал математическую нотацию: формулы записывали почти так же, как в учебниках по математике. Инженер открывал руководство, смотрел пример и через час уже решал свои задачи без помощи программистов.

Язык обрабатывал числа с плавающей точкой, работал с массивами и матрицами. Компьютер МИР выводил результаты на экран сразу после ввода команды — диалоговый режим работы в 1965 году встречался редко.

АЛМИР-65 использовали конструкторские бюро, научные лаборатории и учебные заведения СССР. Инженеры рассчитывали прочность конструкций, физики моделировали эксперименты, студенты учились программированию. Идеи языка развили в АЛМИР-Аналитик.

6. Аналитик

Язык создали в 1968 году в Институте кибернетики АН УССР. Разработка продолжила линию языка АЛМИР-65. Первую версию Аналитика запустили на компьютерах МИР-2, созданных в том же институте.

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

В 1974 году вышла версия Аналитик-74 для компьютеров МИР-3. Язык применяли в научных расчётах — физике, математике, механике. Исследователи писали программы для вывода формул, дифференцирования, интегрирования, работы с матрицами и полиномами.

После распада СССР разработка не прекратилась, на его базе создали систему компьютерной алгебры Аналитик-2010. Современная версия работает на актуальных операционных системах и сохраняет идеи оригинального языка.

Практическое применение Аналитика ограничено академической средой.

7. Робик

Язык используют в российских школах с 2000-х годов. Синтаксис построен на кириллических ключевых словах.

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

Робик содержит три управляющие конструкции:

• цикл со счётчиком (нц 10 раз … кц),
• цикл с условием (нц пока свободно снизу … кц),
• условный оператор (если закрашена то … иначе … все).

Переменных, функций и типов данных нет — только последовательность команд.

Пример программы, которая закрашивает квадрат 3×3:

Робик входит в задания по информатике ОГЭ и ЕГЭ. Практическое применение ограничено образованием.

8. ДРАКОН

ДРАКОН разработали в 1980-х годах для советской космической программы. Расшифровка названия — Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность. Программист не пишет код, а рисует блок-схемы.

Язык использовали в НПО «Энергия» при разработке «Бурана». Сейчас существуют редакторы ДРАКОН-схем с генерацией кода на Python, C++, Java. Программист рисует схему, нажимает кнопку — получает исходники.

Практическое применение:

• документирование сложной логики,
• проектирование критичных систем,
• обучение алгоритмам.

ДРАКОН-схема заменяет десятки страниц технического описания.

9. ЯМБ

Язык Машин Бухгалтерских разработали в конце 1970-х годов. Название связывают с инициалами Марины Борисовны Ярошевской — руководителя группы разработки из СКБ ВТ «Искра».

ЯМБ использовал русскоязычный синтаксис — команды записывали кириллицей. Программисты писали на нём приложения для учёта материальных ценностей, начисления зарплаты, формирования отчётности.

Язык адаптировали под специфику бухгалтерских задач:

• работу с таблицами,
• суммирование колонок,
• форматирование документов.

Практическое применение ограничивалось советскими организациями. После перехода бухгалтерий на программы типа «1С» про ЯМБ забыли.

10. 1С:Предприятие

Платформу «1С:Предприятие» выпустили в 1991 году. Фирма «1С» создала её для автоматизации бухгалтерского учёта в российских компаниях.

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

Платформа генерирует интерфейсы и таблицы базы данных автоматически. Программист описывает структуру справочников, документов, отчётов в визуальном конфигураторе. Система создаёт формы ввода, списки, печатные формы без ручного написания SQL или HTML.

Язык запросов встроен в платформу — разработчик получает данные через конструкции типа ВЫБРАТЬ Номенклатура, Количество ИЗ Документ.Товары.

Рынок 1С существует параллельно классической разработке. Вакансий публикуют больше, чем по Rust или Swift. Специалисты пишут типовые конфигурации, дорабатывают учётные системы под требования заказчиков, интегрируют 1С с сайтами и CRM.

Выводы

Большинство языков исчезли вместе с платформами, для которых создавались. Рапира, Эль-76, АЛМИР-65, ЯМБ остались в архивах и воспоминаниях — их вытеснили международные стандарты.

Три проекта выжили:

• КуМир стал основой для подготовки к ЕГЭ.
• ДРАКОН занял нишу в документировании сложных систем.
• 1С превратилась в отдельную индустрию с десятками тысяч вакансий.

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

В 2026 году русскоязычные разработчики пишут на Python и JavaScript. Однако история советских языков напоминает: технологический суверенитет возможен, если есть задачи, ресурсы и готовность десятилетиями поддерживать разработку.

Тогда компании нанимали инженеров с запасом, под давлением цифровизации, дешевых денег и страха «остаться позади». По данным Indeed и FRED, пик вакансий пришелся на середину 2022 года. После чего последовал резкий спад, так и не вернувшись до прежнего уровня.

Почему ИИ — удобный, но не главный виновник

ИИ стал публичным оправданием сокращений. Заявление «мы заменяем людей на ИИ» хорошо смотрится в отчетах и перед инвесторами.

На практике же компании сокращали издержки, выравнивали штат и параллельно активнее нанимали за пределами США и Европы, где инженеры стоят дешевле.

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

Как будет выглядеть рынок в 2026 году

Эксперты сходятся во мнении: 2026 год пройдет в режиме «низкого найма — низких увольнений». Массовых сокращений не ожидается, но и бурного роста вакансий не будет. Так выглядит стабилизация рынка.

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

По прогнозу Бюро статистики труда США, число вакансий для разработчиков продолжит расти примерно на 15%. Это медленнее, чем ожидалось раньше, но все еще быстрее большинства профессий.

Почему джунам повезло меньше всего

Самое слабое место рынка — начальные позиции. Количество вакансий для junior-разработчиков упало примерно на 40% по сравнению с допандемийным уровнем.

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

Но это также создает отложенную проблему — без притока новичков рушится кадровый «конвейер».

Какие навыки реально востребованы

В 2026 году ценятся не языки сами по себе, а связки «язык + область».

Тот же Python чаще всего нужен при работе с ИИ и данными. JavaScript и TypeScript — для фронтенда и fullstack. Go — для бэкенда и инфраструктуры. Java — для enterprise-систем.

Параллельно растет спрос на ИИ- и дата-инженеров, а также специалистов по ИИ-инфраструктуре.

Технически любая веб-страница строится на трех технологиях:

• HTML (гипертекстовая разметка) задает структуру и содержание (заголовки, абзацы, кнопки).
• CSS (стили) определяет внешний вид (цвета, шрифты, расположение элементов).
• JavaScript отвечает за интерактивность и поведение всех элементов. Именно он заставляет страницу реагировать на действия пользователя.

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

Почему JavaScript — оптимальный первый «настоящий» язык программирования для детей

Выбор первого текстового языка программирования — важное решение. Python, Java, C# — у каждого есть свои достоинства. Однако для детей, которые делают первые шаги в программировании, у JavaScript есть свой, уникальный набор преимуществ.

Низкий порог входа и мгновенная обратная связь

Главный враг интереса к программированию на старте — долгая и сложная настройка среды разработки. Этой проблемы не существует с JavaScript. Детям нужен лишь любой современный браузер (Chrome, Firefox, Edge) и простейший текстовый редактор, даже встроенный «Блокнот».

Любой код можно проверить мгновенно: сохранить файл с расширением .html или .js и открыть его в браузере. Более того, прямо в браузере есть встроенная Консоль разработчика (Developer Tools). Это интерактивная среда, где можно писать и выполнять команды на JavaScript построчно и сразу видеть результат или ошибки. Такая немедленная визуальная отдача превращает обучение в серию быстрых экспериментов: «А что будет, если изменить эту цифру? А если добавить эту команду?».

Визуальность и креативность

В отличие от языков, где первые программы часто выводят в консоль лишь текст (например, Hello, World!) или результат вычисления, JavaScript изначально ориентирован на работу с визуальными элементами.

Уже через несколько уроков ребенок сможет написать программу, которая:

• изменит цвет или текст любой кнопки на сайте;
• создаст анимацию движения объекта по экрану;
• сделает интерактивную фотогалерею или слайдер.

Для более сложных творческих задач существует элемент HTML5 Canvas — «цифровой холст», на котором с помощью JavaScript можно рисовать графику, создавать 2D- и даже простые 3D-игры, визуализировать данные. С JavaScript дети получают зрелищный, осязаемый результат, что принципиально важно для удержания внимания и развития творческого мышления.

Универсальность и понимание полного цикла разработки приложений

JavaScript — это редкий пример языка, который доминирует на одной стороне («клиентской» или фронтенде; это то, что видят пользователи в окне браузера) и при этом полноценно работает на другой («серверной» или бэкенде; то, что «незаметно» происходит на сервере, где обрабатываются данные).

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

На бэкенде JavaScript тоже используют — благодаря платформе Node.js на нем можно писать серверную логику: работать с базами данных, формировать ответы на запросы, организовывать обмен данными в реальном времени.

Такая универсальность JavaScript позволяет ребенку, начав с простых скриптов для страницы, в перспективе разобраться с полным циклом создания веб-приложений — от интерфейса до сервера. А это открывает путь к самым востребованным профессиям в IT.

Какие концепции программирования осваивает ребенок с JavaScript и почему они важны

Программирование на JavaScript для детей — это освоение фундаментальных понятий, которые лежат в основе большинства современных программ.

Базовые понятия программирования

Первым делом ребенок знакомится с элементарными строительными блоками любого языка программирования:

• Переменные (в JavaScript они обозначаются как let или const) — это коробки, или контейнеры, для хранения данных: чисел, текста, списков. Они работают по принципу математической переменной. Например, let score = 0 создает «ящик» с надписью score, где хранится число 0. Это основа для любых изменяющихся данных, например, счетчика очков в игре или имени пользователя.
• Типы данных — компьютер различает числа, текст (строки), логические значения true/false (правда/ложь). Понимание типов помогает избежать ошибок: нельзя сложить число и слово, но можно соединить два слова.
• Операторы — это знаки действий. Они бывают арифметические (+, -, *, /) — здесь прямая связь с математикой и работают они так же, как в математике. Есть операторы сравнения (>, ===, <=) и логические (&& — «и», || — «или») — они отвечают за логику и необходимы для принятия решений в программе.

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

Интерактивность и программирование событий

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

• События (events) — это любое действие пользователя: клик мышью (onclick), нажатие клавиши (onkeypress), движение курсора.
• Ребенок учится создавать функции — блоки кода, которые выполняются по требованию, и «привязывать» их к событиям.

Например:

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

Работа с DOM (Document Object Model) и управление страницей

DOM — это программное представление структуры HTML-страницы в виде дерева объектов. Детям это можно объяснить так: браузер превращает всю страницу (заголовки, абзацы, кнопки, картинки) в особую «карту», которой может управлять JavaScript:

• Код может найти любой элемент на этой карте, например, заголовок — он обозначается как <h1>.
• Код может изменить этот элемент: поменять текст, цвет, размер, скрыть или переместить его.

Первая игровая логика: Canvas и анимация

Для создания графики и игр используется элемент HTML5 Canvas («холст»). Это область на странице, где каждым пикселем можно управлять с помощью JavaScript.

• Дети учатся рисовать геометрические фигуры, выводить изображения.
• Осваивают принципы анимации: чтобы объект на экране двигался, нужно циклически (30-60 раз в секунду) стирать его со старой позиции и рисовать на новой. Так изучаются циклы и таймеры.
• Обработка столкновений — следующая ступень. Это уже прикладная геометрия: программа постоянно проверяет, пересеклись ли координаты одного объекта с координатами другого, и реагирует (например, при столкновении мяча с платформой он меняет направление).

Этот этап объединяет все предыдущие знания: переменные хранят координаты, события управляют героем, функции передают правила отрисовки, а работа с Canvas — это управление особым элементом DOM.

Полезные ресурсы и курсы по JavaScript для детей

Здесь мы собрали все, что поможет детям освоить программирование на JavaScript: уроки, курсы, полезные сайты с тренажерами и даже книги!

Видеоуроки и онлайн-курсы по JavaScript для детей

Мы рекомендуем начать с видеоуроков на наших каналах на YouTube и RuTube или образовательной платформе Stepik.

Также приглашаем на онлайн-курс «Создание сайтов на языках HTML, CSS и JavaScript для детей» у нас, в Школе программирования «Пиксель». Здесь дети работают над собственными интерактивными сайтами, которые станут частью их взрослого портфолио.

Первый урок курса можно пройти бесплатно. Это полноценный урок с преподавателем, на котором ребенок:

• познакомится с основами программирования на JavaScript,
• напишет свой первый код, увидит его результат,
• сможет задать любые вопросы преподавателю,
• на практике проверит, насколько ему интересен этот язык.

Узнать подробнее о курсе можно здесь.

А записаться на бесплатный первый урок здесь.

Еще один полезный ресурс — бесплатный курс «JavaScript для начинающих».

Интерактивные тренажеры по JavaScript для детей

Самые известные — интерактивные платформы Codecademy и freeCodeCamp. Они на английском, но английский — это язык программистов всего мира, так что попотеть и разобраться в нем стоит.

Как они работают? Ребенок видит теоретическое объяснение, затем окно редактора с частично написанным кодом. Его задача — дописать недостающую строку или исправить ошибку. А система мгновенно проверит его решение.

Браузерные игры для детей по программированию и JavaScript

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

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

CodeWars. Ребенок будет тренировать навыки JavaScript, решая задачи на логику разной сложности и сможет сравнить свои решения с вариантами других участников.

JSDares. Здесь дети получают от сообщества небольшие практические задания, например, создать мини-игру или эффект на JavaScript, и учатся применять знания на конкретных примерах.

WarriorJS. В этой игре-головоломке ребенок напишет искусственный интеллект для своего героя, чтобы тот сражался с врагами и преодолевал препятствия, поднимаясь по уровням башни. Каждый новый этаж требует применения более сложных приемов программирования.

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

Untrusted. Ребенок выступит в роли хакера, используя консоль браузера и JavaScript, чтобы изменять саму игру и таким образом проходить сложные лабиринты.

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

JSRobot. Чтобы пройти уровень, ребенку нужно написать код, который будет управлять роботом: заставлять его двигаться, собирать предметы или избегать опасностей.

Elevator Saga. Задача ребенка — запрограммировать логику работы лифтов в здании так, чтобы они успевали обслуживать всех пассажиров. Сложность постепенно увеличивается.

Учебники по JavaScript для детей

«JavaScript для детей» Ника Моргана. Популярное пособие на русском языке, которое обучает языку через создание простых игр (змейка, виселица). Подходит для детей от 10 лет.

Learn.javascript.ru — главный русскоязычный онлайн-учебник. Он может быть сложен для совсем маленьких, но идеален для подростков 14+ как справочный ресурс.

JavaScript открывает детям двери в мир «взрослого» программирования. Чтобы этот старт был уверенным и осознанным, следуйте простому алгоритму:

1. Посмотрите с ребенком бесплатные уроки и предложите повторить их или проверить знания в браузерных играх.
2. Пройдите бесплатный пробный урок. Это поможет вам объективно оценить интерес ребенка к программированию и JavaScript, его готовность заниматься, познакомиться с форматом обучения.
3. Если эксперименты показывают устойчивый интерес — значит нужен более системный подход. Структурированный курс с четкой программой, поддержкой преподавателя и работой над собственными проектами — то, что нужно ребенку на этом этапе.

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFJq93Sp

Пользователь может транслировать презентацию через "AI Кликер", а сервис будет записывать и транскрибировать речь спикера и аудитории. Спикер может переключать слайды простыми голосовыми командами или ключевыми словами, привязанными к конкретным слайдам.

Интеграция LLM позволяет реализовать интеллектуальные функции - переключение слайдов по описанию, контексту, генерация нового контента в реальном времени. Целевая аудитория — учителя, преподаватели и спикеры, на постоянной основе работащие с презентациями.

Архитектура решения

Наша команда использует JavaScript с React на фронтенде и Python c FastAPI на бэкенде. Мы используем PosgtreSQL как базу данных и S3 как объектное хранилище для хранения презентаций. Мы строим микросервисную архитектуру в нашем приложении.

Первый сервис - REST API для авторизации, управления личным кабинетом и контентом пользователя. Развернут на отдельном дешевом сервере за прокси NGINX, запросы шифруются HTTP

Второй сервис - API трансляции презентации. Двустороннее взаимодействие браузера и этого сервиса (передача звука и отдача команд по переключению слайдов) идет по протоколу WebSocket Secure. Отдельный сервис для трансляции позволяет нам динамически управлять дорогими серверами с GPU, уничтожать их, поднимать, экспериментировать с конфигурациями, не переживая о сохранности основного приложения. Модель OpenAI Whisper используется для транскрибации речи и GigaChat от Сбера как LLM для анализа контекста выступления и генерации команд и контента.

Работа Whisper

В AI-кликере распознавание речи - фундамент всей системы. Пока человек говорит, система должна получить текст, проверить команды, сопоставить с ключевыми словами, передать в LLM. Для этого обычного Whisper недостаточно — он отлично работает с файлами, но плохо подходит для живого потока.

Поэтому в проекте используется связка Whisper + WhisperLiveKit — библиотека, которая позволяет кормить модель аудио чанками в реальном времени, а не загружать готовые записи.

Байпас: ручное управление голосом

Одна из ключевых фич — байпас-режим. Это механизм, который позволяет управлять презентацией жёсткими голосовыми командами, в обход всей нейросетевой логики.

Когда Whisper отдаёт текст, он сначала проверяется не через LLM, а через механизм сопоставления фраз:

Дальше всё работает просто:

• если пользователь сказал фразу, похожую на “кликер вперёд” → слайд листается вперёд;
• если “кликер назад” → слайд листается назад.

Данная реализация позволяет пользователю в любой момент перебить автоматику и принудительно перелистнуть слайд. Это критично для надёжности: если LLM вдруг “поплыла”, у спикера всегда есть жёсткий голосовой руль.

Ключевые слова: автоматический переход на нужный слайд

Вторая важная часть — режим ключевых слов. Это уже не просто “вперёд/назад”, а сопоставление речи с конкретными слайдами.

Логика такая:

1. Для презентации загружается набор ключевых фраз, который группируется по номеру слайда.
2. Когда приходит новый фрагмент речи — он сравнивается с ключевыми словами и в случае успеха отправляет команду на переключение:

То есть фактически система работает как голосовой навигатор по презентации:

• сказал фразу, связанную со слайдом 5 → система предлагает перейти на 5;
• сказал фразу из блока 10 → прыжок сразу туда

При этом переход отправляется в очередь и дополнительно проверяется по порогу уверенности:

Слайд переключается только если вероятность достаточная. Это защищает от случайных совпадений и шумов.

Работа с LLM (Гигачат) - промпты, контексты, очереди

Если Whisper в AI-кликере отвечает за то, чтобы услышать, то GigaChat отвечает за то, чтобы понять, о чём сейчас говорит спикер и какой слайд этому соответствует. Вся работа с LLM построена асинхронно: распознанная речь не блокирует систему, а складывается в очередь и обрабатывается в фоне. Каждый фрагмент речи:

• попадает в очередь,
• добавляется в историю пользователя,
• отправляется в GigaChat,
• а результат в виде вероятностей по слайдам уходит дальше в очередь переключения.

Такой подход позволяет не тормозить распознавание речи, не зависеть от времени ответа нейросети, обрабатывать несколько фрагментов параллельно.

В чём возникла основная проблема?

Текущая концепция работы LLM строится на предугадывании номера слайда по смыслу речи. И именно здесь в реальных условиях всплыла главная боль проекта. На живых выступлениях выяснилось, что GigaChat может путаться между похожими слайдами и менять своё решение от фразы к фразе. В итоге презентация иногда начинала хаотично перелистываться, даже если спикер говорил последовательно и спокойно. Для пользователя это выглядит как будто “нейросеть сошла с ума и живёт своей жизнью”.

Пока проблема не решена полностью, в системе есть страховочный механизм — временное отключение GigaChat при ручном управлении. Если пользователь даёт жёсткую голосовую команду (байпас), то нейросеть временно игнорируется, а управление полностью возвращается человеку. Через несколько секунд автоматика включается обратно, что позволяет не ломать выступление даже в моменты, когда LLM начинает вести себя нестабильно

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

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

Итоги

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

В этой статье мы рассмотрим 5 самых востребованных языков программирования, подходящих для детей, — от визуальных, понятных даже младшим школьникам, до мощных «взрослых», на которых построены современные технологии. Вы узнаете не только что это за языки, но и почему они стали популярными, какие задачи решают и, самое главное, как понять, какой из них идеально подойдет для увлечений и склада ума именно вашего ребенка.

Визуальный язык программирования Scratch

Представьте, что перед ребенком — не пустой экран редактора кода, а красочная палитра команд: «двигаться», «повернуть», «повторить», «если-то». Это и есть Scratch — визуальная среда, созданная в 2003 году командой под руководством Митчела Резника в легендарном Массачусетском технологическом институте. Они задались вопросом: как сделать программирование таким же интуитивным и увлекательным, как сборка конструктора Lego? Ответом и стал Scratch, где код «собирается» из цветных блоков.

Почему Scratch идеален для младших школьников:

• С ним нет страха перед ошибками. Главный барьер для новичка — синтаксис. Одна пропущенная скобка или точка с запятой ломает всю программу. В Scratch такой проблемы просто не существует. Блоки подходят друг к другу, только если это логически верно, и дети с первых минут думают не о правилах написания, а о логике действий.
• Мгновенная обратная связь и визуальный результат. Нажал «запустить» — и спрайт (персонаж) побежал по экрану, заиграла музыка, сменился фон. Эта наглядность — хороший мотиватор. Детям сложно воспринимать абстракции, а здесь они создают осязаемую интерактивную историю, игру или мультфильм.
• Развитие вычислительного мышления. Scratch учит сути программирования: разбивать сложную задачу на простые шаги, видеть закономерности, использовать условия и циклы. Это и есть основа алгоритмического мышления, причем освоенная в игровой форме.

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

Где заниматься Scratch онлайн:

• Курсы в школе программирования «Пиксель». Их преимущество — есть целых 3 курса по Scratch, рассчитанных на разный возраст учеников:
  Программирование в Scratch Junior и Kodu Game Lab для детей 5-7 лет,
  Программирование в Scratch для детей 6-9 лет,
  Создание игр и анимации. Визуальная среда Scratch для детей 9-12 лет.

• Scratch для детей и подростков в онлайн-школе Skysmart. Это универсальный курс для школьников всех возрастов.

• Scratch для детей — визуальное программирование и создание игр с нуля в UnionCode.

Лучший первый текстовый язык программирования для детей — Python

Если Scratch похож на конструктор, то Python — это первый настоящий текстовый язык, который рекомендуют детям. Он удивительно эргономичен, точен, и при этом с ним можно создать буквально что угодно. А его философия зашифрована в принципе «Дзен Пайтона» — так называют сборник из 20 правил, которыми руководствуются разработчики при написании кода: простое лучше, чем сложное; читаемое лучше, чем непонятное; явное лучше, чем скрытое и т.д.

Этот язык программирования был создан в конце 1989 года голландским программистом Гвидо ван Россумом. Он начал работать над ним в качестве хобби, в рождественские каникулы, мечтая устранить недостатки другого языка — ABC. Название он позаимствовал не у змеи, а от британского комедийного шоу «Летающий цирк Монти Пайтона». Гвидо хотел, чтобы язык ассоциировался с чем-то забавным и несерьезным. Но жизнь тоже решила пошутить, и сегодня Python — один из самых серьезных и востребованных языков в мире.

Почему Python — лучший первый текстовый язык для детей:

• Код на нем часто читается как короткие инструкции на английском. Например, для вывода текста нужна простая команда print("Привет, мир!").
• Мощный, простой, универсальный, подходящий для всего — от игры до нейросети. Его сила в его гибкости и огромной коллекции библиотек — готовых модулей с кодом. С ними ребенок даже на старте обучения сможет написать текстовый квест или графическую игру, создать полезного телеграм-бота, нарисовать сложные фрактальные узоры или обработать изображения, проанализировать реальные данные — например, статистику своих игровых результатов.
• От простой идеи до рабочего прототипа путь очень короткий, что постоянно подпитывает интерес.
• Python прививает культуру «чистого кода» с самого начала. Из-за того, что для обозначения блоков кода используются отступы (пробелы), а не скобки, дети интуитивно учатся писать аккуратный, структурированный и легко читаемый код. А это хорошая профессиональная привычка.

Python — это редкий случай, когда детское хобби может стать прямым билетом в самые передовые и высокооплачиваемые IT-сферы:

• Искусственный интеллект и Data Science — библиотеки TensorFlow, PyTorch и scikit-learn сделали Python главным языком машинного обучения.
• Веб-разработка — фреймворки Django и Flask лежат в основе миллионов сайтов, среди которых Pinterest, Spotify, YouTube, Netflix.
• Автоматизация и аналитика — его используют системные администраторы, аналитики и ученые для обработки данных и автоматизации рутины.

Лучшие онлайн-курсы для изучения Python:

• Курсы в школе программирования «Пиксель» для детей разного возраста:
  Игровая вселенная Minecraft. Программирование на языке Python для детей 9-13 лет,
  Основы программирования на Python для детей 10-14 лет,
  Веб-разработка Python Django для старших школьников 14-17 лет.

• Курс Программирование на Пайтон для детей от 10 лет в школе ProgKids.

• Программирование на Python для детей 11-14 лет в онлайн-школе GeekSchool.

JavaScript — язык для веба, оживляющий интернет-страницы

Представьте себе веб-страницу как театральную сцену. HTML с текстом, картинками, встроенными видео — это декорации и актеры, CSS — их костюмы и грим, а JavaScript — это режиссер и сценарист, который говорит актерам, когда им выходить, что делать и как реагировать на действия зрителей. Без него Интернет был бы похож на красивую, но статичную картинную галерею.

Интересный факт: JavaScript был создан за 10 дней. Это было в 1995 году, его создатель Брендан Эйх работал над браузером Netscape Navigator. Компании нужен был «язык скриптов для дизайнеров», который можно было бы встраивать прямо в HTML-страницы. Изначально язык назывался Mocha, затем LiveScript, а свое окончательное имя — JavaScript — получил как маркетинговый ход, чтобы «прокатиться» на волне популярности языка Java. Но несмотря на созвучность, это два абсолютно разных языка.

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

JavaScript — это ключ к созданию динамического контента, и не только в вебе, но и для любой анимации и игр. С его помощью можно:

• сделать сайт интерактивным (слайдеры, всплывающие формы, анимации);
• написать полноценную браузерную игру на HTML5 Canvas;
• создать веб-приложение, работающее как настольное (например, простой фоторедактор или клиент для заметок).

Начать можно с простых скриптов прямо в консоли браузера. По мере роста появляется доступ к огромной экосистеме: фреймворки (React, Vue), серверная платформа (Node.js), мобильная разработка. Это показывает ребенку, как с одним языком можно масштабироваться от написания небольших косвенных деталей до глобального проекта.

JavaScript — это безальтернативный стандарт для фронтенд-разработки (того, что видит пользователь). Но его применяют гораздо шире. С появлением Node.js JavaScript вышел за пределы браузера. Теперь на нем можно писать и серверную часть приложений — то, что происходит «за кадром». Это делает возможной профессию фуллстек-разработчика, владеющего одним языком для всех задач.

JS применяют в мобильной и десктопной разработке — такие фреймворки, как React Native, позволяют создавать мобильные приложения для iOS и Android.

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

Лучшие онлайн-курсы в этом направлении:

• Веб-разработка и создание сайтов для детей в онлайн-школе GeekSchool.

• Создание сайтов для детей (HTML+CSS+JS) в ProgKids.

• Образовательная траектория Fullstack-разработчик для детей от 14 до 17 лет в школе «Пиксель».

Lua и C# — языки для геймдева

Эти два языка идеально подходят для подростков, чье увлечение играми переросло в желание понять их внутреннюю кухню и взять управление в свои руки.

Lua — маленький гигант игровых миров Roblox

Lua (в переводе с португальского — «луна») был создан в 1993 году в Католическом университете Рио-де-Жанейро группой инженеров во главе с Роберто Иерусалимши, Луисом Энрике де Фигейредо и Валдемаром Селесом. Их цель была скромной: создать легкий, встраиваемый язык для настройки ПО в нефтяных компаниях. Ирония судьбы в том, что слава пришла к Lua из абсолютно другой сферы — из индустрии видеоигр.

Почему Lua подходит для старта в геймдеве:

• Популярность Lua среди детей на пике благодаря Roblox. Зная основы Lua, можно зайти в Roblox Studio и буквально за час запрограммировать дверь, которая открывается, или создать простого NPC, который будет повторять нужные действия. Так мир, в котором ребенок еще недавно только играл, становится полем для экспериментов и местом обученния.
• Синтаксис Lua намеренно сделан простым и последовательным. В нем мало непонятных правил, он учит основам программирования (переменные, функции, циклы) в чистом, не сбивающем с толку виде.
• Принцип «встраиваемости». Изучая Lua для Roblox, дети на практике понимают важнейшую концепцию: часто программист не пишет программу с нуля, а пишет небольшие скрипты — инструкции для поведения объектов внутри готовой, глобальной системы (движка).

Lua — это стандарт в игровой индустрии для написания игровой логики и скриптов. Его используют в World of Warcraft (для создания аддонов), Civilization, Angry Birds и во многих других играх и приложениях (например, в Adobe Lightroom).

Где его изучать:

• Онлайн-курс Lua для детей в школе EasyCode.

• Программирование на Lua для детей в Keencentre Online.

• Программирование и дизайн игр в Roblox для детей 10-12 лет в GeekSchool.

C# — для профессиональных игр и Unity

C# — язык, созданный Microsoft для конкуренции с Java. C# (произносится как «си шарп») был представлен корпорацией Microsoft в 2000 году под руководством Андерса Хейлсберга, создателя невероятно популярных в конце 20-го века Turbo Pascal и Delphi. Его цель была амбициозной — современный, объектно-ориентированный язык для платформы .NET, который сочетал бы мощь C++ с простотой Java.

Почему C# подойдет подросткам:

• Это ключ к профессиональному движку Unity. Unity — один из самых популярных в мире движков для создания 2D- и 3D-игр, на котором сделаны тысячи коммерческих проектов (от Cuphead до Ori and the Blind Forest). C# — основной язык сценариев Unity. Изучая C#, подросток фактически вливается в индустрию геймдева.
• Системность и строгость. В отличие от Lua, C# — это строгий, типизированный язык. Его изучение — это уже погружение во «взрослое» программирование с классами, объектами, наследованием. Это дисциплинирует мышление и дает понимание, как строятся большие и сложные программы.
• В Unity на C# можно создать не просто демо-версию, а полноценную игру со сложной графикой, физикой, звуком и AI, которую потом можно запустить на ПК, консолях или мобильных устройствах.

Владение C# и Unity открывает двери в профессию геймдев-программиста. Но сфера применения C# шире: это также основной язык для разработки корпоративных приложений, сервисов и программ под платформу Microsoft.

Лучшие онлайн-курсы по C#:

• Создание игр в Unity и программирование на языке C# для детей 10-14 лет в «Пикселе».

• Программирование на C# с 10 лет в «Айтигенио».

• Программирование на C#. Удивительный мир 2D-игр для детей в «КиберШколе».

Lua и C# — две ступеньки на пути в игровую разработку. Lua — быстрый и мотивирующий старт, где результат виден мгновенно, а порог входа минимален. C# — это осознанный выбор для более глубокого изучения, переход на профессиональные рельсы и создание сложных проектов.

Чек-лист для родителей: как выбрать первый язык программирования

Чтобы не гадать, а принять осознанное решение, задайте себе простые вопросы:

Какой возраст ребенка и готов ли он к абстракции?

• 6-10 лет → В приоритете наглядность, игра, мгновенный результат и полное отсутствие страха перед ошибками. Ответ здесь, скорее всего, один — Scratch или аналогичные визуальные среды.
• 10-12 лет → Появляется готовность работать с текстом, если он понятный. Желание создавать что-то «настоящее». Идеальный кандидат — Python.
• 12+ лет → Дети в этом возрасте уже имеют четкие увлечения (гейминг, дизайн, технологии), и их мотивирует возможностью влиять на любимую цифровую среду. Выбор расширяется до JavaScript, Lua, C#.

Подумайте о складе ума ребенка и его интересах:

• Обожает игры → Смотрите в сторону Lua (Roblox) или C# (Unity).
• Нравится рисовать, делать видео, творить → Python (для генерации графики, работы с медиа) и JavaScript (для создания интерактивного искусства, веб-дизайна).
• Любит головоломки, логику, интересно, как именно все устроено → Python (для решения задач) и JavaScript (чтобы «разобрать» и собрать поведение сайтов).
• Хочет создать свой сайт/приложение? → JavaScript (фронтенд) и Python (бэкенд).

Есть ли уже какой-то опыт?

• Нет, это первый шаг → Начинайте с максимально доброжелательных и наглядных Scratch и Python.
• Да, было знакомство со Scratch или блочным программированием → Самый логичный переход — к Python. Дети с опытом в визуальных средах программирования уже понимают логику, а теперь научатся выражать ее в текстовом виде.
• Да, немного пробовал писать код→ Можно смело смотреть в сторону специализации по интересам: JavaScript для веба, C# для игр.

Итак, мы разобрали, какие языки программирования подходят детям — от визуального Scratch до «взрослого» C# — и как выбрать подходящий. Но главный вывод прост: не существует единственно правильного «детского» языка. Есть правильные первые шаги для каждого конкретного ребенка. Scratch, Python, JavaScript, Lua, C# — каждый из них открывает свою уникальную дверь в огромный мир IT: через творчество, через логику, через любимую игру или через создание полезных приложений.

И еще: не выбирайте язык за ребенка — позвольте попробовать свои силы в разных языках и выбрать самому. Многие школы программирования предлагают бесплатные пробные уроки — используйте эту возможность.

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

Но теперь эта «шутка» стала наглядной — проект Stacktower превращает рисунок в настоящую визуализацию зависимостей.

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

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

Как работает Stacktower

Сайт предлагает две модели: «стабильную башню» и «неустойчивую башню», где уровни подстраиваются под выбранные библиотеки.

Пользователь может загрузить зависимости своих приложений — например, на Python или JavaScript — и увидеть, что будет, если убрать даже один элемент.

На странице приводится пример для Node.js:

приложение зависит от Express → Express зависит от body-parser → body-parser зависит от qs → и так далее

Stacktower иллюстрирует, что даже простое приложение тянет десятки модулей, часто неподконтрольных разработчику.

Есть и Python-вариант:

импорт Flask тянет Werkzeug, Jinja2, MarkupSafe, Click и еще несколько пакетов. А те, в свою очередь, имеют собственные зависимости.

Зачем это нужно

Автор подчеркивает: цель проекта — не критиковать экосистемы, а показать их реальное устройство.

Стек современных приложений неизбежно сложен и даже крошечный модуль может стать критически важным. Именно так в 2022 году случайное удаление библиотеки left-pad временно «сломало» огромный кусок JavaScript-мира.

Stacktower превращает эту абстрактную проблему в понятный визуальный эффект: убираешь одну зависимость — рушится вся конструкция.

Комьюнити уже подхватило идею

Проект быстро разошелся по Reddit, Hacker News и X: разработчики делятся скриншотами своих «башен», спорят о хрупкости экосистем и обсуждают, стоит ли пересматривать подход к зависимости.

Кто-то предлагает добавить поддержку Rust и Go, другие мечтают о корпоративной версии инструмента для визуального аудита безопасности.

Изучить проект подробнее можно на его странице на GitHub.

2025 год особенно интересен: требования растут, стек стремительно обновляется, а вокруг — десятки новых инструментов, которые одновременно и вдохновляют, и заставляют чувствовать себя не в своей тарелке. Так что давайте спокойно и по-человечески разберёмся, что сегодня действительно важно, а что можно смело откладывать.

Как изменилась профессия и что теперь требуют от фронтендера

Если лет пять назад от вас ждали уверенную верстку, JavaScript и один фреймворк, то сегодня к этому прибавились архитектура, серверные рендеринги, работа с AI-инструментами и понимание, как всё это уживается на проде. Современный фронтенд стал более инженерным: теперь вы не просто “собираете интерфейс”, а участвуете в создании части системы.

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

Стек, который в 2025 уже обязателен

Начнём с основы — технологий, без которых трудно представить работу фронтендера.

TypeScript окончательно стал стандартом. Это уже не “приятное дополнение”, а часть культуры. Большие команды без типизации работать не могут — слишком дорого обходятся ошибки и непредсказуемые зависимости.

JavaScript тоже не стоит на месте: ежегодно появляются полезные нововведения, которые упрощают работу с асинхронностью, структурами данных и синтаксисом. Те, кто следят за ECMAScript, всегда ощущают себя увереннее остальных: код становится чище, а решения — элегантнее.

Во фронтенде всё больше внимания уделяется браузерным API. WebGPU, новые возможности Storage, нативные анимации — всё это сильно снижает потребность в тяжёлых библиотеках и позволяет делать вещи, которые раньше были попросту невозможны. Чем лучше вы понимаете браузер, тем реже сталкиваетесь с ограничениями.

Фреймворки: что происходит, и куда всё движется

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

Параллельно растет популярность SvelteKit. Он проще, легче и зачастую приятнее в работе, особенно в небольших командах и стартапах, где важна скорость разработки. Vue 3 остается стабильным и очень комфортным выбором — его любят команды, которые ценят предсказуемость и мягкий порог входа.

Angular в 2025 году остаётся выбором крупных компаний и проектов, где важны строгая структура и предсказуемость. Благодаря встроенному DI, мощному CLI и единому стилю разработки он помогает быстрее масштабировать команды и поддерживать большие приложения.

Архитектура: что фронтендер обязан понимать в 2025

Современная разработка уже не обходится без SSR, SSG или ISR. Рендеринг стал частью оптимизации, а значит нужно понимать, почему одни страницы стоит отдавать с сервера, а другие — генерировать заранее.

Edge-функции — еще одно направление, которое стремительно набирает обороты. Когда код выполняется ближе к пользователю, интерфейс работает быстрее, а логика становится гибче. Если раньше подобные вещи интересовали только backend-разработчиков, то теперь это важный элемент фронтенд-экосистемы.

Микрофронтенды остаются актуальными для крупных команд. Они не всегда нужны, но если продукт растет, а структура усложняется, этот подход заметно снижает хаос.

Как AI меняет работу разработчика

AI перестал быть экспериментом — он стал полноценным участником рабочего процесса. Хорошие специалисты уже воспринимают его не как угрозу, а как инструмент.

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

Компании в 2025 году всё чаще спрашивают не “умеете ли вы пользоваться AI”, а “как именно он встроен в ваш рабочий процесс”.

Ключевые навыки, без которых сейчас не обойтись

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

Второе — доступность. A11y перестала быть “бонусом”. Это требование. Интерфейс должен быть удобен всем пользователям, независимо от их ограничений, и компании всё чаще контролируют этот аспект.

Третье — автоматизация. CI/CD, базовая работа с пайплайнами, понимание, как собирается и проверяется код — всё это экономит время и снижает число ошибок. Чем сильнее разработчик в автоматизации, тем надёжнее продукт.

Софт-скиллы, о которых всё чаще говорят

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

Еще одна ключевая компетенция — умение учиться. Обновления приходят настолько быстро, что способность адаптироваться становится не менее важной, чем знание фреймворков.

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

Заключение

2025 год стал переломным для фронтенда. Порог входа вырос, но вместе с этим вырос и потенциал — теперь разработчик может влиять на продукт намного сильнее. “Самое нужное для фронтендера в 2025” — это не столько конкретный стек, сколько способность мыслить шире: понимать архитектуру, разбираться в инструментах, не бояться AI и постоянно развиваться.

Если смотреть на профессию не как на бесконечный список требований, а как на путь, то изменения перестают пугать. Они открывают новые возможности — и именно это делает работу фронтенд-разработчика такой захватывающей.

Зачем вообще убирать ботов

Я из тех, кто не любит тратить время на фичи, пока не понятно, что они реально нужны пользователям. С open-source-проектами та же логика: не стоит всё усложнять, пока клиенты прямо не скажут, что им действительно нужно что-то посложнее (бывает, что такие клиенты способны помочь себе сами… по крайней мере, в теории).

Несколько месяцев назад один из пользователей моего проекта A/Bingo — библиотеки для A/B-тестов на Rails — попросил добавить возможность исключать ботов из подсчёта. Тогда все мои эксперименты были за формой регистрации, так что боты туда почти не попадали.

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

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

Тема всплывала ещё пару раз, но никто не был настолько мотивирован, чтобы оплатить мою работу. Пока недавно я не стал проводить серию сквозных A/B-тестов, где конверсией считалась покупка — и вот тут боты действительно оказались убийцами статистики.

Представим, что в среднем у меня около 2000 визитов в день и 5 покупок — для лета это нормальные цифры. Чтобы различить этот уровень конверсии и вариант, на 25 % лучше, потребуется примерно 56 000 визитов, то есть около месяца данных, чтобы достичь 95 %-го доверительного интервала. Отлично. Проблема в том, что A/Bingo фиксирует не 2000 визитов, а ближе к 8000 — потому что сайт постоянно штурмуют боты. В итоге измеренная конверсия падает с 0,25 % до 0,0625 %.

(Если кажется, что цифры низкие — не забывайте: это несезон, плюс я ранжируюсь по множеству длиннохвостых поисковых запросов, так что часть трафика в любом случае нецелевая.)

Влияет ли это вообще на статистику?

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

CR означает коэффициент конверсии (Conversion Rate), а n — размер выборки для двух альтернатив.

Если мы увеличим размеры выборок на некоторый постоянный коэффициент X, уравнение должно превратиться в:

Из числителя можно вынести 1/X и перенести его в знаменатель — простая арифметика из начальной школы.

Теперь, благодаря магии алгебры старших классов:

Если я здесь ошибся с математикой, команда математиков меня точно исключит:

Если внимательно посмотреть на это, то это не то же уравнение, с которого мы начали. Как оно изменилось? Обратная величина коэффициента конверсии (1 – cr) стала ближе к 1, чем была раньше. (Это можно проверить, взяв предел при X, стремящемся к бесконечности.) Приближение к 1 означает, что числители знаменателя становятся больше, что означает, что знаменатель в целом становится больше, что означает, что Z-оценка становится меньше, что потенциально может навредить расчёту, который мы делаем.

Итак, предполагая, что я правильно выполнил алгебру, интуитивный ответ, который я давал людям месяцами, оказался неверным: боты действительно портят тестирование статистической значимости, искусственно занижая z-оценки и тем самым превращая статистически значимые результаты в нулевые результаты на грани.

Так что же мы можем с этим сделать?

Наивный подход: проверять User-Agent

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

(Так как по ключевым словам мой сайт иногда попадает в серую тематику — вроде азартных игр, — я получаю массу лишнего внимания от скрейперов и парсеров.)

Проверка User-Agent убирала максимум половину трафика от ботов. Остальные продолжали участвовать в A/B-тестах, портя конверсии и статистику.

Более надёжный способ: заставить бота подумать

Можно было бы использовать CAPTCHA — но заставлять всех пользователей доказывать, что они люди, только ради чистоты A/B-тестов, мягко говоря, глупо.

Нужен полностью автоматический способ отличить человека от скрипта — без участия пользователя.

Решение, к счастью, уже есть: выполнение произвольного JavaScript-кода.

Пока Googlebot и ещё пара продвинутых ботов умеют исполнять JS, для большинства остальных это слишком дорого — и по ресурсам, и по сложности реализации. Написать скрипт на wget или через любую HTTP-библиотеку куда проще, чем имитировать полноценный браузер с движком JS.

(Да, Googlebot действительно умеет исполнять JavaScript. SEO-специалисты технического толка это хорошо знают: бот может частично выполнять код страницы, а иногда и полностью — как человек. Проверить это легко: поставьте в коде экспериментальный запрос, и Googlebot вскоре появится в логах по этому URL.)

Чтобы точно отличать людей от машин (и при этом не мешать Googlebot, который честно указывает свой User-Agent), нужно заставить браузер выполнить три простых задачи:

1. Сложить два случайных числа. (Для браузера с JS это тривиально.)
2. Сделать AJAX-запрос через Prototype или jQuery. (Подгрузить и выполнить эти библиотеки без реального движка JS почти невозможно.)
3. Выполнить POST-запрос. (Googlebot на POST обычно не ходит. Он делает много GET-запросов и даже пытается угадывать параметры, чтобы обойти больше страниц — но POST для него запретная зона.)

Пример на Prototype

И в jQuery

На сервере мы принимаем параметры a, b и c и проверяем, что они образуют корректную тройку. Если всё сходится — считаем, что это человек. Если нет — продолжаем считать клиента ботом.

Можно было бы усложнить задачу, например, попросить вычислить MD5 от случайного значения, сохранённого в сессии, чтобы отсеивать ботов, которые пытаются просто повторить старый ответ. Но мне это не нужно: цель не в защите от злонамеренных атак, а в фильтрации большинства «безобидных» ботов, которые лишь засоряют статистику.

Никто не получает выгоды, ломая мои A/B-тесты, так что я не жду целенаправленных атак. Это не защита — просто средство наведения порядка.

Да, я исхожу из того, что пользователи умеют выполнять JavaScript. (Мой сайт без JS всё равно не работает.)

Так что если кто-то вроде Ричарда Столлмана с включённым NoScript не сможет участвовать в моих тестах — что ж, я переживу.

Как всё связать вместе

Теперь мы умеем отличать тех, кто действительно исполняет JavaScript, от тех, кто нет.

Осталась одна мелочь: браузер сообщает о своей человечности уже после того, как пользователь начал участвовать в A/B-тесте.

Это абсолютно нормальная ситуация. Например, человек заходит на первую страницу, где где-то внутри встроен тест. Он выполняет JS-код, который посылает на сервер доказательство, что он человек. Но делает это уже после того, как A/Bingo зарегистрировал его участие в тесте.

Решение оказалось простым.

A/Bingo и так отслеживает, в каких экспериментах пользователь уже участвовал, чтобы не считать его повторно. В «антибот-режиме» это поведение чуть меняется:

• система продолжает записывать участие и конверсии,
• но не добавляет их в общую статистику, пока пользователь не подтвердил, что он человек.

Когда подтверждение приходит (браузер выполнил JS и прошёл проверку), система просматривает все предыдущие тесты, где пользователь уже участвовал, и задним числом добавляет его участие в подсчёты.

Если кому-то интересно посмотреть, как именно это реализовано, код доступен для изучения — всё лежит на официальной странице проекта.

А если не хочется разбираться в деталях, а просто нужно быстро сделать свои A/B-тесты ботоустойчивыми, — посмотрите последнюю запись в FAQ. Там объясняется, как включить этот режим в один клик.

Другие применения

Этот приём с проверкой через JavaScript можно использовать не только в A/B-тестах.

У него есть и другие, вполне практичные применения.

1. Невидимая CAPTCHA для комментариев

С небольшой доработкой это превращается в CAPTCHA без взаимодействия с пользователем — отличное решение для блогов, форумов и любых форм обратной связи.

Принцип такой:

• все пользователи (и люди, и боты) сразу видят свой комментарий после отправки,
• но сайт публикует его только после того, как получит подтверждение JavaScript-выполнения.

Никаких галочек Я НЕ РОБОТ — просто задержка публикации, пока браузер не выполнит нужный код.

Можно сделать проверку чуть сложнее и добавить состояние на сервере, чтобы она была уникальной для каждого запроса.

Минус очевиден: ваш сайт, скорее всего, навсегда останется без комментариев от Ричарда Столлмана и других любителей NoScript.

Но, согласитесь, это не самая высокая цена за чистоту данных.

2. Автоматическое дискриминирование пользователей под нагрузкой

Ещё одна идея — всегда различать, кто человек, а кто нет. Когда сервер оказывается на грани по ресурсам, можно временно отключать тяжёлые функции для тех, кто ещё не доказал свою человечность.

Так вы избавитесь от резких просадок производительности из-за всплесков ботов и сможете спокойно выдерживать пики нагрузки.

А если ситуация критическая — можно вообще заблокировать ботов на время. Обычные пользователи этого даже не заметят.

3. Защита от разрушительных действий

И наконец, проверку можно использовать, чтобы предотвратить опасные или разрушительные операции.

Хотя, по-хорошему, такие действия и так должны быть защищены — спрятаны за POST-запросом и аутентификацией. Но дополнительная проверка на человечность нужна, особенно если ошибка может что-то удалить или повредить данные.

От редакции Tproger

Если вам понравился этот перевод — обсудите материал в комментариях.

Мы стараемся находить и адаптировать для вас лучшие тексты о разработке, данных и инженерном мышлении. Поделитесь своими мыслями: сталкивались ли вы с ботами, которые ломают аналитику, и как вы с этим справлялись?

Есть веская причина, по которой многие разработчики задумываются, прежде чем использовать в JavaScript методы .sort(), .reverse() или .splice(): эти методы изменяют исходный массив. Такой побочный эффект может привести к скрытым, трудноуловимым ошибкам — особенно в приложениях с общим или реактивным состоянием.

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

• toSorted()
• toReversed()
• toSpliced()

Эти методы возвращают копии массивов, вместо того чтобы изменять оригинал. Это небольшое, но важное обновление синтаксиса — особенно для разработчиков на React, где неизменяемость данных (immutability) — ключ к правильному управлению состоянием.

Проблема методов, изменяющих массив «на месте»

В JavaScript традиционные методы, такие как .sort(), .reverse() и .splice(), модифицируют сам массив, на котором были вызваны:

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

Сравнение старых и новых методов

• Для сортировки вместо arr.sort(), который изменяет исходный массив, теперь можно использовать arr.toSorted(), возвращающий новый.
• Для обратного порядка вместо arr.reverse() следует применять arr.toReversed(), чтобы сохранить оригинал.
• Для удаления или вставки элементов вместо arr.splice() можно использовать arr.toSpliced(), который создаёт копию массива с изменениями, не трогая исходный.

Эти новые методы работают так же, как и их «изменяющие» аналоги, но вместо модификации исходного массива возвращают новый.

⚠️ Важно: это поверхностные копии, поэтому если массив содержит объекты, сами объекты останутся теми же ссылками, а не новыми экземплярами.

Решение: безопасные, не изменяющие оригинал методы

В стандарте ES2023 появились новые версии привычных методов массивов, которые не изменяют исходный массив:

toSorted() — создаёт отсортированную копию массива, не затрагивая оригинал.

Вы также можете передать собственную функцию сравнения — точно так же, как в методе .sort():

toReversed() — возвращает обратную копию массива, не изменяя исходный порядок элементов в оригинале.

Отлично подходит для случаев, когда нужно вывести список в обратном порядке, не изменяя исходный массив.

toSpliced() — это более безопасная альтернатива методу .splice(). Она возвращает новый массив с добавленными или удалёнными элементами, не затрагивая оригинал.

Напоминание: метод .splice() возвращает удалённые элементы, а .toSpliced() — обновлённый массив.

Почему это важно в React

В React неизменяемость данных — ключевой принцип, который обеспечивает обновление компонентов и предсказуемость состояния.

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

Практический пример: сортировка задач в React

Вот как можно использовать toSorted() или toReversed() в компоненте, чтобы безопасно отображать динамические списки, не изменяя исходные данные:

Такой подход избегает изменения массива tasks, что особенно важно, если он передан через props или вычисляется из state — в противном случае могут возникнуть ошибки. Кроме того, использование операторов опциональной цепочки (?.) и объединения с null (??) помогает предотвратить сбои, если tasks окажется undefined.

И это ещё не всё! Оба этих оператора — опциональная цепочка и nullish coalescing — улучшения синтаксиса, делающие код более надёжным и устойчивым к ошибкам во время выполнения, приближая его к современному стандарту JavaScript.

Маленькое изменение в синтаксисе — большое улучшение

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

Поддержка браузерами

Методы toSorted(), toReversed() и toSpliced() поддерживаются во всех современных средах:

✅ Chrome / Edge — с версии 110+

✅ Safari — с версии 16+

✅ Firefox — с версии 115+

✅ Node.js — с версии 20+

Для старых окружений можно использовать полифил, например, из библиотеки core-js.

Основные выводы

Метод .toSorted() возвращает отсортированную копию массива, не изменяя оригинал. Метод .toReversed() создаёт новый массив в обратном порядке, также без мутаций исходного. Метод .toSpliced() возвращает изменённую копию массива — с добавленными или удалёнными элементами, но оригинальный массив остаётся нетронутым.

ES2023 принёс не только заметные обновления вроде опциональной цепочки и top-level await, но и такие, казалось бы, мелкие улучшения, которые делают код чище, понятнее и безопаснее. Попробуйте использовать новые методы в своих проектах — и вы больше не будете смотреть на .sort() с тем же доверием.

Этого можно избежать, если подойти к организации импортов системно.

В статье мы разложим по полочкам:

• Основные типы импортов и их влияние на сборку;
• Известные способы импортировать модули;
• Подходы по организации импортов;
• Частые проблемы с импортами и инструменты их решения.

Статья будет полезна как новичкам, желающим разобраться в основах, так и сеньорам, которые хотят систематизировать свои знания и узнать о тонкостях работы импортов.

Как импорты влияют на производительность вашего приложения?

Понимание работы импортов способствует созданию лёгкого и производительного web-приложения, в то время как неправильное использование — приводит к попаданию в сборку неиспользуемого кода, что напрямую влияет на время загрузки приложения.

В чем разница CommonJS и ES Modules?

CommonJS

CommonJS (далее CJS) — система импортов, которая долгое время была стандартом в Node.js.

Синтаксис

Особенности

Загрузка модулей в CJS происходит синхронно. Это хорошо подходит для сервера, где файловая система работает быстро, но в браузере такой подход является узким местом, особенно без использования сборщиков.

По той же причине CJS не подходит для SSR, поскольку блокирует рендеринг и замедляет отдачу конечной страницы.

Интересно: Хотя современные React-приложения используют ES-модули, многие библиотеки из экосистемы NPM до сих пор пишутся или транспилируются в CommonJS. Понимание различий между этими системами может вам понадобиться для отладки получения более эффективного tree-shaking

Гибкость

require() — это обычная функция, которая может быть вызвана в любом месте кода, что само по себе довольно удобно:

CJS-модуль выполняется один раз — при первом require(). Затем результат выполнения кешируется, и все последующие вызовы будут возвращать тот же объект.

ES Modules

ES Modules (дале ESM) — современная система модулей в JavaScript, которая пришла на замену CJS.

Node.js поддерживает ESM начиная с версии 12.

Важно: Расширение .mjs является рекомендованным расширением для NodeJS, которое явно указывает разработчику, что файл содержит ESM-модуль.

Интересно: ESM это официальная спецификация ECMAScript, в отличие от CJS, который по факту был решением сообщества NodeJS.

Синтаксис

Особенности

• ESM грузится асинхронно;
• Импорты должны находиться в начале ESM — такое статическое расположение позволяет сборщикам проводить более эффективный tree-shaking;
• ESM исполняется в строгом режиме и имеет собственную область видимости;
• ESM поддерживает динамический импорт, который возвращает модуль в виде промиса.

Интересно: Библиотеки часто публикуют dual-пакеты, то есть когда библиотека собирается и в CommonJS (.cjs), и в ES-модули (.mjs), чтобы быть более универсальными. Это может пригодится когда вы захотите оптимизировать сборку своего приложения.

Также ESM предоставляет объект import.meta для получения информации о модуле. В нём доступны свойства url dirname filename, которые содержат URL, директорию и имя файла модуля соответственно.

ESM можно подключать нативно, прямо в браузере:

Import Maps

Import Maps позволяют контролировать разрешение импортов в браузере, аналогично тому как это делают сборщики:

Import Maps обычно использую для:

• Алиасов;
• Версионирования;
• Когда выбор библиотеки зависит от окружения.

Также, Import maps очень полезен для быстрых прототипов на сервисах где можно пошарить какой-то компонент, чтобы не тащить сборку, например на Codepen.

Как можно импортировать модули?

В JavaScript существует множество видов импорта, каждый из которых служит своей цели и имеет конкретные особенности:

Именованный

Особенности:

• Точное указание импортируемых сущностей;
• Хорошо совместим с tree-shaking;
• Необходим для hot-reloading в dev-сервере.

Применение:

• Компоненты. утилиты, константы.

Важно: tree-shaking особенно хорошо работает при подходе один модуль = один файл.

Дефолтный

Особенности:

• Один основной экспорт на модуль;
• Возможность переименования при импорте;
• Плохо совместим с tree-shaking.

Возможные проблемы:

• Содержимое импорта может быть непонятным, до момента пока не заглянешь во внутрь;
• Один и тот же модуль может импортироваться под разными именами в разных файлах проекта, создавая путаницу;
• Слабая поддержка IDE.

Применение:

• Верхнеуровневые сущности;
• Ленивая загрузка модулей через React.lazy.

Комбинированный

Особенности:

• Совмещает импорт по умолчанию и именованный;
• Важен порядок объявления.

Применение:

• Модули с основным и вспомогательными экспортами.

Namespace-импорты

Применение:

• Удобен для конфигов, API, утилитарных функций.

Возможные проблемы:

• Легко поломать tree-shaking внутри модуля.

Здесь не стоит сильно пугаться что подход может поломать tree-shaking, чаще всего неиспользуемые функции, на которые нет ссылок вырезаются минификатором кода, так что если что-то в этом случае осталось в бандле, дело скорее всего в том, что функцию где-то есть ссылка.

Type-импорты

Особенности:

• Используются только для типов;
• Не попадают в runtime-код;
• Помогают избежать циклических зависимостей типов.

Применение:

• Импорт типов в TypeScript.

В TypeScript 5.0 появилась новая опция --verbatimModuleSyntax, призванная упростить ситуацию. Правила стали проще: все импорты и экспорты без type-модификаторов сохраняются. Всё, что использует type-модификатор, полностью удаляется.

Barrel-импорты (бочка импортов)

Особенности:

• Упрощение путей импорта за счёт централизации экспортов.

Возможные проблемы:

• Возможно снижение производительности при большом количестве реэкспортов.

Применение:

• Организация публичного API для папок и пакетов.

Относительные импорты

Особенности:

• Зависят от расположения файла на сервере или в файловой системе.

Применение:

• Локальные модули в пределах проекта.

Абсолютные импорты

Особенности:

• Независимость от структуры папок;
• Требуется настройка в сборщике или компиляторе.

Применение:

• Глобальные пути в проекте.

Как можно удобно организовать работу с импортами?

Алиасы

Алиасы это короткие и удобные сокращения для импорта модулей вместо длинных относительных путей. Алиасы делают код чище и упрощают рефакторинг.

Интересно: Автору много раз приходилось рефакторить проект с относительным путями, в ходе которого, во время переноса файлов, IDE не всегда мог корректно рассчитать новый относительный путь. Это приводило к тому что множество битых путей приходилось прописывать вручную.

Любой современный сборщик умеет работать с алиасами:

• webpack;
• vite;
• rollup.

В нейминге алиасов можно встретить разные подходы:

• src/components — простой и понятный, но может быть избыточным при неглубокой вложенности;
• @/components — популярный вариант, но может конфликтовать с названиями npm-пакетов;
• $/components — наименее популярные вариант, но имеет наименьшие шансы на конфликты;
• ~/components — оптимальный вариант, широко используется, интуитивно понятен пользователям unix-систем;
• #/components — современный подход, настраивается в package.json и поддерживается в TypeScript 4.9+.

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

Настройка алиасов через сборщик уже сегодня можно считать анти-паттерном, так как NodeJS позволяет настроить этот функционал через package.json

Паттерн разработки «реэкспорт через директорию»

Суть паттерн в создании единой точки входа для модуля через index.ts, который реэкспортирует нужные методы из вложенных директорий.

Преимущества:

• Короткие и чистые импорты;
• Группировка логически связанных модулей;
• Сокрытие внутренней структуры директорий.

Файл index.ts можно представить публичным API модуля, который отделяет его потребителей от внутренней реализации, что соответствует принципу разделения интерфейса (ISP) из SOLID.

Обычно, такой подход считается “антипатерном” в корпоративной разработке, так как чаще всего разработчики используют функцию автоимпорта в IDE, что может порождать разные пути импорта одного и того же файла. Лучше всего использовать его как некий фасад для публичного апи библиотеки, когда важна простота и лаконичность.

Сортировка импортов

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

Базовый порядок импортов:

Автоматизация

Сортировку импортов можно настроить как с помощью ESLint:

…так и при помощи Prettier:

Какие проблемы можно встретить при неправильном использовании импортов?

Циклические зависимости

Проблема возникает когда два модуля начинают импортировать друг друга напрямую.

Чаще всего циклические зависимости встречаются:

• В роутинге и навигации;
• В State-менеджменте.

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

Интересно: Автор чаще всего встречался с циклическими зависимостями при организации сложного стейт-менеджмента в Effector и RxJS.

Иногда циклическая зависимость возникает, когда модуль из длинной цепочки импортов начинает экспортировать другой модуль из той же цепочки:

Когда Module D начнёт импортировать Module A вы получите циклическую зависимость.

Ну и самое главное, почему эту проблему невозможно обойти: в случае если на каком-то из шагов потребуется инициализация переменной, которая участвует в этом цикле, она вернется как undefined. Особенно если создалось “состояние гонки”, когда модуль одновременно участвует в нескольких импортах, один из которых циклический. Получается классическая проблема иголки в столе сена, а значит отлавливать и следить за ними надо как можно раньше, пока внезапно вылезший undefined не увеличил сроки разработки.

Как предотвратить?

• Использовать архитектурные паттерны и методологии которые занимаются управлением потока данных: MVC, FLUX, FSD, Domain Driven Design;
• Строго соблюдать направление зависимостей: нижние уровни не должны зависеть от верхних;
• Стремится к минимальной вложенности модулей;
• Подключить автоматическое отслеживание циклических зависимостей через линтеры.

Поломка tree-shaking и code-splitting

Чтобы tree-shaking работал корректно с библиотеками, их нужно собирать, а затем подключать правильным образом. Например, именованный импорт из lodash затянет в сборку всю библиотеку:

В то время как точный импорт добавит в сборку только используемый метод:

Неиспользуемые импорты

Обычно это подключенные модули или зависимости, которые фактически не применяются в коде. Такого рода мёртвый код создает лишнюю нагрузку на проект, следовательно это нужно держать на контроле.

Это процесс можно автоматизировать при помощи ESLint:

…и TypeScript компилятора:

Как проанализировать конечную сборку приложения?

Для анализа итоговой сборки приложения существуют специальные инструменты визуализации бандла:

• webpack-bundle-analyzer;
• vite-bundle-analyzer;
• sonda.dev.

Лучшие практики

• Используйте абсолютные пути глобально, относительные — локально;
• Придерживайтесь единого стиля именования алиасов;
• Избегайте barrel-файлов для тяжёлых компонентов;
• Отдавайте предпочтение именованным импортам;
• Применяйте динамические импорты для редко используемых модулей;
• Проверяйте поддержку tree-shaking в сторонних библиотеках;
• Ограничивайте глубину относительных путей;
• Группируйте импорты по типам;
• Автоматизируйте соблюдение практик с помощью линтеров.

Заключение

Организация импортов в JavaScript-приложениях — далеко не второстепенная задача, а важная часть приложения способная повлиять на скорость сборки, производительность и читаемость кода.

Я бы еще добавил, что для теоретической базы архитектуры импортов стоит почитать про 2 принципа GRASP: Low cohesion и High Coupling. Cистема должна состоять из слабо связанных сущностей, которые должны содержать близкую бизнес логику. Соблюдение этих принципов позволяет удобно переиспользовать созданные сущности, не теряя понимания об их зоне ответственности.

Если вам понравилась статья — подписывайтесь на мой телеграм. Там я рассказываю о жизни разработчика, делюсь практическим опытом и инсайтами, которые помогут вам расти как специалисту ✨

Отдельное спасибо экспертам за их комментарии: Александру Коротаеву и Роману Титову, обязательно подпишитесь на их телеграмм-каналы Трудно быть Коротаевым и 🦜 on the web.

Остались вопросы по статье? Давайте обсудим в комментариях 👇

Рекомендуем

Как упростить импорт JavaScript-модулей с помощью Node.js Subpath Imports

Подготовка окружения React-приложения: VSCode, Prettier, ESLint, Stylelint, Husky

ReactJS на изи: что реально нужно знать фронтенд-разработчику в 2025 году

Ускоряем загрузку своего сайта

В повседневной работе с JavaScript нам часто приходится проверять значение переменной перед тем, как присвоить ей новое. Подобные проверки быстро превращаются в шаблон, особенно если вы работаете с props в компонентах, глобальными настройками или объектами состояния.

Именно здесь на помощь приходят логические операторы присваивания — компактное нововведение стандарта ES2021, которое позволяет сократить типичные условные конструкции, не меняя при этом саму логику кода.

Что такое логические операторы присваивания?

Логические операторы присваивания объединяют обычный логический оператор (||, && или ??) с оператором присваивания (=), создавая короткую и наглядную запись.

По сути, это синтаксический сахар, позволяющий писать условное присваивание в одну строку. При этом они работают по тому же принципу, что и обычные логические выражения: правая часть вычисляется только в том случае, если левая не проходит логическую проверку — то есть оказывается falsy, truthy или nullish (в зависимости от конкретного оператора).

Примечание: Оператор опциональной последовательности (?.) нельзя использовать в левой части логического присваивания.

Попытка сделать это приведёт к синтаксической ошибке:

Если нужно безопасно присвоить значение, используйте обычную проверку или промежуточную переменную:

Оператор опциональной последовательности (?.) возвращает значение свойства, а не ссылку на само свойство.

А поскольку в JavaScript присваивание возможно только в том случае, если левая часть выражения является ссылкой (например, переменной или свойством объекта), использование ?. в левой части делает выражение некорректным.

Логическое присваивание через OR (||=)

Оператор ||= выполняет присваивание только тогда, когда значение слева является ложным (falsy) — то есть false, 0, “”, null, undefined или NaN.

Присвоить, если значение — falsy.

Это эквивалент записи:

Этот оператор удобен, чтобы задать значение по умолчанию, если переменная ещё не инициализирована. Однако он перезаписывает такие значения, как 0, ” или false, даже если они были установлены специально.

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

Логическое присваивание через AND (&&=)

Присвоить, если значение — truthy:

Этот оператор полезен, когда нужно обновить значение только при наличии уже существующего truthy значения.

Примечание: при использовании &&= правая часть выражения вычисляется только если левая часть является truthy, и результат этого вычисления присваивается, даже если он окажется falsy.

Исходное значение (true) играет роль «ворот»: именно оно определяет, выполняется ли присваивание.

Однако новое значение берётся из результата вызова checkPermissions (или любого выражения справа).

Важно: оператор &&= не сохраняет старое значение, а заменяет его результатом вычисления правой части.

Присваивание через nullish-оператор (??=)

Присвоить, если значение — null или undefined:

Эквивалентно:

Используйте ??=, когда нужно задать значение только если переменная действительно отсутствует — то есть равна null или undefined, а не просто falsy. В отличие от ||=, этот оператор сохраняет корректные значения, такие как 0, false и ”.

Подробнее: если хотите глубже разобраться в механике nullish-оператора и принципах работы с дефолтными значениями — посмотрите материал о том, как грамотно использовать значения по умолчанию в JavaScript.

Значения по умолчанию для пропсов компонентов

Логические операторы присваивания особенно удобны при работе с пропсами в компонентах.

Например, если часть значений не передана, можно задать дефолты прямо в коде:

Такой подход:

• делает код компактнее и читаемее,
• избавляет от лишних if или тернарных выражений,
• позволяет контролировать поведение пропсов при разных типах значений (null, undefined, false, ”).

Идеально подходит для случаев, когда вы хотите задать понятные значения по умолчанию, не ломая текущую логику компонента.

Важно учитывать

• Оператор ||= срабатывает, когда левая часть — falsy-значение (0, ”, false, null, undefined). Это может привести к нежелательному перезаписыванию:

• Используйте ??= если нужно проверять только на null или undefined, сохраняя корректные falsy-значения (0, ”, false).
• Правая часть вычисляется только при необходимости, что сохраняет производительность и предотвращает побочные эффекты:

Пример с побочным эффектом

В этом примере:

• Изначально obj.val равно 0, что является falsy. Поэтому выражение ++calls вычисляется и присваивается obj.val.
• После первой строки obj.val становится 1 (truthy).
• На второй строке условие уже не выполняется, и ++calls не вызывается.

В результате значение calls остаётся равным 1, потому что вторая операция не выполняет инкремент.

Поддержка браузерами

Логические операторы присваивания поддерживаются всеми современными окружениями:

✅ Chrome 85+, Firefox 79+, Safari 14+, Edge 85+

✅ Node.js 15+

❌ Internet Explorer — не поддерживается

Если нужно обеспечить работу в старых окружениях, используйте транспайлер, например, @babel/preset-env с настройками ES2021.

Теперь вы готовы!

Логические операторы присваивания — небольшое, но очень полезное дополнение к JavaScript. Они делают код понятнее, уменьшают шаблонные конструкции и упрощают условную логику.

Особенно полезны они во фронтенд-разработке, например:

• при работе с props и state;
• при задании значений по умолчанию для API;
• при очистке и валидации форм.

Если вы уже уверенно используете ||, && и ??, переход на ||=, &&= и ??= будет естественным — здесь всё дело лишь в привычке.