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

Первым делом уменьшайте размер в пикселях, а не качество: фотография 6000×4000 в карточке шириной 1200 пикселей это чистые потери. Один этот шаг убрал 77% веса тестового снимка.

Формат выбирается под тип картинки: фотографиям WebP или AVIF, скриншотам и интерфейсам сжатие без потерь, логотипам SVG, анимациям анимированный WebP вместо GIF.

AVIF при равном качестве весит вдвое меньше JPEG, но кодируется примерно в пятнадцать раз дольше, поэтому генерировать его нужно на этапе сборки.

Метаданные съёмки занимают от 10 до 30 КБ на файл и в вебе не нужны ни для чего.

Сжатие с потерями на тексте и резких границах даёт видимые артефакты: скриншоты и логотипы жмутся только без потерь, зато на 20–60%.

Шаг, который экономит больше всех остальных

Прежде чем подбирать кодек и качество, посмотрите на фактические размеры. Фотография 6000×4000 в карточке шириной 1200 CSS-пикселей отдаёт браузеру в двадцать пять раз больше пикселей, чем нужно обычному экрану, и вшестеро больше, чем нужно экрану с двойной плотностью.

В замерах автора чеклиста одно только уменьшение до реально отображаемого размера ужало тестовое изображение с 4,7 МБ до 1,1 МБ. Это минус 77% при нулевой потере качества: пиксели, которых не видно, просто перестали передаваться.

Как определить нужный размер:
Отправная точка это ширина контейнера в CSS-пикселях. На обычном экране она же и есть нужная ширина в физических пикселях, на плотных экранах нужно кратно больше: у части ноутбуков это двойка, у большинства современных смартфонов тройка. Поэтому правильный инструмент здесь не фиксированный множитель, а атрибут srcset с несколькими вариантами файла: браузер сам возьмёт тот, что соответствует плотности экрана посетителя.

Формат под тип изображения, а не один на всё

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

• Фотографии — WebP (на 30–50% меньше JPEG) или AVIF (ещё примерно на 30% меньше WebP).
• Скриншоты и элементы интерфейса — PNG или WebP без потерь.
• Логотипы и иконки — SVG: вектор весит копейки и масштабируется без предела.
• Анимации — анимированный WebP вместо GIF, это экономит 60–80% веса.

Отдельно про текст. Сжатие с потерями на буквах и резких границах создаёт заметные ореолы вокруг символов, поэтому скриншоты и логотипы обрабатываются только алгоритмами без потерь. Инструменты вроде oxipng ужимают такие файлы на 20–60%, не меняя при этом ни одного пикселя.

Конвертация и сжатие — это два разных действия

Перевод PNG в JPEG экономит место. Сжатие получившегося JPEG экономит ещё столько же, и про этот второй проход регулярно забывают. Для фотографий рабочий диапазон качества это 75–82%: от стопроцентного такая картинка визуально неотличима, а весит заметно меньше.

Метаданные, которые вы отдаёте бесплатно

В файле с камеры или из редактора лежат EXIF, координаты GPS, модель камеры и метки программы обработки. Для показа в браузере это бесполезный груз весом от 10 до 30 КБ на файл, за одним исключением: тег ориентации. Часть снимков с телефона хранит пиксели неповёрнутыми и полагается на него, поэтому поворот нужно применить к самим пикселям до того, как метаданные срежутся, иначе фотографии лягут набок. На каталоге из тысячи товарных снимков набегает до 30 МБ трафика ни за что, а координаты съёмки вдобавок могут оказаться данными, которые вы не собирались публиковать.

AVIF: что это и почему его нельзя кодировать на лету

AVIF (AV1 Image File Format) выпущен Alliance for Open Media в 2019 году и построен на внутрикадровом кодировании видеокодека AV1. По сути это инструменты сжатия одного кадра AV1, упакованные в самостоятельный контейнер для картинок.

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

Сколько это в килобайтах

В сравнительном тесте брали пейзажный кадр 1920×1080 с градиентами неба, текстурой листвы и границами зданий, исходник в BMP весил 5,93 МБ. Целевое качество задавали по метрике структурного сходства: она сравнивает сжатую картинку с исходной, где единица означает полное совпадение, а 0,92 примерно соответствует порогу, за которым разницу перестают замечать глазом. Результаты:

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

Плата за это — время. Кодирование AVIF примерно в пятнадцать раз дольше JPEG и вчетверо дольше WebP, потому что выбор разбиения и типа преобразования требует перебора с оптимизацией. Зато декодирование медленнее JPEG всего вдвое, и на просмотр это почти не влияет. Практический вывод прямой: генерируйте AVIF заранее, на этапе сборки. Сервисы доставки изображений кодируют его и по запросу, но только с кешированием результата, чтобы платить за кодирование один раз на вариант, а не на каждого посетителя. Чего делать нельзя, так это кодировать заново при каждом обращении.

Как отдавать современный формат и не потерять старые браузеры

Поддержка AVIF в браузерах составляет примерно 96%, но подстраховка всё равно нужна. Делается она тегом <picture>: браузер берёт первый формат, который понимает, и до остальных не доходит.

Атрибуты width и height здесь не декоративные: без них браузер не знает пропорций до загрузки файла и подвёрстывает страницу заново, когда картинка приходит. Это тот самый прыжок содержимого, который портит метрику визуальной стабильности. Атрибут loading=lazy убирает изображения за пределами первого экрана из очереди, конкурирующей за отрисовку главного элемента.

Именно за пределами: на картинку первого экрана его ставить нельзя. Отложенная загрузка задержит ровно тот элемент, скорость появления которого и меряет метрика отрисовки основного содержимого. Там уместен противоположный по смыслу fetchpriority=high.

Сжатие в браузере: почему это вообще возможно

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

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

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

Вся тяжёлая работа уходит из главного потока

Перекодирование снимка 4000×4000 нагружает процессор настолько, что в главном потоке интерфейс замирает, а браузер показывает предупреждение о зависшей странице. Поэтому весь конвейер живёт в Web Worker: главный поток отвечает за выбор файлов, превью и состояние, а рабочий поток декодирует через createImageBitmap, применяет преобразования и кодирует через OffscreenCanvas. Именно через него, а не через canvas.toBlob: последний это метод DOM-элемента, а DOM в рабочем потоке отсутствует, и нужный метод там называется convertToBlob.

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

Три ошибки, которые ищутся дольше всего

Рабочий поток не имеет доступа к window. Причём не только напрямую: достаточно подключить библиотеку, которая трогает window на верхнем уровне модуля. В консоли разработчика появляется ошибка обращения к неопределённому объекту, а вот в интерфейсе не появляется ничего: если сбой рабочего потока никак не показан пользователю, тот видит вечный спиннер. Лечится ревизией всех импортов рабочего потока: библиотеки, завязанные на браузерное окружение, остаются в главном потоке и передают в рабочий поток уже готовые данные.

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

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

Заголовки безопасности ломают рабочие потоки молча:
Блокирует загрузку скрипта заголовок Cross-Origin-Embedder-Policy: он требует, чтобы каждый сторонний ресурс отдавал разрешающий заголовок, иначе браузер молча его отбрасывает. Cross-Origin-Opener-Policy на это не влияет, но включают их обычно парой, поэтому и ломается всё в одном релизе. Любое изменение заголовков безопасности проверяйте на настоящем развёрнутом стенде, а не только на машине разработчика.

Что это даёт в цифрах

Скриншот 1920×1080 проходит такой путь: исходный PNG весит 2,1 МБ, после уменьшения и перевода в WebP с качеством 75% — 186 КБ, то есть минус 91%. Тот же кадр в AVIF занимает 102 КБ, минус 95% от исходного.

Именно эти проценты и отделяют страницу, которая грузится четыре секунды, от страницы, которая укладывается в одну.

Что забрать с собой

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

Материалы разбора: чеклист оптимизации с замерами, техническое устройство AVIF и сравнительный тест форматов и разбор браузерного конвейера сжатия.

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

Практический смысл простой: то, что раньше делали через --i в инлайн-стиле каждого элемента или через JavaScript, теперь считает сам браузер. Ступенчатые задержки анимации в списке, ширина колонок по числу карточек, позиционирование по индексу без нумерации в разметке. По данным Web Platform DX, функции получили статус «newly available» с 18 августа 2026 года; статус «widely available» по правилам Baseline ожидается 18 февраля 2029 года, то есть старые браузеры ещё долго будут требовать запасного варианта.

• sibling-index() возвращает позицию элемента среди соседей, начиная с 1; sibling-count() возвращает число прямых детей родителя, включая текущий.
• Поддержка: Chrome и Edge 138 (июнь 2025), Safari 26.2 (декабрь 2025), Firefox 154 (18 августа 2026).
• Функции считают по дереву DOM, а не по flat tree; при попытке пересечь границу Shadow DOM результат может быть 0.
• Типичные применения: transition-delay и animation-delay по номеру, размер элемента в зависимости от числа соседей, раскладка без JavaScript.
• CSSWG допускает будущую форму с фильтром of, чтобы считать только соседей по селектору.

Как это выглядит в коде

Классический пример из обсуждения: список, где каждый следующий пункт появляется чуть позже предыдущего. Раньше для этого либо писали style="--i: 3" в каждом li, либо перечисляли :nth-child() вручную. Теперь достаточно одного правила:

Обе функции возвращают целое число без единиц, поэтому умножение на 80ms или на 100px внутри calc() работает как с обычной переменной. В спецификации CSS Values and Units Level 5 их называют tree-counting functions, функциями подсчёта по дереву.

Где функции ведут себя не так, как ожидается

• Считается дерево DOM, а не flat tree: слоты и элементы внутри Shadow DOM учитываются иначе, чем при рендеринге; на границе теневого дерева функция может вернуть 0, чтобы не раскрывать его содержимое.
• Учитываются все элементы-соседи, а не только подходящие под селектор. Если в списке есть скрытый li, он всё равно попадёт в счёт; форма с фильтром of пока только обсуждается в CSSWG.
• Индексация начинается с 1, как у :nth-child(), а не с 0.

Можно ли использовать в проде

Для декоративных эффектов вроде задержек анимации можно уже сейчас: в браузере без поддержки calc(sibling-index() * 80ms) будет невалидным значением, и правило просто не применится, элементы появятся одновременно. Для раскладки, от которой зависит читаемость, стоит завернуть правило в @supports:

Кому это ничего не даст: проектам, которые обязаны поддерживать браузеры старше Chrome 138 и Safari 26.2, а также тем, кто уже генерирует индексы на сервере. По данным Web Platform DX, Chrome и Chrome Android получили функции в версии 138 от 24 июня 2025 года, Edge 138 от 26 июня 2025 года, Safari и iOS Safari в 26.2 от 12 декабря 2025 года, Firefox и Firefox Android в 154 от 18 августа 2026 года.

Из соседних CSS-новостей на сайте: Firefox 155 добавил функцию progress(), а в Chrome 154 beta появились режимы links и tabs у scroll-marker-group. Черновик спецификации с формальным описанием функций лежит на сайте CSSWG.

Источники: Обсуждение в r/css, Web Platform DX: sibling-count и sibling-index, CSS Values and Units Module Level 5

Я разбираю 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

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 на десктопе и на бюджетном смартфоне — и сравните, где заметнее компромиссы качества.

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

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

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

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

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

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

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

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

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

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

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

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

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

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

В итоге я заменил самописную страницу на полноценный комьюнити-проект Homepage. Это дало некоторую гибкость: вся панель настраивается через простые YAML-файлы и поддерживает встроенные виджеты интеграции. Пока что она простенькая, но возможно в будущем сделаю что-то более продвинутое.

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

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

В статье разбираем, почему 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

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

Редакция Tproger недавно была нескольких таких ивентах и на партнёрском дне Диасофт пообщалась с членом правления Диасофт и директором по работе с партнёрами Александром Сахаровым. Мы поговорили о том, почему агентская разработка в её нынешнем виде — тупик, как строить эффективные AI-процессы разработки, почему фреймворк теперь важнее модели и что нового в AI-обновлении платформы Digital Q.

Digital Q — российская low-code экосистема разработки от «Диасофт» с готовым «заводом» инструментов для сборки корпоративных приложений: от проектирования бэкенда, дизайна интерфейсов до DevOps. В мае 2026 года вышла AI-driven версия, где искусственный интеллект встроен в саму платформу — он проектирует архитектуру, генерирует код, фронтенд и бизнес-процессы по человекочитаемой спецификации, оставляя разработчику работу с замыслом, а не с рутиной.

AI добрался до фундамента

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

— Главный сдвиг — это то, что AI добрался до вещей, которые казались незыблемыми. ERP-системы — это же фундамент крупного предприятия. И мы своими глазами видим, как крупные компании переходят на вайб-кодинг ERP. Звучит страшновато, но это факт, это происходит не в стартапах, а в очень больших организациях. Банки, промышленность, энергетика — везде одно и то же.

А шум — это вера, что AI всё решит сам по себе. Что можно купить лицензии Copilot, посадить за них разработчиков и они вам начнут производить продукты в десять раз быстрее. Нет, не начнут. Точнее, начнут, но счета вас очень неприятно удивят.

От агентов к AI-native платформе

Агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native

— Вы на сцене показывали, как обновился Digital Q с декабря. Что конкретно поменялось за эти полгода?

— В декабре, на зимнем партнёрском дне, мы представили платформу Digital Q.GPT — на ней можно реализовывать агентский workflow. Интеграция со всеми LLM-моделями, экосистема построения агентов, мультиагентные системы. На тот момент это было супер актуально.

К маю выяснилось, что этого недостаточно. За последние шесть месяцев все — Anthropic, Google, Gartner, Amazon, Сбер на ЦИПР — пришли к одному и тому же выводу: агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native, то есть AI вшит в саму экосистему разработки, а не прикручен сбоку отдельными агентами.

— А что плохого в агентах?

— С агентами ничего плохого, они нужны. Плохо, когда вся разработка строится только вокруг них. Если кто-то хочет писать агенты — пожалуйста, в Digital Q.GPT весь функционал остался: workflow, мультиагентные системы, всё это работает. Но это уже не центральная история. Центральная история теперь — единая экосистема, в которую AI встроен на каждом этапе процесса.

Три способа потерять деньги на AI

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

— Давайте про антипаттерны. Вы на сцене перечислили целый список — что точно делать не надо. Какой из них самый болезненный?

— Самый болезненный — вендорлок на конкретную LLM. Если вчера вы платили 20 долларов на разработчика в месяц, завтра это 100, послезавтра 200. Скоро будет дороже, чем один разработчик в месяц. И весь ваш контекст — спецификации, история, наработки — лежит у этой модели. Вы заложник. Они вам говорят: «не парьтесь, весь контекст у нас, всё будет хорошо». Хорошо у них будет, а у вас потом будут проблемы.

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

Третий — использовать AI только в кодировании. Это путь в галлюцинации и в бесконечные ошибки, которые вы потом просто не отследите.

— Как можно решить эти проблемы?

— Главный тезис: фреймворк важнее модели. Они это называют harness, мы называем экосистема разработки. Есть термины IDP — Integrated Development Platform, IDE — Integrated Development Environment. Суть одна. Ваш фреймворк должен быть локально у вас, весь контекст — локально у вас, модели должны быть взаимозаменяемые. Тогда вы можете переключаться между ними и управлять стоимостью.

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

Как теперь устроена разработка

— Вы говорили про два контура разработки. Объясните для тех, кто услышит об этом впервые.

— Раньше был один контур: ТЗ — постановка — кодирование — тестирование — релиз. Долго, последовательно. Цифровая трансформация это ускорила: годы превратились в кварталы и месяцы. Но всё равно один линейный процесс.

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

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

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

— Это та же мысль, что и про вендорлок, по сути?

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

— Вернёмся к Digital Q. Как она теперь устроена? Если разобрать на компоненты — что там лежит?

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

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

Разработчик всегда идёт на самую дорогую модель — она же лучшая. И запускает её сто раз в день. Ему кажется, что это бесплатно. Извините, не бесплатно.

— Почему вы так настойчиво возвращаетесь к теме денег? Ведь все маркетинговые материалы AI-вендоров обещают именно экономию.

— Потому что это самая опасная иллюзия сейчас. Uber, пытаясь сэкономить на разработчиках, потратил больше трёх миллиардов долларов на AI-генерацию кода. Японская компания за несколько месяцев потратила 500 миллионов долларов вместо тех людей, которых сократили. Долларов, не рублей. И это уже не теория, это свежие кейсы 2025–2026 годов.

Почему так получается? Потому что разработчик, если его не ограничивать, всегда идёт на самую дорогую модель — она же лучшая. И запускает её сто раз в день. Увидел маленькое расхождение в результате — поправил формулировку — перегенерил всё. Ему же кажется, что это бесплатно. Это так красиво, так удобно — нажал кнопку, всё пересоздалось. Извините, не бесплатно. Это огромные деньги. Свобода такая, что разоряет.

— И как вы с этим боретесь технически?

— Лимиты в самой экосистеме. Разработчикам автоматически предлагаются более дешёвые модели для простых задач, иногда вообще бесплатные. Жёстко зашиваем: при изменениях перегенерация только изменённых частей, не модуля целиком. Если в модуле 50 тысяч строк кода, и вы поправили одну спецификацию — не должны перегенериваться все 50 тысяч.

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

— Расскажите про демо с CRM. Вы показывали, как из 400-страничного ТЗ получается работающее приложение. Это правда один день двух человек, или там есть нюансы?

— Один день двух человек — это правда. Нюансы есть, конечно. Главный: это не black box, который сгенерил вам что-то непонятное. Это полностью оснащённый артефактами IT-проект. Можно пойти и сдать любому госзаказчику по ГОСТу. Полная документация — техническая, пользовательская, финансовая. Полный набор описанных бизнес-процессов. Полный набор тестов, включая тесты на уязвимости.

Что происходит по шагам? Загружаем ТЗ в основной контекст платформы. Она начинает читать, находит нестыковки, раскладывает по полочкам — где процесс, где поток, где архитектура. Задаёт уточняющие вопросы заказчику. Можно ответить, можно сказать «работаем как есть» — тогда она дальше креативит по тому, что есть.

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

— А фронтенд?

— Полностью автогенерация. Мастер: меню справа, меню слева, нужна аналитика — не нужна, нажал галочки — получил весь фронт. Документированный, открытый, лежит в гите. Дальше можно дорабатывать голосом — буквально говоришь в микрофон «добавь форму жалобы на робота», и она лезет в MCP, смотрит схему дизайна, добавляет форму, обновляет версии, выпускает изменение. Современные разработчики уже на клавиатуре ничего не пишут — у них микрофон.

Потом бизнес-процессы. Та же AI-машина смотрит на ТЗ и генерит BPMN-процесс — уже машиночитаемый, его можно сразу выполнять. Но она же его и критикует: смотрит со стороны и говорит — у вас тут проблема, тут проблема, ТЗ было неполным, давайте решать. И человек уже работает с агентом, который ему подсвечивает дыры.

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

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

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

Фишка нашей платформы в том, что мы все роли оснастили всеми агентами из коробки. Не надо ничего собирать самому. Скачали Digital Q, поставили, производите ПО.

Что доступно прямо сейчас

С июля начинаем публиковать обновлённую версию. Можно скачать, развернуть, запускать.

— И эта экосистема действительно доступна партнёрам?

— Да, мы её отдаём рынку. С июля начинаем публиковать обновлённую версию для партнёров. Можно скачать, развернуть, запускать. Правда, нужно знать, что такое Kubernetes и Kafka — это не магический инсталлер для гуманитариев. Но если знаете — берёте и работаете.

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

— Возвращаясь к началу разговора. Вы фактически заявляете, что Диасофт — единственный, кто отдаёт такую экосистему рынку. Это правда так, или маркетинг?

— Это так. Давайте честно: на российском рынке такие экосистемы делают несколько компаний. Сбер, ВТБ, Тинькофф — для себя. Это им и нужно, у них колоссальные команды разработки, они это могут себе позволить. Кто-то из телекома делает для своих больших разработок. Иногда они пробуют что-то предложить рынку, но по большому счёту — это всё «для себя».

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

Если такого человека нет — никакая AI-генерация вас не спасёт. Будет только дороже и хуже.

— Какой главный совет тем, кто только сейчас задумывается о собственной AI-трансформации разработки?

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

И ещё одно. Команды теперь строятся вокруг продуктового инженера. Это новая ключевая роль. Раньше ценностью был код. Сейчас ценность — бизнес-компетенция, способность правильно поставить задачу. Если у вас есть человек, который понимает бизнес и умеет это сформулировать — код появится быстро. Если такого человека нет — никакая AI-генерация вас не спасёт. Будет только дороже и хуже.

Бонус: чек-лист «AI-разработка без иллюзий»

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

Чего точно не стоит делать:

— Сажать команду на одну LLM-модель — это вендорлок, и он будет дорожать;

— Разрешать разработчикам неограниченно гонять самую дорогую модель;

— Использовать AI только в кодировании, без интеграции в остальной процесс;

— Накупить разных инструментов и надеяться, что они потом «как-нибудь соберутся»;

— Сокращать разработчиков в расчёте на «бесплатные» токены.

Что стоит сделать:

— Держать экосистему разработки и весь контекст локально;

— Зашить в платформу переиспользование кода — половину нового модуля собирать из готового;

— Настроить лимиты: дешёвые модели для простых задач, перегенерация только изменённых частей;

— Разделить процесс на два контура — замысла (где работает человек) и исполнения (где работают агенты);

— Растить продуктовых инженеров — людей, умеющих формулировать задачу, а не только писать код.

Реклама. Рекламодатель: ООО «Диасофт», ИНН 7715560268, erid: 2W5zFJRM88q

На первый взгляд кнопка «наверх» — задача на пять минут. Добавил 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.

В начале июня команда 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.

• Базовые знания 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 сбросит любые стили, определённые до тех пор, пока эти правила не встретятся. Это не предотвратит применение дальнейших неограниченных стилей в файлах или тегах

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.

Всё началось с безобидного, почти рутинного тикета в саппорт:

«У меня тут несколько одинаковых карт создалось. Я вроде один раз нажимал, а их штук пять висит в приложении».

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

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

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

Мы начали разбираться. Стандартный мониторинг показывал норму: дашборды зелёные, в логах тихо, метрики CPU и памяти без отклонений. При этом в базе обнаруживались дубликаты, которых быть не должно. И только тогда, когда мы внимательно посмотрели на коммунальный API Gateway, то поняли что одно изменение от другой команды поменяло идемпотентность работы endpoint-а.

Проблема была структурно невидима для тех, кто находился ближе всего к ней. Отсутствие видимой проблемы не равно отсутствию риска — система просто ждала подходящего момента.

Что произошло: хронология инцидента

Архитектура была классической: Клиент → API Gateway → микросервисы,.

Сценарий развивался почти незаметно для стандартных средств наблюдения:

1. Фронтенд: Пользователь нажимает кнопку «Выпустить карту».

2. Gateway: Запрос начинает обрабатываться в API Gateway.

3. Микросервис по созданию карт: честно выполняет работу: создаёт запись в БД и возвращает `200 OK` в Gateway.

4. Новый микросервис: API Gateway вызывает новый микросервис и получает HTTP 500 в ответ от него. Исключение возникает уже после успешного вызова нашего микросервиса, и это ключевая точка разрыва: Gateway считает весь запрос неудавшимся, а ответ нашего микросервиса теряется.

5. Клиент: получает HTTP 500

6. Реакция: Пользователь видит красную плашку ошибки и логично решает: «Не сработало, пробую снова». Более того, с точки зрения протокола HTTP - запросы, в ответ на которые пришла ошибка HTTP 500, можно пытаться отправлять опять.

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

Круг замкнулся. Эпидемия началась.

В компании такого уровня это не было предусмотрено. И это такая обидная ошибка.

Как так получилось?

Вскрылось ошибочное предположение:

«В API Gateway вызов микросервиса создания карт всегда идет последним».

Таким образом идемпотентность достигалась «формально» - ведь если создание карты завершалось с ошибкой - это точно означало что и вызов API Gateway тоже завершится с ошибкой. Сработало ложное чувство безопасности.

Ответ на вопрос “почему так было сделано?” очень простой - это было осознанное упрощение на старте. Все знали об этом, но задача на фикс потерялась в недрах бэклога на очень долгое время. Это классический пример того, как архитектурное допущение и отложенный рефакторинг годами живут в проде, пока их не вскрывает редкая последовательность отказов.-

Что потребовалось изменить

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

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

1. Почему нельзя просто заблокировать кнопку на фронте?

Блокировка кнопки решает проблему только при стабильной сети. Если запрос ушёл, сервер создал сущность, но ответ потерялся — кнопка разблокируется по таймауту, и пользователь нажмёт снова. Это не устраняет корневую причину, а лишь слегка снижает вероятность дубля.

2. Чем идемпотентность отличается от дедупликации в БД?

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

3. Как долго хранить ключи идемпотентности?

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

4. Что делать со старыми клиентами, которые не шлют request_id?

Мы сделали несколько версий API для создания карт — под разные версии приложения. Для новых клиентов работала полноценная идемпотентность с клиентским ключом. Для старых версий приходилось принимать риски и генерировать request_id на стороне сервера. Альтернативой может быть хэширование payload запроса, но это менее надежно и сложнее: таймстемпы и случайные поля могут отличаться от вызова к вызову. Поэтому мы выбрали подход с генерацией ключа на сервере для устаревших клиентов: риски дублей на переходный период оказались меньше, чем сложность поддержки двух схем валидации одновременно.

5. Обязательно ли делать идемпотентность для всех методов API?

Идемпотентность требуется только для методов, которые изменяют состояние системы — POST, PUT, PATCH и иногда DELETE. Методы чтения (GET, HEAD, OPTIONS) не изменяют данные, поэтому считаются идемпотентными по умолчанию.

6. Как понять, что в вашей системе уже есть скрытая проблема с дублями?

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

Если метрик ещё нет, вот три косвенных признака, которые помогут заподозрить неладное:

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

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

Итог

Главный урок, который мы вынесли: идемпотентность — это общая ответственность всех команд разработки, и поломать её может быть проще, чем кажется. А добавить в уже работающую систему быстро и дёшево — почти невозможно.

Метрик на всплески повторных запросов у нас не было. А зря — это самый дешёвый способ увидеть проблему до того, как она обрушит продакшен. Системы, спроектированные на 10% нагрузки, ломаются на 60% — и обычно это становится неожиданностью для команды.

Практический чек-лист: что проверить в своей системе уже сегодня

• Убедитесь, что все критические мутирующие эндпоинты поддерживают ключ идемпотентности.
• Настройте алерты на аномальное количество запросов на создание сущностей от одного пользователя за короткий промежуток времени.
• Проверьте, как ваш API Gateway обрабатывает ошибки — не теряет ли он ответы downstream-сервисов.
• Убедитесь, что фронтенд корректно обрабатывает не только 200, но и 500, 502, 504, не провоцируя пользователя на повторные клики без необходимости.

Tailwind обучает системам: reset, цветовая палитра, шкала размеров — всё это переносится в CSS custom properties без зависимостей.

Компонентный подход (один класс — один CSS-файл) резко снижает когнитивную нагрузку: 100 строк компонента — это только 100 строк.

CSS Grid с auto-fit и minmax() создаёт гибкие сетки без единого media query.

В dev-режиме сборщик не нужен: браузер понимает нативные @import и вложенные селекторы. Для production — одна команда esbuild.

Tailwind v2 без сборщика весит 2,8 МБ (270 КБ gzip) в каждом проекте — и это один из аргументов для миграции.

Зачем уходить с Tailwind

Прежде чем разбирать систему, — почему вообще стоит её строить, если Tailwind под рукой.

• Build-система стала обязательной. Tailwind v3+ требует JIT-компилятора. Без сборщика вы застряли на v2 — а это 2,8 МБ CSS (270 КБ gzip) в каждом проекте.
• Смесь стилей неудобна. Когда в одном проекте живут и ванильный CSS, и Tailwind — сопровождение становится болезненным.
• Tailwind ограничивает. grid-template-areas технически работает через arbitrary values, но синтаксис настолько громоздкий, что на практике им никто не пользуется. Container queries, @layer, @scope — туда же.
• Накопленный опыт. После нескольких лет работы ванильный CSS уже не пугает.
• Ценность CSS-экспертизы. Джулия упоминает эссе «Tailwind and the Femininity of CSS»: Tailwind косвенно транслирует идею, что CSS — не настоящее программирование. Она больше не хочет поддерживать этот нарратив.

При этом Tailwind честно обучал хорошим системам. Миграция — не отказ от этих систем, а их присвоение в виде нативного CSS.

Что Tailwind успел дать

Приступая к миграции, Джулия поняла: у неё уже есть многое из нужного. Любая CSS-кодовая база состоит из нескольких слоёв — раскладка, шрифты, цвета, переиспользуемые компоненты. Для каждого нужна система, иначе хаос. Tailwind эти системы давал: reset-стили, цветовую палитру, шкалу размеров шрифтов. Переход — это не изобретение колеса заново, а перенос уже понятых систем в нативный CSS.

Девять аспектов структуры CSS

Как Джулия организует свою CSS-кодовую базу сегодня.

1. Reset-стили

Простейшее решение — скопировать первые ~200 строк Tailwind Preflight из tailwind.css. За годы работы привыкаешь к box-sizing: border-box и line-height: 1.5 как к умолчаниям. Перенос preflight сохраняет привычное поведение без npm-зависимости.

2. Компоненты

Это ядро подхода. Идея та же, что в Vue или React-компонентах — но без JavaScript. Три правила:

• У каждого компонента — уникальный CSS-класс.
• CSS одного компонента никогда не перекрывает стили другого.
• Каждый компонент живёт в собственном CSS-файле.

При редактировании ста строк компонента нужно думать только о ста строках. Нативные вложенные CSS-селекторы (поддерживаются всеми браузерами с 2023 года) делают код компактным:

3. Цвета

Одно правило: все цвета сайта объявляются в colours.css через CSS custom properties — никакого хардкода в компонентах.

4. Размеры шрифтов

Вместо классов text-lg — переменные, взятые из Tailwind. Не нужно помнить, в каких единицах задавать размер (em, px или rem):

5. Утилитарные классы

Небольшой файл для вещей, которые встречаются в разных компонентах — кнопки, .sr-only для скринридеров и т.п. Держится маленьким намеренно.

6. Базовые стили

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

7. Отступы

Наименее завершённая часть системы. Основной принцип: за внешние отступы отвечает родительский контейнер, а не сами компоненты. Паттерн «owl selector» (или «lobotomized owl» — селектор вида * + *) даёт отступ между любыми соседними дочерними элементами, не трогая первый:

Дополняет это принцип «no outer margin»: компоненты не задают собственные внешние отступы — ими управляет исключительно родитель. Это предотвращает коллизии при вставке компонента в разные контексты.

8. Адаптивный дизайн: больше Grid

Вместо Tailwind-классов вида md:text-xl — гибкие сетки CSS Grid, которые сами адаптируются без брейкпоинтов. auto-fit — директива Grid, которая создаёт столько колонок, сколько умещается в контейнер (может быть 4, 3, 2 или 1 — в зависимости от ширины):

Ещё одна возможность, неудобная в Tailwind, — grid-template-areas (именованные зоны сетки): в Tailwind её можно задать через arbitrary values, но синтаксис настолько громоздкий, что в реальных проектах это нечитаемо. В ванильном CSS это просто:

9. Система сборки: esbuild

В dev-режиме сборщик не нужен совсем: современный CSS поддерживает нативные @import и вложенные селекторы в браузере без препроцессоров.

Для production-бандла Джулия использует esbuild — сборщик на Go, распространяемый как нативный бинарник (без Node.js в runtime), который работает в десятки раз быстрее webpack:

Возможности CSS, которые стоит изучить

В процессе миграции Джулия наткнулась на несколько возможностей CSS, которые пока не использовала:

• @layer — каскадные слои для управления приоритетом стилей без повышения специфичности.
• @scope — ограничение области действия CSS-правил конкретным поддеревом DOM.
• Container queries — медиазапросы относительно размера родительского контейнера, а не viewport.
• Subgrid — вложенные сетки, наследующие треки родительской Grid.

Итог

Главный вывод: Tailwind — это не магия, а набор систем. Reset-стили, цветовая палитра, шкала размеров шрифтов — всё это существует в нативном CSS как custom properties. Компонентный подход решает те же задачи изоляции. CSS Grid делает большинство media queries ненужными. А esbuild заменяет тяжёлый toolchain одним бинарником.

Начать можно с трёх шагов: скопировать Preflight → добавить custom properties для цветов и размеров → разбить стили по файлам-компонентам. Оригинальная статья Джулии Эванс доступна на jvns.ca.

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

• Что изменилось: Mozilla и Apple наконец смержили патчи (авторы — Simon Pieters в Gecko и Yoav Weiss в WebKit), и sizes="auto" работает во всех движках. Раньше фича жила только в Blink (Chrome, Edge). Конкретные номера версий Firefox и Safari, в которых оказалась поддержка, лучше сверять по caniuse.
• Как использовать: только на изображениях с loading="lazy". К img добавляете sizes="auto" — браузер берёт реальный размер элемента из layout и выбирает source из srcset.
• Когда не работает: hero-картинки и LCP-кандидаты (Largest Contentful Paint — самый крупный визуальный элемент в первом экране, ключевая метрика Core Web Vitals), у которых нет loading="lazy" (их браузер запрашивает до того, как знает layout). Им по-прежнему нужен явный sizes — но это редкие исключения, а не правило.
• Безопасность миграции: sizes — descriptive-атрибут (описывает факт, а не команду). Браузеры без поддержки auto просто проигнорируют ключевое слово и откатятся к запасному значению — например, sizes="auto, (min-width: 1040px) 650px, 100vw".
• Уже в продакшене: WordPress использует этот подход после патча от Joe McGill — выходца из RICG (Responsive Images Community Group).

Четырнадцать лет ожидания

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

Тогда, четырнадцать лет назад, я был достопочтенным председателем RICG (Responsive Images Community Group) — пиратской радиостанции среди web standards bodies, ответственной за то, чтобы привести в платформу разметку для responsive images. Кто-то из вас помнит. Кто-то был там, на заре responsive web design, и помогал находить новые сценарии, в которых веб-платформа не справлялась — когда сборная команда фронтенд-специалистов сплотилась, организовалась и врезалась лбом в процесс веб-стандартов, который не был ей рад. Мы требовали место за столом наряду с производителями браузеров и представляли интересы веб-дизайнеров, разработчиков и тех пользователей, которым мы служили. Нас были сотни. После лет итераций, бесчисленных черновиков спецификаций и прототипов, бесконечных споров, превращавшихся в консенсус через древние мейл-листы и IRC-каналы, мы вместе с вендорами браузеров наконец пришли к рабочему синтаксису. И сделали его реальностью — собрали деньги в коммьюнити, чтобы оплатить независимые реализации в браузерах, написали полифиллы для разгона adoption, прикрутили это всё к крупным CMS, написали статьи, выступили с докладами и распространили — позвольте сказать — лучшие футболки в истории веб-стандартов.

Я понимаю, что многие из вас при всём при этом отсутствовали — это древняя история по меркам веб-разработки. Для вас разметка для responsive images существовала всё то время, что вы делали сайты: плотный, непрозрачный, неотвратимый и неизбежный аспект платформы, замысловатый синтаксис и постоянный источник фрустрации.

Если вы из второй группы — позвольте представиться: это всё я. Прямо здесь — я.

Каждый раз, когда вы безуспешно пытались понять, почему браузер выбирает конкретный source из srcset, — это я вас мучил. Каждый раз, когда приходилось затаскивать огромную third-party библиотеку, чтобы справиться с синтаксисом, который явно не задумывался для написания человеком, — я был причиной; чёрт, я даже мог его соавторствовать. Когда вы запускали bookmarklet, который ломал ваш workflow, в надежде, что он сгенерирует значение sizes, более-менее совпадающее с реальностью ваших layouts. Когда становилось слишком много, и вы опускали руки — сдавались — и в итоге грузили на пользователей огромные оригиналы, от которых те никогда не получат никакой практической пользы, но заплатят всю цену в производительности. Это всё было не вашей виной. Это было моей. Я не только не остановил эти синтаксисы от стандартизации — я был их знаменосцем. Я зубами рвал за разметку, которую вы прокляли.

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

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

Зверь, которого нужно было приручить

Поймите меня правильно — я не ненавижу сами responsive images. Проблему нужно было решать, никаких сомнений. Тогда, как и сейчас, подавляющая часть transfer size сайта приходится на изображения. Гибкая картинка требует source, достаточно большого, чтобы покрыть максимальный размер, который она занимает в layout — без responsive images картинку, которая занимает в макете, скажем, две тысячи пикселей в ширину, пришлось бы отдавать каждому пользователю в оригинальных 2000 px. Уменьшить её в CSS — тривиально, но запрос-то тот же. Пользователь несёт все издержки трафика, ничего за это не получая.

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

А вот picture — это отдельная история. picture мне нравится с самого начала. Что не любить-то? Кому не нужен такой уровень контроля? К тому же picture позволил ответственно отдавать новые форматы изображений с быстрым и надёжным механизмом отката между браузерами — открыл двери невероятным успехам в кодировании и сжатии, причём без единой строчки JavaScript. Синтаксис читается осмысленно, он даёт нам шаблон для стандартизации более умных решений вокруг любых медиа-запросов и становится мощнее с каждым добавленным media query. picture крутой, мне нравится picture, всем нравится picture. Мы здесь не про picture.

picture принципиально отличается от srcset и sizes — последние представляют собой descriptive-синтаксис. Чтобы было сразу понятно: descriptive — это «описательный»: вы описываете факт (какие источники у картинки и какого размера она в layout), а решение принимает браузер. Prescriptive — «предписывающий»: вы прямо говорите, что делать. srcset вы используете, чтобы дать браузеру информацию про набор источников, идентичных везде кроме разрешения; sizes — чтобы дать информацию о том, каких размеров изображение будет отрендерено. Ни один из этих атрибутов не говорит браузеру, что делать. Получив эту информацию, браузер делает ровно одну, очень сложную, вещь: определяет источник, наилучшим образом подходящий под контекст пользователя. Визуально источник, выбранный из srcset, неважен — все они выглядят одинаково. Но выбранный кандидат лучше всего подходит под условия пользователя. Вы не получаете никакого контроля над тем, как принимается это решение. Более того — вы даже не имеете права знать, как оно принимается. By design — то есть так задумано: это намеренно вырезано в HTML-спецификации:

Реализация сама определяет, как — выбрав один источник из набора кандидатов. (In an implementation-defined manner, choose one image source from sourceSet.)

Как вам такое? «Тогда браузер», в строгих технических терминах, просто делает что захочет. Этот формально кодифицированный недостаток контроля не случился сам: ответственность могла остановиться на мне — но не остановилась. Я лично проголосовал «за» за решение, что у вас не должно быть права голоса в том, как работают srcset/sizes — что вы даже не можете знать, как они работают. Сейчас, после всех этих лет, при разоблачении меня как злодея этой истории, я наконец могу рассказать почему. И вам это тоже не понравится. Потому что я знал — вы бы сделали неправильно.

Это работа не для человека

Не воспринимайте это слишком лично — я бы тоже сделал неправильно. Чёрт возьми, я и делал неправильно, через десятки предложений и прототипов, в поисках решения, которое можно было стандартизировать. Все делали неправильно. В итоге все эти итерации только доказали: никто не мог сделать эту часть правильно. Та «одна вещь», которую делают srcset/sizes — определение источника, наилучшим образом подходящего под контекст пользователя, включая размер viewport, плотность дисплея, пользовательские настройки, пропускную способность и бесчисленное количество других потенциально непознаваемых факторов? В этих факторах есть вещи, которые мы знать не можем, и столько же — которых нам знать не следует.

Например, мы не можем подстраивать выдачу под скорость соединения пользователя — кажется, что жаль. Но представим на секунду, что могли бы — что мы могли бы сказать «выше этой скорости — этот source, ниже — тот». Теперь это решение ваше. Какие пороги скорости вы бы выставили для своих картинок, и какие я — для своих? Они будут разные. То есть для одной и той же скорости пользователь получит на одном сайте красивые, но забивающие канал картинки, а на следующем — сильно сжатые, но эффективные. Какие из них пользователь хочет? Вопрос с подвохом — все хотят разное. А чего хочет ваша компания? Уф. Все смотрят на вас — на вас, с открытыми тикетами, митингом через полчаса и всем этим контролем, который вам в руки сунула спецификация. Почему сайт ощущается так медленно? Почему наши картинки теперь выглядят хуже, чем у конкурентов? Почему сайт опять ощущается так медленно? Даже когда мы рассматриваем только скорость соединения, цена нашего контроля — это утрата контроля у пользователя. А ведь мы ещё ничего не сказали про остальные факторы.

Я не хотел этого. Я не хотел этого для тех, кто строит веб, не хотел этого для тех, кто пользуется вебом, и точно не хотел смотреть, как сам веб трещит под весом миллиона огромных картинок и сотни тысяч тикетов «надо когда-нибудь подробно расписать нашу политику работы с responsive images», похороненных в трекерах навечно.

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

В итоге нам не нужен контроль, когда речь о выборе источника. Нам нужны просто быстрые картинки — и srcset с sizes закрывают этот use case прекрасно. Лучше, чем кто-то из нас способен был бы лично, если бы пришлось. Было бы кошмаром, если бы пришлось. Descriptive-синтаксис избавляет нас от всего этого ужаса и позволяет браузеру делать то, что он умеет лучше всего: использовать информацию, которая у него уже есть, чтобы сделать один эффективный запрос за источником. Нам остаётся только дать ему ту небольшую часть информации, которой у него нет.

Честно говоря, srcset даже не так уж плох, всё взвесив! Любая CMS, статический генератор или build-tool в мире легко выплюнет список сгенерированных источников и их ширин через запятую. Чем больше значений вы туда положите, тем эффективнее и точнее будут запросы. Никаких страданий, никаких user-facing издержек, кроме нескольких лишних байт разметки. Аккуратный синтаксис, если приглядеться. srcset — норм.

Responsive images — не проблема. picture — не проблема. srcset — даже не проблема.

Мы оба знаем, в чём проблема.

Дилемма sizes

Браузер не может знать, сколько места займёт изображение в макете, потому что принимает решения по запросам картинок задолго до того, как у него будет информация для рендера layout — там просто пока нечего измерять. Размер viewport в этот момент уже доступен — но это ужасный proxy для размера реально отрендеренного изображения. Веб не сделан из full-bleed «hero»-картинок; он сделан из колонок и гридов, сайдбаров и «карточек» и кучи маленьких круглых аватарок. Допущение, что source никогда не будет больше viewport, — неплохое начало (поэтому пропущенный sizes, формально невалидный, работает как sizes="100vw"). Но этого недостаточно. И вот мы с вами вынуждены описывать все размеры, которые элемент примет на всех breakpoints и контейнерных запросах, единой строкой в HTML-атрибуте. Какая мерзость.

Именно потому, что для sizes нужна информация об окружающем layout, его невозможно автоматизировать. Сборочный процесс не может узнать, сколько места займёт картинка в разных макетах без огромных накладных расходов — вроде «собрать всё, отрендерить весь сайт, замерить каждое изображение на каждой странице, сгенерировать sizes для всех, и только потом продолжить сборку». Поэтому мы пишем эти описания вручную — и за исключением совсем простых случаев это нельзя сделать без инструментария. Описание размеров гибкой картинки требует слишком многих вычислений между breakpoints. Вот пример из относительно простого макета:

Никто не должен быть способен это написать. В смысле — как? Изменяя размер браузера и щурясь? Гадая? sizes — один из немногих паттернов разметки, которые буквально требуют инструментария, что максимально далеко от веб-этоса «открой текстовый редактор и собери сайт» — этоса, который я очень ценю. Чёрт, даже если бы вы умудрились описать всё через media query — то есть использовать прескриптивный синтаксис как дескриптивный, говоря «выше такого размера вот это произойдёт» вместо «выше такого размера сделай вот это» — мне делается дурно. Я ненавижу sizes. Я всегда ненавидел sizes.

Поэтому я здесь. Поэтому я наконец об этом пишу. Я не извиняюсь за sizes. Я здесь, чтобы помочь его похоронить.

Начало и конец

Несколько недель назад в Gecko и WebKit залендили патчи — авторы Simon Pieters и Yoav Weiss, два лучших участника RICG. Эти патчи влились тихо, выровняв Gecko и WebKit с Blink — поддержка значения auto в атрибуте sizes. Автоматический sizes — потенциальные размеры отрендеренного изображения, которые браузер определяет сам, наряду со всеми остальными факторами. Полностью автоматические responsive images. Передаёте список кандидатов через srcset, прикручиваете sizes="auto" — и браузер делает остальное.

Как? Центральная проблема srcset/sizes была в тайминге: браузер принимает решения по запросам картинок задолго до того, как у него есть информация о макете страницы, поэтому мы должны были давать ему информацию о layout сами. Это допущение больше не строго истинно. Это всё ещё дефолтное поведение: если в разметке есть img, запрос за ним уйдёт задолго до того, как layout будет известен, — если только картинка не использует атрибут loading="lazy" (исключительно частая лучшая практика для всех картинок, кроме тех, что почти наверняка попадут в viewport при первой загрузке страницы). Добавление loading="lazy" к img меняет всё уравнение: теперь эти изображения запрашиваются в момент пользовательского взаимодействия, гораздо позже момента, когда у браузера уже есть вся информация о размерах будущего рендера. Браузеру больше не нужны мы — и в мире всё стало хорошо.

Готов поспорить, вы ждёте подвоха. Не ждите. Если переживаете за поддержку браузеров — не стоит: встретив строку «auto» в начале sizes, любой браузер с поддержкой скажет «понял, дальше я сам», выкинет остальную часть sizes и продолжит. Браузер без поддержки выбросит auto как бессмысленное и продолжит читать атрибут как обычно. Это значит, что начать использовать можно прямо сейчас — без затрат и накладных расходов, кроме набора слова auto, в начале sizes:

Не первое матерное слово, на которое меня сподвиг sizes, но точно с самым позитивным результатом.

Этот подход — ровно то, что теперь использует WordPress.

Когда sizes ещё нужен

Конечно, это не конец абсолютно — описательные значения sizes вам всё ещё иногда понадобятся. Картинка, которая, скорее всего, попадёт в viewport при первой загрузке, — это сценарий, в котором вы не хотели бы использовать loading="lazy" (а sizes="auto" работает только с ленивыми изображениями). Но такие картинки — исключения, не правило.

Эти редкие исключения — изображения, почти наверняка попадающие в viewport в самом верху страницы, ваши вероятные Largest Contentful Paint элементы (LCP — самый крупный визуальный элемент в первом экране, ключевая метрика Core Web Vitals; лениво грузить такое нельзя — у него слишком ранний дедлайн), которым плохо живётся под loading="lazy"? Ну, вы только что представили их в голове, верно? Большая «hero»-картинка, тип изображения, который, скажем, занимает всю ширину viewport-а или близко к этому. Их относительно легко описать через breakpoints. Может быть, что-то в районе — ну, вытащу значение из воздуха — sizes="100vw". Все остальные картинки — те, что раскиданы по колонкам, гридам, сайдбарам, «карточкам» и кучкам маленьких круглых аватарок, из которых на самом деле и сделан веб? loading="lazy" sizes="auto". Готово. Поздравляю.

Я не буду скучать по всем этим вручную выкованным sizes. У меня к ним любви и не было. Я никогда не испытаю ни проблеска ностальгии по тому, что я помог сделать реальным и неотделимо связал со своим именем. Синтаксис никогда не был целью; целью всегда был механизм. На тот момент платформа не давала браузерам способа принимать более умные решения о том, какой источник запросить и когда — никакие сценарии или markup-трюки никогда не дадут request настолько же быстрый и эффективный, как тот, что делает сам браузер. Мы получили этот механизм — и я заставил всех нас оплатить его стоимость, ради пользователей и ради здоровья веба.

Так что любой из вас, дизайнеров и разработчиков, кто боролся с атрибутами sizes в прошлом, — давайте, нарисуйте мой портрет, какого хотите размера, распечатайте и приклейте к ближайшей дартс-доске. Я держу голову высоко и не приношу извинений. Я был прав. Мы были правы. Я по-прежнему стою за необходимость декларативного синтаксиса. Стою за это ровно настолько же, насколько жалею, что он не мог быть лучше — и ровно настолько же, насколько знаю, что в то время не мог. Конечно, я ёжусь от идеи отдать контроль не меньше, чем любой разработчик, но когда речь о высокопроизводительных изображениях — у нас никогда не могло быть контроля по-настоящему. Было бы самонадеянно даже пытаться. И как бы фрустрирующе это ни было — отказаться от контроля — владеть responsive images было бы бременем; проклятием.

Спросите меня, откуда я знаю.

Что делать сегодня

Поправка к шаблонам короткая. У всех img с loading="lazy" в проекте — поставить sizes="auto" (можно с запасным значением auto, … для старых браузеров). Hero-картинки и явные LCP-кандидаты оставить как есть. Сборку и pre-render это не ломает: auto — расширение существующего descriptive-синтаксиса, не замена. Если вы пишете на современном WordPress — вероятно, вам уже ничего делать не нужно.

Оригинал статьи Mat Marquis — на Piccalilli. Спецификация атрибута sizes с поддержкой auto — в WHATWG HTML. Совместимость по версиям браузеров — на caniuse.

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

Концепция. Забытая мельница на воде, рендерится как акварель, но полноценно 3D и интерактивна. Вода, ветер, сцена — единое атмосферное пространство. Под мирным фасадом скрыт сюрреалистический намёк: подводная мельница бесконечно производит хлеб, хотя зерно давно ушло.

Стек. React, React Three Fiber, Drei, React Three Rapier, Howler.js, TypeScript, WebGL, HTML/SCSS.

Главный приём — Kuwahara-шейдер. Несмотря на сильно обработанный вид, это единственный пасс постпроцессинга. Сцена строится вокруг него, в том числе на этапе моделей в Blender — чтобы видеть итоговый эффект сразу.

Отражающая вода — три шага. MeshReflectorMaterial в низком разрешении (для производительности), кастомный шейдер сверху для деталей и анимации воды, тюнинг освещения.

Reveal Effect. ScrollControls контролирует параметр uProgress, шейдер применён к ScreenQuad. Это компактный способ реализовать разворачивающуюся при скролле интро-сцену.

Концепция: уют, которого не бывает

Wei работает в свободном режиме: не использует Figma и подобные инструменты на личных проектах, идёт от концепта в голове. Susurrus родился как «эхо в сознании»: дом, плавающий на отражающей воде, с Kuwahara-шейдером, наложенным как пост-процессинг — чтобы получить «3D-веб-впечатление как картина».

Интерфейс при этом намеренно прост — фокус на 3D-контенте. В сцене присутствуют два поэта, но смысловое ядро — атмосфера и эмоция, переданные через визуал и звук. Само слово «susurrus» (шёпот, шорох) задаёт тон: слова намеренно невнятны, важнее — настроение.

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

Kuwahara-шейдер: ядро всего проекта

Весь визуальный стиль Susurrus построен на Kuwahara-фильтре. Это единственный пасс постпроцессинга — всё остальное собрано вокруг него. Wei поставил его на этап раньше, чем закончил 3D-модели в Blender: так можно видеть итоговый эффект и подгонять модели под шейдер, а не получить сюрприз в финале.

При исследовании автор нашёл несколько подходов, опираясь в основном на разбор Maxime Heckel о Kuwahara-фильтре и painterly-шейдинге. На основе этих референсов Wei сделал упрощённую реализацию:

• Не использовал TensorPass, чтобы пасс остался простым (хотя он усиливает детализацию).
• Использовал отличающийся подход на vertex-стадии, по сравнению со стандартными реализациями.

Стандартный vertex для Kuwahara обычно выглядит так:

Версия Wei проще:

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

Отражающая вода в три шага

Авторская «грязная» реализация воды:

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

Reveal Effect для интро-сцены

Wei использовал ScrollControls для контроля параметра uProgress, который подаётся в reveal-шейдер. Шейдер применён к ScreenQuad — это удобный способ реализовать эффект «открытия» сцены при скролле.

Звук, физика и адаптивность

Звуковые эффекты. Через react-howler: разные звуковые взаимодействия по hover/click. Эффекты интегрированы с фоновой музыкой, чтобы получился lo-fi-стиль — «картина, которая может петь».

Физика. Главный интерактивный элемент Susurrus — Spawning Bread on Click: щелчок порождает физический объект (хлеб), который падает в сцену. На реализации стоит React Three Rapier.

Адаптивность. Стандартная для автора цель — мобильная совместимость и плавная производительность на mobile и более старых устройствах.

Выводы

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

Для тех, кто работает с Three.js / React Three Fiber, в случае Susurrus есть три прямых заимствования: компактный паттерн ScrollControls + ScreenQuad для reveal-сцен, дешёвая реализация отражающей воды через MeshReflectorMaterial низкого разрешения + кастомный шейдер сверху, и выбор пасса постпроцессинга на старте проекта, а не в финале.

Источник: Susurrus: Crafting a Cozy Watercolor World with Three.js and Shaders — Codrops.

В материале на блоге LogRocket разобран один из самых частых React-паттернов, который в неподходящем контексте оказывается одним из самых дорогих, — передача inline-объектов, массивов и колбэков прямо в месте вызова компонента. Контролируемый эксперимент с 200 memoized строк показывает, как это превращает один keystroke в коммит на 243,9 мс — и как простой рефактор возвращает время до 6 мс.

React.memo сравнивает по ссылке. Внутри React работает Object.is: {padding:16} и {padding:16} — это разные ссылки, значит «изменилось».

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

Цена в живом коде. Эксперимент: 200 memoized строк, поиск, inline style и onAddToCart. После 6 нажатий — счётчик рендеров каждой строки = 14, на keystroke коммит 243,9 мс.

Фикс простой. Статичный объект — в module scope. Динамический колбэк — в useCallback с пустыми зависимостями. После: коммит 6 мс, счётчик рендеров = 2, Why Did You Render молчит.

React Compiler не отменяет понимания. Он автоматизирует много memoization, но useMemo/useCallback остаются escape hatch для случаев, когда нужен точный контроль (например, dependency для Effect).

Как работает bailout у React

React.memo оборачивает компонент в memoization-границу. Когда родитель ререндерится, React не пропускает дочерний автоматически только потому, что он мемоизирован. Вместо этого сравниваются новые пропсы со старыми. Если каждый пропс считается равным — bail out, переиспользуем предыдущий результат. Если хотя бы один не равен — рендер. По умолчанию React сравнивает попропсово через Object.is.

Эта деталь критична, потому что для объектов и функций Object.is — это, по сути, проверка по ссылке:

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

Та же логика объясняет, зачем нужны useCallback и useMemo. По документации React, useCallback кеширует определение функции между рендерами, а useMemo — результат вычисления. Оба помогают только тогда, когда зависимости остаются достаточно стабильными, чтобы React переиспользовал предыдущее значение. Если положить в массив зависимостей нестабильный объект, React видит новую зависимость на каждом рендере и пересчитывает заново.

Это и объясняет, почему баг ощущается запутанным в реальном приложении. Значения «выглядят» неизменными для человека: у style-объекта те же ключи, тело колбэка идентично, config всё ещё говорит то же самое. Но React не сравнивает намерение или структуру — он сравнивает идентичность.

Когда inline-пропсы реально становятся проблемой

Стоит провести границу между теоретической и практической ценой. Inline-колбэк сам по себе — не баг производительности. Если ребёнок дешёвый, частота рендера низкая и memoization-границы вокруг нет, измеримого отрицательного эффекта может вообще не быть. И в документации React, и в гайдах LogRocket по производительности — общее место: оптимизация работает там, где есть реальные узкие места, а не гипотетические.

Проблема начинается, когда сходятся три условия одновременно:

• Родитель ререндерится часто (поиск, скролл, фильтры, анимация, live data).
• Дочерний компонент или поддерево большое — лишняя работа заметна.
• Вы уже добавили memoization и ждёте, что React пропустит работу, когда «ничего важного не изменилось».

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

Контролируемый эксперимент: 200 memoized строк

Чтобы не спорить «плохо или нормально», автор поста собрал контролируемый тест: поисковый список товаров с 200 memoized строками, где каждая строка получает одинаковые логические значения, но новые ссылки на объект и функцию на каждом рендере родителя. Это позволяет напрямую увидеть, делает ли React.memo bail out или всё поддерево ререндерится на каждое нажатие клавиши.

Представьте storefront UI с 200 memoized ProductRow. Родитель — ProductList — хранит searchTerm в state. Каждое нажатие апдейтит state, ререндерит ProductList и снова прогоняет JSX, который мапает отфильтрованные товары. В эксперименте каждая ProductRow обёрнута в memo и помечена whyDidYouRender = true, но получает два inline-пропса в месте вызова:

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

В эксперименте эффект становится виден почти мгновенно. Объект style и колбэк onAddToCart пересоздаются каждый раз, когда ререндерится ProductList, поэтому memo-обёртка видит изменённые пропсы для каждой строки на каждом нажатии. Счётчик рендеров делает это конкретным: после шести нажатий каждая видимая строка показывает Renders: 14. React Profiler затем показывает рантайм-цену ошибки: одно нажатие порождает коммит, в котором ProductList занимает 243,9 мс и все 200 row-fibers светятся в flame-графе.

Здесь React Developer Tools отрабатывают по полной. По официальной документации, React DevTools позволяют инспектировать компоненты, редактировать пропсы и state, а также находить проблемы производительности. Профайлер также доступен программно через <Profiler>, но интерактивный вид DevTools обычно используется командами для отладки.

Why Did You Render делает корневую причину ещё нагляднее. Пакет модифицирует React и сообщает о потенциально избегаемых ререндерах. В этом примере он рапортует props.style как «different objects that are equal by value» и props.onAddToCart как «different functions with the same name» — ровно тот референциальный мисматч, который мы и ожидаем. Это диагностический инструмент только для разработки, не для прода, но крайне эффективный для выявления этого класса багов.

Рефакторинг, который реально решает проблему

Чтобы остановить каскад рендеров, нужны стабильные ссылки. Концептуально фикс прост: значения, которые не меняются, не должны пересоздаваться во время рендера; колбэки, которым нужно жить через рендеры, должны быть memoized, когда ребёнок зависит от референциальной стабильности.

Вынос ROW_STYLE в module scope решает проблему на самом дешёвом уровне: React никогда не видит новую ссылку на объект, потому что он создаётся один раз вне компонента. Использование useCallback для handleAddToCart даёт ребёнку стабильную ссылку на функцию между рендерами, пока массив зависимостей не меняется. Это и есть тот случай, для которого React документирует useCallback при передаче функций в мемоизированных детей.

В эксперименте стабилизация ссылок восстанавливает bail-out. Измеренный результат впечатляет: ProductList падает с 243,9 мс до 6 мс, бейджи рендеров остаются на 2 сколько ни печатай, и Why Did You Render замолкает — избегаемых референциальных мисматчей больше нет.

Когда стабилизировать ссылки, а когда — нет

Это часть, которая часто теряется в дискуссиях про производительность. Урок не «никогда не используй inline-объекты» и не «оборачивай всё в useCallback». Урок: memoization — это контракт. Если ребёнок полагается на референциальное равенство, чтобы пропустить работу, родитель обязан этот контракт уважать и передавать стабильные ссылки.

Но это не значит, что каждому компоненту нужна агрессивная мемоизация. Современные рекомендации React всё ещё трактуют memoization как точечную оптимизацию, а не дефолтный стиль. Если рендер дешёвый, поддерево маленькое или ребёнок не memoized, стабилизация ссылок может добавить сложности без реальной выгоды. Поэтому большинство гайдов по React performance, включая обзоры LogRocket, акцентируют профилировку прежде, чем механически оптимизировать.

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

Меняет ли это React Compiler

Один актуальный нюанс — React Compiler. Документация описывает его как стабильный билд-тайм инструмент, который автоматически оптимизирует React-приложения и по умолчанию мемоизирует код на основе анализа и эвристик. Это уменьшает потребность в ручных useMemo, useCallback и React.memo, особенно в новом коде.

Но это не делает референциальную стабильность нерелевантной. Документация также отмечает, что useMemo и useCallback остаются полезными как escape hatch для случаев, когда разработчику нужен точный контроль — например, чтобы держать memoized-значение стабильным как зависимость для Effect. Так что даже в кодовых базах, переходящих на React Compiler, всё равно полезно понимать, как нестабильные ссылки влияют на ререндеры, результаты профайлера и кейсы, где ручной контроль ещё нужен.

Итог

Inline-объекты и inline-колбэки — не плохой React-код по умолчанию. Чаще всего это просто обычные JavaScript-выражения внутри JSX. Проблема появляется, когда они пересекают memoization-границу и вы ждёте, что React воспримет «то же значение» как «тот же пропс». По умолчанию React сравнивает пропсы и зависимости хуков через Object.is, поэтому для объектов и функций новой ссылки достаточно, чтобы React счёл значение изменившимся.

Этот паттерн заслуживает большего внимания, чем обычно получает. Это не пустяковая микрооптимизация. Это один из самых простых способов случайно обнулить React.memo — особенно в фильтруемых списках, дашбордах, search-heavy UI и компонентных деревьях с дорогими потомками. Код выглядит чистым, приложение работает, но оптимизация, на которую вы рассчитывали, исчезает.

Практический вывод для команд, строящих быстрые React-интерфейсы: профилируй сначала. Если memoized поддерево всё ещё ререндерится слишком часто — проверь пропсы прежде, чем винить React. Перенеси статичные объекты из render-пути. Мемоизируйте колбэки только тогда, когда ребёнок реально выигрывает. Используй React DevTools и Why Did You Render, чтобы подтвердить, что именно изменилось и почему. Делай это последовательно — и React.memo перестанет быть декоративным куском кода и начнёт делать свою работу.

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

Я из поколения десктоп-софта. От Windows 95 до Windows 7 я рос на преимущественно офлайн-приложениях, которые управлялись мышью и клавиатурой — задолго до планшетов и смартфонов. В последнее время я скучаю по одной конкретной части той эпохи: по консистентности дизайна. В этом эссе я хочу рассказать про идиоматический дизайн, подчеркнуть важность гомогенных интерфейсов и предложить мысль, что мы потеряли что-то важное.

• Идиоматический дизайн — это набор настолько распространённых решений, что и пользователи, и разработчики применяют их «не задумываясь». Чекбокс «Запомнить меня» — каноничный пример: никто не делает выпадающий список или текстовое поле для этого вопроса.
• Десктоп-эра (Windows 95–7) держалась на гомогенных интерфейсах: File / Edit / View, подчёркнутые буквы для шорткатов вроде Alt + F, статус-бар с состоянием, слова вместо иконок. Идиомы диктовали ОС и её GUI-библиотеки.
• Веб-эра — это эра гетерогенных интерфейсов. Figma и Linear — два лучших энтерпрайз-инструмента сегодня — не разделяют ни одной иконки и ни одного шортката. Даже внутри Google: Gmail, GSuites и Google Docs — три разных опыта.
• Причины разрушения идиом: переход на мобильные (паттерны для тач-экрана пришлось переизобретать), и то, что современный фронтенд пишут не на голом HTML, а на React + npm-пакетах, где идиомы теряются на каждой итерации.
• Apple — главный выживший пример идиоматического дизайна в наше время. Эффект «it just works» строится на том, что iOS навязывает третьим приложениям свои шрифты, кнопки, жесты. То же делает Substack для авторов: ноль настроек, всегда выглядит одинаково.
• Практический вывод для разработчика: следовать HTML/CSS-идиомам, не переизобретать `` через React, не ломать back-button браузера, предпочитать слова иконкам, и понятность — красоте.

Идиомы дизайна

Допустим, вы заходите на сайт, и он спрашивает: «вы хотите остаться залогиненным?». Есть множество способов задать этот вопрос: текстовое поле, в которое можно ввести «да» или «нет»; выпадающий список с вариантами «Запомнить меня» и «Выйти при закрытии окна». Но в реальности это всегда чекбокс. Почему?

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

Гомогенные интерфейсы

Чекбокс — это ещё и часть интерфейса. Через него вы взаимодействуете с системой и вводите данные. Интерфейс тем лучше, чем меньше думанья он требует: будь то руль автомобиля или онлайн-форма — если на разбирательство уходит хоть какое-то время, это плохо. Когда вы взаимодействуете со множеством вещей, вы хотите гомогенных интерфейсов с консистентным опытом. Если вы выучили, что Cmd + C — это «копировать», вы хотите, чтобы это работало везде. Никто не хочет помнить, что в одних случаях нужно Ctrl + Shift + C, а в других правый клик → «копировать».

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

Эра десктоп-софта

Для контраста: одной из сильных сторон десктоп-эры была высокая консистентность интерфейсов через идиомы дизайна. Посмотрите на типичный скриншот из Windows 2000 — Microsoft Word.

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

• Структура меню «Файл / Правка / Вид…» была стандартной. В Adobe Photoshop или Microsoft Excel — без разницы, вы знали, что «Сохранить» лежит в «Файле», «Отменить» в «Правке», «Полный экран» в «Виде» и так далее.
• Меню навигируется с клавиатуры. У каждого пункта есть подчёркнутая буква: F в File, N в New. Это шорткаты. Нажимаете Alt + F, открывается меню «Файл», нажимаете N — создаётся новый файл. И мощным пользователям удобно, и шорткаты легко учить.
• Статус-бар внизу показывает всё про текущее состояние: страницу, столбец, количество слов, идёт ли запись правок, в каком вы режиме (вставки или замены) и так далее.
• Пункты меню подписаны словами. Слова, не иконки, — основной интерфейс к действиям. Иконки используются только там, где смысл очевиден. Весь интерфейс не оставляет места для воображения. На скриншоте нет «интересно, а что эта кнопка делает?» — вы знаете, как этим пользоваться, даже если никогда раньше не пользовались.

Возможно, вы не знаете, что значат метки REC, TRK, OVR в статус-баре. Тогда вам помог бы ещё один стандартный паттерн: всплывающие подсказки при наведении мыши, которые объясняют, что эта штука делает.

Что критично — эти идиомы дизайна использовались не только в Microsoft Word, а вообще во всей экосистеме Windows. Посмотрите на экран выхода из Windows XP. Каждая кнопка визуально явно кнопка и подписана прямо тем, что она делает. У каждой подчёркнутая буква для шортката. Разве не приятно?

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

Стоит упомянуть, что последние десятилетия Microsoft вместе с релизами Windows публиковала несколько-сотен-страничные жёстко предписывающие гайды по тому, как делать идиоматические приложения. Один из недавних примеров — Windows Apps Design.

Эра браузерного софта

Эра браузерного софта — это эра гетерогенных интерфейсов. Возьмите два моих любимых веб-приложения: Figma и Linear.

Я намеренно беру утилитарный энтерпрайз-софт и не сравниваю его с Facebook, Twitter и подобными — это были бы яблоки и апельсины.

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

Мы в эпохе индивидуально хорошо сделанных и полезных веб-приложений, и все они уникальны. Даже в продуктах одной и той же компании опыт гетерогенный: пользоваться Gmail — это совсем не то же самое, что пользоваться GSuites, и совсем не то же самое, что Google Docs. В сумме это очень фрустрирует. Отсутствие гомогенных интерфейсов означает, что я провожу большую часть своего цифрового времени не в продуктивном потоке, а тыкая по экрану и спрашивая себя: «можно ли по этому кликнуть? откроется ли это в новой вкладке? сработает ли кнопка „назад" в браузере?». Жуть.

Эта негомогенность — по двум причинам.

Переход на мобильные

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

Современный фронтенд-разработчик живёт в культуре копирования и переиспользования модульных компонентов, поэтому копировать-вставлять плохие паттерны и закреплять их — очень легко. После 10+ лет такого подхода поколение за поколением фронтендеров деградировало качество UI/UX-дизайна.

Недостаточно идиом за пределами HTML

Если бы все следовали одним и тем же идиомам, интерфейсы бы выглядели довольно консистентно. В ранние годы интернета сильные идиомы были: гиперссылки на другие страницы — синие подчёркнутые, фиолетовые если уже посещали. Прекрасно. Сегодня каждый сайт — это собственная угадайка о том, как стилизованы элементы интерфейса. Это ссылка? Может быть.

Может удивлять, что современный веб-дизайн настолько неидиоматичен — ведь стандарты HTML/CSS очень предписывающие. Проблема в том, что хотя стандарты для написания HTML существуют, его никто не пишет. Все пишут React в TypeScript или последний фреймворк. Импортируют бесчисленные npm-пакеты. Всё это проходит через сложный билд-процесс и выдаёт что-то, что бежит в браузере.

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

Фронтенд-разработчики не делают ничего неправильного. Браузеры сегодня очень мощные и предлагают универсальные API, которые позволяют делать почти всё, если подходить креативно. Например, Figma не следует ни одной HTML-идиоме, потому что в ней нет HTML. Она написана на WebAssembly; команда на cutting edge-реализации десктоп-стиля софта в браузере. Конечно, это ломает HTML-as-document-модель веб-страницы. Кнопка «назад» в браузере, шорткаты и так далее идут лесом, пока заново выстраивается парадигма взаимодействия человека и компьютера.

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

Хуже того: даже на техническом уровне правильные идиомы часто пропускают разработчики, которые гонят к финишной черте. Я видел в open source-кодовых базах <span> с обработчиком onclick вместо тега <a>. Это хаос, и это ломает скрин-ридеры и другие средства доступности.

Успех идиоматического дизайна

И всё же некоторые из самых успешных продуктовых организаций сегодня агрессивно навязывают свои идиомы дизайна и достигают какой-то гомогенности интерфейсов.

Apple — отличный пример. Мы говорили про Microsoft прошлого, но Apple сегодня двигает резко бескомпромиссную дизайн-систему. Общая библиотека шрифтов, кнопок, цветов и её консистентность через все нативные приложения и устройства Apple создали мощный эффект подражания для сторонних приложений. Даже когда вы пользуетесь сторонним приложением на iPhone, взаимодействие через клавиатуру, pinch-to-zoom и так далее контролируется iOS. Это большая часть эффекта Apple «оно просто работает». Сильный, со вкусом сделанный, идиоматический дизайн — в ядре успеха Apple.

Что интересно про «оно просто работает»-эффект — он заставляет пользователей доверять дефолтам и избегать кастомизации. Похожая динамика на платформах вроде Substack, где у меня как у автора нет возможности выбрать шрифт или даже подчеркнуть текст. Но ограничивающие дефолты выставлены со вкусом, и это отлично работает. Дизайн-принципы Substack и Apple набирают распространение по мере успеха этих продуктов: дизайнеры смотрят на них как на удачные примеры. Эти решения становятся идиомами через две вещи: (1) люди сходятся на них как на хорошем дизайне, и (2) частоту использования в сообществе.

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

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

1. Изучайте и следуйте идиомам HTML/CSS, когда возможно. Например, ссылка должна быть подчёркнутой, цветной, с курсором-пальцем при наведении и написана как тег <a>.
2. Избегайте JavaScript-переизобретений базовых HTML-элементов: например, React-компонент Button вместо стилизованного <button>.
3. Изучайте и следуйте идиомам браузера, когда возможно. Кнопка «назад» должна всегда работать. Копирование-вставка URL должны приводить пользователя к тому же интерфейсу. Ctrl+Click по навигационному элементу должен открывать его в новой вкладке.
4. Если отклоняетесь от общих идиом — убедитесь, что ваш дизайн полностью внутренне консистентен и хотя бы «идиоматичен» внутри вашей организации.
5. Предпочитайте слова иконкам. Используйте только иконки, понятные универсально.
6. Если сомневаетесь — делайте визуальные элементы очевидными. Никогда не должно возникать вопроса, кнопка это или таб.
7. Предпочитайте то, что легко понять, тому, что визуально красиво.
8. Если зашли в тупик — обратитесь к двум типам ресурсов: лучшим сайтам с дизайном, которые вы знаете, и книгам по интерфейсному дизайну прошлых десятилетий. Большинство проблем интерфейсного дизайна сегодня — не новые, а повторы исторических, у которых есть решённые аналоги в прошлом.

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

От переводчика

Эссе написано в 2023 году, но за два с половиной года консистентности в вебе не прибавилось — скорее наоборот. ИИ-сгенерированные интерфейсы и v0/Cursor-style фронтенд-генерация только увеличили число способов сделать одно и то же: каждый промпт даёт чуть новый <Button> с уникальным API.

Из практически применимого для российских команд: совет «следуйте HTML-идиомам» снижает не только риск сломать UX, но и число npm-зависимостей — а значит, и риск supply-chain атак, и порог входа для новых разработчиков. Особенно ценно, когда команда меняется быстрее, чем проект.

Оригинал эссе: essays.johnloeber.com. Сайт автора: johnloeber.com.

• CSS Studio — визуальный WYSIWYG-редактор, который встраивается в ваш dev-сайт через npm-пакет.
• Вы двигаете padding, шрифты, отступы, анимации руками; изменения через MCP-сервер уходят в Claude Code, Cursor или любой другой агент с MCP-поддержкой.
• Агент правит код по месту: классы в Tailwind-проектах, объект стилей в CSS-in-JS, селектор в стайлшитах. Специальной поддержки Tailwind-токенов пока нет — token-режим в планах.
• Цена: $99 за одно место.

Что это и зачем

Сейчас типичный ИИ-воркфлоу для фронтенда выглядит так: вы открываете сайт в браузере, замечаете кривой отступ, идёте в чат агента и пишете «сделай padding у кнопки-подписки на два пикселя меньше и выровняй по базовой линии». Агент угадывает, какой компонент вы имели в виду, промахивается, вы поправляете. Через десять сообщений нужный padding наконец встал куда надо.

CSS Studio заменяет эту итерацию прямым редактированием. Вы добавляете npm-пакет в dev-сборку, запускаете её, в углу страницы появляется панель редактора. Кликаете на элемент, двигаете ползунки или тянете за точки — padding меняется в реальном времени в браузере. Когда результат нравится, нажимаете «Apply» (или включаете auto-apply). В этот момент подключённый ИИ-агент через MCP получает JSON-патч с описанием изменений и дописывает реальные файлы.

То есть вы получаете WYSIWYG-редактор, но результат приземляется в ваш настоящий код. Что с Tailwind — отдельный вопрос. Специальной интеграции с ним пока нет: визуальная панель показывает вычисленные CSS-значения, а агент уже сам догадывается, как их вернуть в исходник, — вслепую, без понимания Tailwind-токенов. Перри пообещал token/strict-режим с распознаванием Tailwind-классов и CSS-переменных, но это пока план. С CSS-in-JS и обычными стайлшитами проще: агент дотягивается до объекта стилей в компоненте или до нужного селектора в файле.

Как это работает технически

Всё завязано на Model Context Protocol — стандарт от Anthropic, который позволяет агентам подключаться к локальным инструментам (файлы, БД, сервисы) как к плагинам, без кастомной интеграции под каждый. CSS Studio поднимает локальный MCP-сервер рядом с вашим dev-сервером (подружиться с Vite получилось сразу, судя по отзыву разработчика mpeg на HN).

В Claude Code или Cursor вы запускаете команду /studio — и агент начинает слушать MCP-сервер. Когда вы в браузере двигаете слайдер padding, CSS Studio стримит агенту JSON вида «компонент такой-то, свойство такое-то, новое значение — вот такое, плюс информация о viewport и URL». Агент видит текущий контекст проекта, находит нужный файл и вносит правку по правилам кодовой базы.

Перри также упоминает, что для низкой задержки MCP-сервер может использовать Claude Channels — малоизвестную фичу Claude Code для стриминга. В обычном режиме агент периодически опрашивает MCP-сервер; Claude Channels снимают эту задержку.

Что умеет

• Стили — padding, margin, цвета, шрифты, тени, бордеры, flex/grid-настройки через визуальные контролы.
• Текст и контент — прямое редактирование содержимого элементов без захода в файлы.
• Лейаут — добавление и удаление элементов, перестановка.
• Анимации — таймлайн-редактор для motion-эффектов (что логично от автора Motion).
• Breakpoints — редактор понимает, в каком брейкпоинте вы сейчас правите; canvas-режим для параллельного просмотра нескольких вьюпортов Перри дорабатывает прямо сейчас.
• Рисование — инструмент для набросков новых блоков на странице, потом отдаёте агенту на реализацию.

Кому полезно

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

Третий — QA и владельцы агентств, которые собирают десятки маркетинговых сайтов: визуальные правки через браузер с автоматической синхронизацией в код ускоряют финальную полировку. В комментариях на HN несколько человек отдельно отметили, что до этого сами писали похожие инструменты «на коленке» — значит потребность назрела.

Что не так

Цена — $99 за одно место, и комьюнити на HN это обсуждает активно. Сравнивают с Figma (около $160 за место) и с Cursor (те же $20 в месяц). Для команды из пяти человек выходит $495 в год. Перри в комментариях пообещал подумать над ценообразованием, а пока рассчитывает на ранних энтузиастов.

Второе — лендинг. Несколько комментаторов заметили, что сайт продукта для дизайна выглядит «как сгенерированный LLM» — слишком много фиолетового, шаблонная композиция, анимации fade-in. Для инструмента, который продаёт дизайн, это, мягко говоря, неловко. Перри признал и пообещал переделать.

Третье — зависимость от ИИ-агента с MCP. Если вы не сидите на Claude Code / Cursor / Windsurf и не планируете, CSS Studio для вас пока бесполезен: он не генерирует код самостоятельно, а только командует вашим агентом. Отдельная боль для российских разработчиков — оплата: Stripe из РФ не работает, нужна зарубежная карта или сервис-посредник. Зато живое демо на сайте cssstudio.ai доступно без регистрации, попробовать можно.

Что это значит

CSS Studio — один из первых публичных примеров того, как MCP превращается в инструмент «человек рисует, агент кодирует». До этого WYSIWYG-редакторы либо жили в отдельной вселенной (как Figma и Webflow), либо редактировали код напрямую, но теряли контекст проекта. MCP даёт третий путь: визуальный фронтенд + реальный агент с доступом к вашей кодовой базе.

Если такой подход взлетит, ждите аналогичных инструментов для других доменов: визуальный редактор схемы базы данных → агент правит миграции, визуальный редактор API → агент правит OpenAPI и генерирует клиент, визуальный редактор Grafana-дашбордов → агент правит Terraform. Базовая механика одна и та же.

Источники: cssstudio.ai, обсуждение на Hacker News.

Полгода назад я бы посмеялся над таким заголовком. TanStack? Это же ребята, которые делают React Query. Съедают экосистему? Я много лет пользовался React Query, любил его, рекомендовал всем — но воспринимал TanStack как одну библиотеку. Отличную библиотеку, не больше.

Потом я обновил проект в прошлом месяце и заметил кое-что. Я уже использовал TanStack Query, TanStack Router и TanStack Table. TanStack Form начал заменять React Hook Form в новых проектах. А TanStack Start полностью вытеснил мой Next.js-сетап. Я открыл package.json — и почувствовал странное: половина моего стека оказалась TanStack. Не потому что я так планировал, а потому что по одной библиотеке за раз, месяц за месяцем, TanStack просто становился лучшим выбором. И я шёл за лучшим выбором, не задумываясь, куда это меня ведёт.

• TanStack превратился из одной библиотеки (Query) в полноценную платформу из восьми взаимосвязанных продуктов: Query, Router, Table, Form, Start, Store, DB и AI
• По State of React 2026 (~3700 разработчиков) у TanStack Query 68% использования и всего 1% негатива, у Next.js — те же ~80% охвата, но в 17 раз больше негатива
• Главное отличие философии: все библиотеки TanStack headless — они делают логику, а UI и рендеринг остаются за вами
• TanStack Router и TanStack Start дают сквозную типизацию по всему приложению — от search params до server functions
• Реальность: TanStack Start ещё RC, TanStack DB — в бете, TanStack AI — в альфе. На прод сейчас безопасно только Query/Router/Table/Form/Store
• Рекомендация автора: Query ставьте уже сегодня, Router — на новом greenfield-проекте, Start — пока наблюдайте

Что сейчас вообще такое TanStack

Два года назад TanStack означал одно: React Query — лучшая библиотека для фетчинга данных в экосистеме React. Простая, мощная, решала реальную проблему. Сегодня TanStack — это восемь взаимосвязанных библиотек, которые вместе образуют полноценную фронтенд-платформу.

• TanStack Query — заменяет ручной fetch + useEffect. Стабильна, 68% использования
• TanStack Router — заменяет React Router и роутинг Next.js. Стабильна
• TanStack Table — заменяет все табличные библиотеки сразу. Стабильна
• TanStack Form — заменяет React Hook Form. Стабильна
• TanStack Start — заменяет Next.js и Remix. RC, активно растёт
• TanStack Store — заменяет Zustand и Redux. Стабильна
• TanStack DB — заменяет Firebase и Supabase-клиенты. Бета
• TanStack AI — заменяет AI SDK других вендоров. Альфа

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

Момент, который всё изменил

Восемь месяцев назад я дебажил проблему с роутингом в проекте на Next.js. Конкретно — URL search params. Это когда фильтры, пагинация и сортировка живут в URL, чтобы пользователи могли делиться ссылками, а кнопка «Назад» работала правильно.

В Next.js для этого нужно жонглировать тремя хуками:

Работало. Но многословно. И не типобезопасно: searchParams.get('category') возвращает string | null, и TypeScript не знает, какие значения валидны. А потом я увидел, как коллега делает ровно то же самое через TanStack Router:

TypeScript точно знал, какого типа category и page. Он упал бы при компиляции, если бы я попытался установить невалидное значение. Состояние URL и типы TypeScript были в идеальной синхронизации. Я долго смотрел на этот код, потом открыл новую ветку и начал миграцию.

Цифры — State of React 2026

Здесь история перестаёт быть моей личной и становится чем-то большим. Опрос State of React 2026 — более 3700 разработчиков, опубликован в феврале 2026 — дал показательные результаты.

Next.js, который когда-то казался стандартом для фулстек-React, широко используется, но не особо любим: 80% респондентов им пользовались, у 17% — негативное отношение, основные жалобы на избыточную сложность и слишком тесную интеграцию с главным спонсором (Vercel).

А вот цифры по TanStack Query: 68% использования, 42% позитивного отношения, 1% негативного. Один процент негатива у библиотеки, которой пользуется 68% React-разработчиков. Это ненормально хорошие цифры. Для сравнения: у Next.js в 17 раз больше негатива при примерно том же охвате. Экосистема говорит. Большинство просто пока не слушает.

Почему TanStack выигрывает

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

Философия звучит так: владей своим кодом, а не фреймворком. Каждая библиотека TanStack — headless by design, то есть без встроенного UI: она занимается логикой, а вёрстку и стили делаете вы. Нет никакого готового TanStack-компонента, который нужно подгонять под свой дизайн. Нет TanStack-стилей, с которыми нужно воевать. Нет мнения TanStack о том, как должно выглядеть ваше приложение.

Сравните это с Next.js — там ваши <Image>, шрифты, роутинг и серверное поведение контролируются фреймворком. Вы получаете мощь, но платите вендор-лок-ином. «Vendor lock-in, сложные API и слишком много шума в экосистеме Next.js — для меня это no-go», — так сформулировал один из респондентов опроса. Ответ TanStack на эту жалобу — архитектурный: это не фреймворк, а набор строительных блоков. Код — ваш, решения — ваши, а TanStack просто берёт на себя сложные части.

Ключевые библиотеки, которые стоит знать прямо сейчас

1. TanStack Query — вы наверняка уже им пользуетесь

Если вы ещё не используете TanStack Query — остановитесь и поставьте его прямо сейчас: npm i @tanstack/react-query плюс обернуть приложение в QueryClientProvider. Я подожду.

Кеширование, фоновые рефетчи, stale-while-revalidate (показываем старые данные, пока подгружаются свежие), оптимистичные обновления, бесконечный скролл, devtools — всё в комплекте. Это точка входа в экосистему TanStack — именно с Query начинают большинство.

2. TanStack Router — тот, который удивит больше всего

Это библиотека, которая окончательно перетянула меня на сторону TanStack. Полная сквозная типизация по всему слою роутинга — не только пути, но и search params, контекст маршрута, данные лоадеров — всё типизируется от маршрута до компонента.

Если у вас хоть раз был баг из-за того, что useParams() вернул undefined, а TypeScript не предупредил — TanStack Router и есть ответ.

3. TanStack Form — наследник React Hook Form

React Hook Form — отличная библиотека. TanStack Form — это то, чем был бы React Hook Form, если бы его писали сегодня, с TypeScript-first подходом. Никаких строковых register('email') — все имена полей проверяются типами.

4. TanStack Start — альтернатива Next.js, которую никто не ждал

Это самое новое и самое спорное пополнение. TanStack Start — это меньше магии и больше контроля: вы сами решаете, как грузятся данные, где они запускаются и что рендерится. Типобезопасность отличная, и Start прекрасно дружит со всей остальной экосистемой TanStack. Полноценный fullstack-фреймворк поверх TanStack Router — SSR, стриминг, server functions, всё как в Next.js, но без привязки к Vercel и с end-to-end типизацией.

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

5. TanStack DB и AI — будущее, которое строится прямо сейчас

У TanStack есть несколько проектов на ранних стадиях: помимо стабильных Query/Router/Table/Form/Store, в бете — TanStack DB, в альфе — TanStack AI, а ещё есть TanStack CLI со встроенным MCP-сервером (Model Context Protocol) для работы с ИИ-агентами.

TanStack DB — реактивное клиентское хранилище данных: что-то вроде Firebase, но без привязки к вендору. TanStack AI — унифицированный интерфейс к разным ИИ-провайдерам: один и тот же API, независимо от того, дёргаете ли вы Claude, GPT-4 или Gemini. И то, и другое пока не прод — но они показывают, куда движется TanStack. Это уже не библиотеки, это платформа.

Честный контраргумент

Я выставил TanStack серебряной пулей. Это не так. Если ваша команда хорошо знает Redux и React Router, потеря продуктивности на изучение новых инструментов может не окупиться. У Next.js годы боевой эксплуатации на проде. Redux-разработчиков на рынке больше, чем TanStack-разработчиков, — это важно для найма. Если вам нужна скучная и предсказуемая технология, оставайтесь на привычном стеке.

Ещё один момент: если вам нужны React Server Components с полной прод-поддержкой уже сегодня — Next.js всё ещё ответ. И если ваша команда глубоко в Redux, а переход на новое означает месяцы переобучения, — цена, возможно, не оправдана. TanStack — отличный инструмент, но не всегда правильный выбор. Используйте его, когда его сильные стороны совпадают с вашими задачами.

Так стоит ли переходить

Честная рекомендация после шести месяцев жизни в экосистеме TanStack:

• Ставьте Query уже сегодня. Если вы ещё не пользуетесь — это самое выгодное по ROI изменение, которое можно сделать в React-кодбазе. Минимум риска, моментальный эффект, плюс это ворота в понимание философии TanStack
• Попробуйте Router на следующем greenfield-проекте (то есть новом, с чистого листа). Не мигрируйте существующее приложение — ценность яснее всего видна, когда вы стартуете с типобезопасности с первого дня
• Наблюдайте за Start. Он ещё не так стабилен, как Next.js. Но траектория понятна: разработчики, которые изучат его сейчас, получат заметное преимущество, когда он дойдёт до 1.0
• Следите за DB и AI. Оба слишком ранние для прода. Но они показывают амбиции команды TanStack — и, судя по её послужному списку, получатся отлично, когда будут готовы

Что всё это значит

TanStack выигрывает не потому, что маркетит себя лучше Next.js, и не благодаря виральным твитам или докладам на конференциях. Он выигрывает, потому что решает проблему, которая реально болит у React-разработчиков в 2026 году: слишком много магии, слишком много вендор-лок-ина, слишком много сложности, которая живёт не в вашем коде, а в фреймворке.

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

Источник: колонка TanStack is eating React's ecosystem and nobody is talking about it на dev.to. Автор: разработчик harsh2644. Перевод сокращён и адаптирован, авторские мнения сохранены.

Railway — облачная PaaS-платформа (аналог Heroku), которую используют десятки тысяч разработчиков для деплоя приложений. Их собственный фронтенд — дашборд, документация, маркетинговые страницы — работал на Next.js.

• Railway перевёл весь фронтенд с Next.js на Vite + TanStack Start
• Время сборки сократилось с 10+ минут до менее 2 минут
• Это часть тренда: крупные проекты всё чаще уходят с Next.js из-за сложности сборки и несоответствия App Router их архитектуре
• Railway — не первые: с Next.js публично уходили Kent C. Dodds и другие команды

Почему ушли с Next.js

По словам команды Railway, основные проблемы были связаны с временем сборки и сложностью инфраструктуры. Next.js-приложение Railway разрослось до такого масштаба, что каждый билд занимал более 10 минут — это тормозило CI/CD-пайплайн и замедляло итерации.

Дополнительные факторы:

• Несоответствие App Router модели Railway — у них client-first продукт, а App Router ориентирован на server-first подход
• Сложность конфигурации Next.js для нестандартных кейсов — когда приложение выходит за рамки «блога на Vercel», настройка становится нетривиальной
• Размер бандла и время cold start при серверном рендеринге

Что получили

После миграции время сборки упало с 10+ минут до менее 2 — ускорение более чем в 5 раз. Для команды, которая деплоит десятки раз в день, это означает экономию часов ежедневно.

Публикация вызвала бурное обсуждение на Hacker News (206 очков, 188 комментариев). Мнения разделились: одни поддержали решение, другие указали, что проблема не в Next.js, а в архитектуре конкретного приложения.

Часть тренда

Railway — не первые, кто публично уходит с Next.js. За последний год аналогичные решения приняли:

• Kent C. Dodds — публично отказался от Next.js в пользу Remix, который позже влился в React Router 7
• Многие команды переходят на Vite + React или SvelteKit для ускорения сборки

Общая тенденция: Next.js отлично подходит для проектов, которые деплоятся на Vercel и укладываются в стандартные паттерны. Для крупных client-first приложений с нестандартной инфраструктурой издержки фреймворка начинают перевешивать преимущества.

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

React — JavaScript-библиотека для создания пользовательских интерфейсов, разработанная Meta (ранее Facebook). Vue.js — прогрессивный фреймворк для создания UI, созданный Эваном Ю (Evan You). Оба инструмента используют компонентный подход и виртуальный DOM, но различаются в философии, синтаксисе и экосистеме.

— React лидирует по npm-загрузкам (429 млн/мес против 47 млн у Vue) и рынку вакансий

— Vue проще в освоении и имеет более целостную экосистему «из коробки»

— React 19.2 принёс Activity, Performance Tracks и useEffectEvent

— Vue Vapor Mode обещает производительность без виртуального DOM

— Для крупных корпоративных проектов React остаётся безопасным выбором

— Для быстрого старта и небольших команд Vue даёт преимущество в скорости разработки

React в 2026 — что нового

React продолжает эволюционировать. В 2025–2026 годах произошло несколько значимых событий, которые определили направление развития библиотеки.

React 19 и Server Components

React 19 стал самым масштабным обновлением со времён хуков. Server Components (RSC) — компоненты, которые рендерятся на сервере и не увеличивают клиентский бандл — перешли из экспериментального статуса в стабильный. Это позволяет снизить объём JavaScript, отправляемого клиенту, на 30–50% в типичных приложениях.

Ключевые нововведения React 19:

• Actions — встроенная обработка форм с серверными и клиентскими экшенами
• useOptimistic — хук для оптимистичных обновлений UI
• use() — новый хук для чтения промисов и контекста в рендере
• Нативная поддержка метаданных — title, meta, link можно рендерить прямо в компонентах
• Улучшенная поддержка Web Components — полная интеграция с кастомными элементами

React 19.2 и Compiler v1.0

Вышедший в 2026 году React 19.2 добавил экспериментальные фичи: Activity (управление жизненным циклом скрытых компонентов), React Performance Tracks (интеграция с DevTools для профилирования) и useEffectEvent.

Отдельное событие — выход React Compiler v1.0. Компилятор автоматически мемоизирует компоненты, устраняя необходимость ручного использования useMemo, useCallback и React.memo. По данным Meta, это сократило количество ре-рендеров в их приложениях на 40%.

React Foundation и Linux Foundation

В 2025 году React перешёл под управление React Foundation при Linux Foundation. Это означает более открытое управление проектом и снижение зависимости от одной компании. Для разработчиков это сигнал долгосрочной стабильности.

Vue в 2026 — что нового

Vue тоже не стоит на месте. Хотя темп обновлений ниже, чем у React, каждый релиз Vue приносит продуманные и обратно совместимые улучшения.

Vue 3.5 — стабильность и производительность

Вышедший в сентябре 2024 года Vue 3.5 ("Tengen Toppa Gurren Lagann") сфокусирован на внутренних улучшениях производительности. Реактивная система была оптимизирована для более точного отслеживания зависимостей, а потребление памяти снижено на 56% по данным бенчмарков команды Vue.

Ключевые улучшения Vue 3.5:

• useTemplateRef() — типобезопасные ссылки на элементы
• Deferred Teleport — телепортация контента с отложенным рендерингом
• Lazy Hydration — ленивая гидратация для SSR-приложений
• useId() — генерация стабильных уникальных ID для SSR
• Улучшенный watch — deep watch с поддержкой паузы и возобновления

Vapor Mode — будущее без виртуального DOM

Vapor Mode — экспериментальный режим компиляции Vue, который генерирует код без виртуального DOM. Вместо создания виртуального дерева и его сравнения (diffing) Vapor Mode компилирует шаблоны в прямые DOM-операции. Это аналог подхода Svelte, но с сохранением API Vue.

По предварительным бенчмаркам, Vapor Mode показывает прирост производительности в 2–3 раза на операциях обновления. Проект находится в активной разработке на GitHub (2400+ звёзд), но пока не рекомендован для продакшена.

Nuxt 4 — полная переработка

Nuxt 4 вышел в 2025 году и уже добрался до версии 4.4. Это полная переработка мета-фреймворка для Vue с улучшенной архитектурой, нативной поддержкой серверных компонентов и обновлённым Nuxt UI v4. Для Vue-экосистемы Nuxt 4 — это то же, что Next.js для React.

Сравнение по критериям

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

Критерий / React / Vue

Производительность

В стандартных бенчмарках (js-framework-benchmark) React и Vue показывают сопоставимые результаты. React с Compiler v1.0 автоматически оптимизирует ре-рендеры, Vue 3.5 имеет более эффективную реактивную систему. На практике разница в производительности редко становится решающим фактором — оба фреймворка достаточно быстры для подавляющего большинства задач.

Реальная разница появляется в экстремальных сценариях: Vue Vapor Mode (когда выйдет из эксперимента) обещает преимущество за счёт отказа от виртуального DOM, а React Server Components снижают нагрузку на клиент, перенося логику на сервер.

Порог входа

Vue традиционно считается более дружелюбным к новичкам. Однокомпонентные файлы (SFC) с секциями <template>, <script> и <style> интуитивно понятны. Документация Vue — одна из лучших в индустрии.

React требует понимания JSX, хуков и однонаправленного потока данных. С приходом Server Components и Compiler порог входа вырос — нужно разбираться, какие компоненты серверные, а какие клиентские. По данным State of JS 2024, React назвали "избыточно сложным" чаще других фреймворков.

Экосистема

React обладает самой большой экосистемой в мире фронтенда. Next.js, Remix, React Native, тысячи UI-библиотек (Material UI, Ant Design, Chakra UI, shadcn/ui) — для любой задачи найдётся готовое решение. Обратная сторона — проблема выбора: для одной задачи существует десяток конкурирующих библиотек.

Vue предлагает более целостный подход. Официальные решения покрывают большинство потребностей: Vue Router, Pinia (стейт-менеджмент), Nuxt (SSR/SSG), Vuetify и PrimeVue (UI). Меньше выбора, но меньше и головной боли.

Рынок вакансий

По данным npm, React скачивают 429 млн раз в месяц против 47 млн у Vue — разрыв примерно в 9 раз. На GitHub суммарно у React 244 000 звёзд, у Vue — 263 000 (с учётом Vue 2 и Vue 3 репозиториев). Однако звёзды на GitHub не отражают реальное использование в продакшене.

На рынке труда React доминирует. По данным Stack Overflow Developer Survey 2024, React используют на работе значительно чаще, чем Vue. На hh.ru и LinkedIn вакансий с React в 3–4 раза больше, чем с Vue. Это важно для тех, кто строит карьеру.

Размер бандла

Минифицированный и сжатый (gzip) размер:

• React (react + react-dom): ~44 КБ
• Vue 3: ~33 КБ

Vue компактнее на ~25%. С React Server Components часть кода не попадает в клиентский бандл вовсе, что может нивелировать эту разницу. Vue Vapor Mode в будущем обещает ещё меньший размер за счёт tree-shaking рантайма виртуального DOM.

Поддержка TypeScript

Оба фреймворка отлично работают с TypeScript, но подходы различаются.

Vue 3 написан на TypeScript и предоставляет первоклассную типизацию «из коробки». <script setup lang="ts"> в SFC — лаконичный и типобезопасный способ писать компоненты. IDE-поддержка через Volar (теперь часть Vue Language Tools) значительно улучшилась.

React исторически использует .tsx файлы и имеет зрелую систему типов через @types/react. Типизация хуков и контекста может быть многословной, но хорошо документирована. React Compiler v1.0 полностью поддерживает TypeScript.

Когда выбрать React

React — оптимальный выбор в следующих ситуациях:

• Крупный корпоративный проект — максимальная экосистема, проще найти разработчиков
• Нужен React Native — единая кодовая база для веб и мобильных приложений
• Server-side rendering — Next.js с React Server Components даёт лучший в классе SSR
• Большая команда — огромное сообщество, много документации и готовых решений
• Карьерные перспективы — React-вакансий на рынке в 3–4 раза больше
• Сложные интерактивные интерфейсы — дашборды, real-time приложения, графические редакторы

React подходит тем, кто готов инвестировать время в изучение экосистемы и не боится "усталости от выбора" (framework fatigue). Если команда уже знает React — смена на Vue ради смены не имеет смысла.

Когда выбрать Vue

Vue — лучший выбор, когда:

• Быстрый старт проекта — от идеи до прототипа за минимальное время
• Небольшая команда — целостная экосистема снижает время на принятие решений
• Постепенная миграция — Vue можно внедрять по частям в существующий проект
• Обучение фронтенду — низкий порог входа, отличная документация
• Проекты на Laravel/Django/Rails — Vue традиционно хорошо интегрируется с серверными фреймворками
• Китайский рынок — Vue крайне популярен в Китае (Alibaba, Baidu, Xiaomi используют его)

Vue идеально подходит для команд, которые ценят прагматичность и хотят сфокусироваться на продукте, а не на выборе инструментов. Если проект не требует React Native или React-специфичных библиотек — Vue даст результат быстрее.

Выводы

В 2026 году и React, и Vue — зрелые, стабильные инструменты с активным развитием. Спор «что лучше» не имеет универсального ответа — выбор зависит от контекста проекта, команды и задач.

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

Выбирайте React, если вам нужна максимальная экосистема, React Native, Server Components или вы ориентируетесь на рынок труда. Выбирайте Vue, если цените скорость разработки, целостный developer experience и низкий порог входа.

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

По сути 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).

В первой статье про CSS counters мы с вами разобрались, как с ними работать на базовом уровне. Мы изучили основные CSS свойства и функции для работы с ними, а также привели базовые примеры с помощью фреймворка mlut.

В этой статье мы углубим наши познания в области кастомных CSS счётчиков, опираясь на спеки и обзор в MDN. Если конкретнее, то мы изучим принципы наследования счётчиков и их значений, а также разберём парочку примеров. А бонусом мы посмотрим на небольшое расхождение в том, как ведут себя кастомные счётчики в разных браузерах.

Ну что, поехали!

Базово про вложенность

Наивный путь

Думаю, вы хотя бы раз в жизни сталкивались с ситуациями, когда вам приходилось верстать многоуровневые списки. CSS counters позволяют создавать такие списки – давайте научимся этому.

На базовом уровне для этого можно создать новый счётчик с новым именем внутри элемента, где уже задан “родительский счётчик”. Например, если на родительском <ol> мы зададим счётчик parent-counter, то на дочернем `<ol>` можем задать счётчик `child-counter`. Выглядеть это будет так:

А вот такие стили сгенерирует mlut:

А так будет выглядеть результат – в принципе, как мы и ожидали:

Продвинутый путь

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

Существует такое правило:

Если мы создаём счётчик с каким-то именем (далее – дочерний счётчик или вложенный) на данном элементе, а он наследует счётчик с точно таким же именем от родителя (далее – родительский счётчик), то новый счётчик будет вложен в родительский. Тогда функция counter() будет возвращать значение последнего вложенного счётчика с данным именем, а counters() значения всех вложенных счётчиков с таким именем в области видимости элемента.

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

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

Кроме того, мы можем обратить внимание на несколько тонкостей:

– функция counters() действительно отображает значения всех уровней счётчика nested с указанным разделителем;

– свойство `counter-increment` инкрементирует значение наиболее глубоко вложенного счётчика с данным именем, который может видеть наш элемент.

Вложенность и наследование

В этом разделе мы подробно разберём процесс наследования кастомных счётчиков и посмотрим на примерах, как это работает.

Область видимости

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

– все потомки того элемента, в котором этот счётчик был создан;

– все последующие соседи того элемента, в котором счётчик был создан, а также все потомки этих соседей;

– наследование счётчика прерывается на первом элементе-соседе, на котором создаётся счётчик с таким же именем с помощью counter-reset.

Давайте проиллюстрируем эти правила следующим примером:

CSS:

А результат получится такой:

Мы видим, что счётчик inherited был создан на первом элементе <div>, а его дочерние элементы <p> унаследовали его. Также его унаследовали следующие два соседа нашего <div>, но на последнем из них счётчик inherited был переопределён на новый, так что последний <div> из области видимости первого счётчика выпал. Итого, в область видимости счётчика, созданного на первом <div> входят:

– первый и второй элементы <div>;

– дочерние параграфы <p> первого элемента <div>;

– дочерние параграфы второго элемента <div>.

Правила наследования счётчиков

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

Счётчики могут попасть в это множество двумя путями:

– через механизм наследования;

– посредством создания прямо в этом элементе.

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

1. Текущий элемент наследует любой счётчик, который определён ранее на любом родительском элементе.
2. Предположим, что на предыдущем элементе-соседе есть счётчик. Прежде, чем текущий элемент унаследует этот счётчик от соседа, произойдёт проверка: нет ли уже в текущем элементе счётчика с таким именем? Если такого нет, то копия счётчика из предыдущего элемента унаследуется текущим. Если же есть такой, то этого не произойдёт.

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

Всё это мы видим на приведённом выше примере. Давайте я ещё раз покажу его:

Здесь:

1. Div 1 не наследует никакие счётчики.
2. Все <p> внутри Div 1 получили в наследство от своего родителя счётчик, который затем на них инкрементируется и отображается;
3. Div 2 унаследовал счётчик как сосед Div 1, а параграфы <p> внутри Div 2 – как дочерние элементы Div 2;
4. Мы также видим, как наследуется значение счётчика на всех этапах. В частности, из интересного стоит отметить, как Div 1 передаёт значение первому вложенному параграфу <p>, тот передаёт следующему, а вот последний параграф <p> внутри Div 1 передаёт значение уже Div 2. И это всё идеально соответствует правилу, которое гласит, что значение счётчика передаётся от последнего предшествующего соседа в DOM-дереве.

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

Тонкости поведения браузеров

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

CSS:

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

1. создаём в первом элементе <div> счётчик curious с начальным значением 1 и с помощью counters() отображаем значения всех счётчиков c этим именем, которые присутствуют в этом элементе (он только один в данном случае);
2. этот же счётчик наследуется дочерними <p> и следующим соседом <div>.
3. на первом вложенном <p> в каждой из <div> создаётся вложенный счётчик с тем же именем curious.

Теперь вопрос, что здесь будет?

Вариант А: получится правильный вложенный список, где нумерация будет идти следующим образом (1 1.1 1.2 2 2.1 2.2). То есть созданный на первом <p> вложенный счётчик будет наследоваться следующим его соседом, как на картинке ниже:

Вариант Б: получится некорректный вложенный список, где нумерация будет такой (1 1.1 2 3 3.1 4). То есть созданный в первом <p> вложенный счётчик не наследуется его соседями. Здесь можно сослаться на то, что счётчик наследуется от предыдущего соседа только тогда, когда на текущем элементе счётчика с таким именем нет. А на втором <p> уже может быть унаследованный от родителя счётчик curious. Тогда результат должен быть таким:

Вариант В: получится вообще не понятно, что. Ну, например такая нумерация (1 1.1 2 3 3.1 3.2). То есть в первой `` вложенный счётчик из первого `` не унаследуется его соседом, а во второй `` – унаследуется. Совершенно маловероятный вариант, но пусть будет.

Ну что, каков ваш ответ?

А ответ таков: вариант А будет работать в браузерах Firefox и Safari, а вариант Б ни в каких браузерах не реализуется! И что же получается, что для Chromium браузеров остаётся самый удивительный вариант В? Да, так и есть, по крайней мере в версии 143 (в версии 144 это уже исправлено). Можете проверить аналогичную иллюстрацию.

Вот такая вот тонкость имеется в поведении CSS Counters в разных браузерах.

Как это можно объяснить?

Safari и Firefox в данном случае идут вразрез со спецификациями, хотя их поведение более интуитивно понятно для пользователей. На самом деле реализоваться должен вариант Б. Дело в том, что от родительского элемента счётчик наследуют все дочерние, а счётчик, созданный на первом дочернем элементе, наследуется соседями только тогда, когда у них нет счётчика с таким именем.

А вот команда Chromium стремилась реализовать вариант Б, но допустила небольшой баг, который уже исправлен в версии 144.

Заключение

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

Успехов вам в увлекательном пути Frontend-разработки!

Тогда компании нанимали инженеров с запасом, под давлением цифровизации, дешевых денег и страха «остаться позади». По данным Indeed и FRED, пик вакансий пришелся на середину 2022 года. После чего последовал резкий спад, так и не вернувшись до прежнего уровня.

Почему ИИ — удобный, но не главный виновник

ИИ стал публичным оправданием сокращений. Заявление «мы заменяем людей на ИИ» хорошо смотрится в отчетах и перед инвесторами.

На практике же компании сокращали издержки, выравнивали штат и параллельно активнее нанимали за пределами США и Европы, где инженеры стоят дешевле.

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

Как будет выглядеть рынок в 2026 году

Эксперты сходятся во мнении: 2026 год пройдет в режиме «низкого найма — низких увольнений». Массовых сокращений не ожидается, но и бурного роста вакансий не будет. Так выглядит стабилизация рынка.

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

По прогнозу Бюро статистики труда США, число вакансий для разработчиков продолжит расти примерно на 15%. Это медленнее, чем ожидалось раньше, но все еще быстрее большинства профессий.

Почему джунам повезло меньше всего

Самое слабое место рынка — начальные позиции. Количество вакансий для junior-разработчиков упало примерно на 40% по сравнению с допандемийным уровнем.

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

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

Какие навыки реально востребованы

В 2026 году ценятся не языки сами по себе, а связки «язык + область».

Тот же Python чаще всего нужен при работе с ИИ и данными. JavaScript и TypeScript — для фронтенда и fullstack. Go — для бэкенда и инфраструктуры. Java — для enterprise-систем.

Параллельно растет спрос на ИИ- и дата-инженеров, а также специалистов по ИИ-инфраструктуре.

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

Умение создавать сайты — одино из самых востребованных в современном мире. Причем неважно, гуманитарий ты или технарь — сайт может сделать любой. Кроме того, работая над проектом, ты прокачаешь свои знания по информатике. Зачем? Все просто: на ЕГЭ по информатике легче всего получить высокий балл, а значит — серьезно поднять средний балл аттестата и поступить в лучший вуз.

В этой статье мы разберем два способа создать первый сайт, каждый — с пошаговыми инструкциями. Ты можешь выбрать способ, который ближе тебе по духу: самостоятельно написать код (для тех, кто любит логику, контроль и хочет понять, как все устроено изнутри) или создать сайт в конструкторе Tilda (для дизайнеров, гуманитариев или тех, кто хочет сделать и быстро, и красиво). Поехали!

Подготовка инструментов и окружения

Прежде чем приступить к созданию сайта, нужно подготовить инструменты (так веб-разработчики и программисты в целом называют программы, которыми пользуются) и рабочее окружение. Нам понадобятся:

Браузер. Используй Google Chrome или Mozilla Firefox. Эти браузеры имеют полнофункциональные «Инструменты разработчика». Чтобы открыть их, нажми клавишу F12 на клавиатуре. «Инструменты разработчика» позволяют просматривать HTML-код и CSS-стили открытой страницы — функция, полезная не только для отладки своего сайта, но и во время обучения: ты сможешь легко подсмотреть, как устроен фронтенд любого сайта в Интернете.

Для ручной верстки нужен редактор кода VS Code — программа, в которой ты будешь писать и редактировать HTML и CSS. Чтобы установить ее, перейди на официальный сайт code.visualstudio.com. Скачай версию для твоей операционной системы (Windows, macOS, Linux):

Запусти установочный файл и следуй инструкциям мастера установки. Можно оставить все параметры по умолчанию.

Чтобы кодить было проще, установим несколько полезных расширений. Для этого запусти VS Code и нажми на иконку «Extensions» на левой панели или используй сочетание клавиш Ctrl+Shift+X:

В поисковой строке введи название расширения, нажми «Install» и перезагрузи редактор после установки.

Обязательные расширения:

• Live Server от Ritwick Dey. Это расширение запускает локальный сервер и автоматически перезагружает страницу в браузере при сохранении кода. Чтобы использовать его, после написания кода щелкни правой кнопкой мыши по html-файлу и выбери «Open with Live Server».

• Russian Language Pack — для русификации интерфейса.

• Auto Rename Tag. Когда ты меняешь название открывающего HTML-тега, расширение автоматически меняет и закрывающий.

Для верстки вручную важно правильно организовать файлы. Создай новую папку под проект, дай ей понятное имя, например, Проект создание сайта 9 класс. Внутри этой папки создай:

• папку images — для хранения всех изображений сайта;

• папку styles — для хранения файлов со стилями (CSS);

• файл index.html — это главный файл, который браузер открывает по умолчанию; его можно создать и позже, прямо из редактора.

Такая структура является стандартной — она позволяет легко находить нужные файлы и избегать ошибок в путях к ним.

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

Для регистрации нужна электронная почта. После входа ты попадешь в «Личный кабинет»: здесь будут видны все твои проекты. Чтобы создать новый сайт, нажми кнопку «Создать новый сайт».

Для создания сайта на информатике достаточно бесплатного тарифа. Хотя у него есть ограничения: одна страница и адрес сайта вида your-site.tilda.ws — этого полностью хватит для выполнения школьного проекта.

Создание сайта в 9 классе: верстка вручную

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

Шаг 1: Создаем структуру сайта (HTML)

Открой папку проекта в VS Code, для этого в меню выбери File → Open Folder, найди и открой созданную ранее папку проекта:

Создай файл index.html. В левой панели проводника щелкни правой кнопкой мыши по пустому месту, выбери «New File» и введи название index.html:

Открой index.html и создай базовую HTML-структуру. Для этого достаточно ввести ! (восклицательный знак) и нажать Tab — VS Code автоматически создаст базовый шаблон HTML5:

Основные элементы HTML-файла::

• <!DOCTYPE html> — объявление типа документа.
• <html lang="en"> и </html> — между этими тегами находится весь html-код страницы. lang="en" показывает браузеру, что страница на английском, сейчас для нас это не важно, поэтому можешь оставить, как есть.
• <head> и </head> — внутри этих тегов служебная информация.
• <meta charset="UTF-8"> — объявление кодировки UTF-8, нужно, чтобы браузер правильно отображал символы на странице.
• <meta name="viewport" content="width=device-width, initial-scale=1.0"> — показывает, как масштабировать страницу на устройствах с разными экранами.
• <title> и </title> —между этими тегами заголовок вкладки, он же — название твоего проекта.
• <body> и </body> — между этими тегами находится контент, который видят пользователи.

Добавь контент в тег <body>, например, так:

Вот как это выглядит в редакторе:

И в браузере (двойной клик по index.html):

В этом примере есть комментарии. Они находятся между сочетаниями символов <!-- и -->. Браузер не отображает закомментированный текст — это удобно, если нужно оставить в коде пометки на будущее.

Шаг 2: Добавляем стили (CSS)

Создай файл стилей style.css в папке styles.

Подключи стили к HTML — для этого в раздел <head> файла index.html добавь строку кода:

<link rel="stylesheet" href="styles/style.css">

После этого добавь базовые стили в style.css:

Как видишь, в css-файлах тоже есть комментарии, но они находятся между сочетаниями символов /* и */.

Вот как это выглядит в редакторе кода:

Если кликнуть на маленький квадратик с цветом в css-файле в VS Code, то откроется палитра — как в фоторедакторах.

Шаг 3: Тестируем веб-сайт

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

Кстати, ты можешь зайти в «Инструменты разработчика» и менять содержимое страницы и стили. Все изменения будут отображаться на странице в реальном времени, но не сохранятся в файлах.

Также можно использовать расширение Live Server в VS Code: щелкни правой кнопкой мыши на index.html и выбери «Open with Live Server». Сайт откроется на локальном сервере с автоматической перезагрузкой при сохранении изменений.

Для школьного проекта статичного одностраничного веб-сайта достаточно. Чтобы добавить дополнительную страницу, создай HTML-файл в папке проекта и размести на него ссылку в index.html.

Если хочешь создать более сложный сайт — посмотри видеоуроки по ссылке:

Бесплатный онлайн-курс «Уроки веб-программирования для детей

За 7 уроков ты изучишь основы HTML, CSS и даже JavaScript, узнаешь, как создать небольшой интернет-магазин и пользоваться библиотекой jQuery. Такой, более продвинутый, сайт ты сможешь не только представить в качестве школьного задания, но и добавить в резюме, если решишь связать свою жизнь с диджитал-сферой.

Шаг 4: Публикация созданного веб-сайта в Интернете

Если ты хочешь поделиться сайтом в интернете, то мы рекомендуем GitHub Pages. Создай аккаунт на github.com, затем создай новый репозиторий с названием username.github.io (здесь username — твой логин). Загрузи все файлы проекта в репозиторий. Через 5-10 минут сайт будет доступен по адресу https://username.github.io, этой ссылкой ты можешь поделиться с учителем или добавить ее в презентацию проекта.

Создание веб-сайта на Tilda

Теперь перейдем ко второму способу создать сайт для проекта по информатике — с помощью визуального конструктора Tilda. Это метод не требует знаний программирования, главное в нем — скорость и простота реализации.

Шаг 1: Старт и выбор стратегии

В личном кабинете Tilda нажми кнопку «Создать новый сайт», введи любое название, затем выбери «Создать новую страницу». Теперь выбери метод создания сайта для проекта. Есть два варианта — «Пустая страница» и готовые шаблоны:

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

Альтернативный вариант — готовые шаблоны. Используй их, если сайт был нужен «уже вчера». Шаблоны можно изменять и настраивать под свои задачи.

Шаг 2: Сборка страницы из блоков

В левой панели интерфейса расположены все доступные блоки. Для добавления блока перетащи его в рабочую область.

Основные типы блоков: заголовок, текст, изображение, кнопка.

Заголовок:

Изменить текст можно двойным щелчком мыши, а настроить шрифт, размер и цвет — в панели параметров справа.

Текст:

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

Изображение:

Кнопка:

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

Шаг 3: Настройка единого стиля

В верхней панели управления нажми на «Мой проект» и затем на «Настройки сайта». Что нужно сделать:

• выбери основные шрифты для заголовков и текста;

• определи цветовую палитру: основные цвета текста и фона, дополнительные цвета.

Эти настройки нужны, чтобы дизайн всех элементов сайта был единообразным.

Шаг 4: Публикация сайта

Нажми оранжевую кнопку «Опубликовать» в правом верхнем углу страницы. Сайт станет доступен в Интернете сразу после публикации. Ссылку можно отправлять учителю и одноклассникам для просмотра проекта.

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

А что дальше? От школьного проекта — к уровню PRO

Итак, твой сайт готов. Это важный первый шаг. Но возможности веб-дизайна и веб-разработки гораздо шире. Посмотри, какие проекты создают другие школьники! Может быть они вдохновят тебя на более детальную работу над своим сайтом ;)

• Сайт интернет-магазина. Это полнофункциональный сайт с возможностью регистрации, личным кабинетом, каталогом товаров и корзиной.

• Адаптивный сайт-органайзер со встроенными офисными функциями: блокнот, калькулятор, напоминания.

• Веб-сайт магазина музыкальных пластинок.

Эти проекты объединяет одно — при создании сайтов ребята использовали профессиональные технологии и подходы:

• JavaScript — для интерактивных элементов;
• фреймворки — для разработки сложных интерфейсов;
• backend-разработка — для работы с данными и пользователями,
• базы данных — для хранения информации,
• API — для интеграции с внешними сервисами.

Хочешь выйти на профессиональный уровень? Тогда тебе на курсы программирования и веб-разработки. На них ты:

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

А здесь лучшие курсы, которые тебе помогут:

• Создание сайтов на языках HTML, CSS, JavaScript
• Fullstack-разработчик для подростков 14-17 лет

Подведем итоги: вопрос-ответ

• Смогу ли я создать сайт в 9 классе, если не разбираюсь в информатике?

Да, конечно. Конструктор Tilda создан специально для тех, у кого нет технической подготовки. А если ты выберешь путь программирования — многие курсы рассчитаны на обучение с абсолютного нуля: ты начнешь с основ и будешь изучать веб-разработку шаг за шагом.

• Сколько времени нужно, чтобы сделать свой сайт без подготовки и специальных знаний?

Создать сайт можно очень быстро. Например, верстка простого сайта на HTML/CSS может занять 2-3 вечера, а проект на Tilda — 4-6 часов интенсивной работы.

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

• Что делать, если я запутался в коде?

Это стандартная ситуация в разработке. Используй ее для развития:

• поищи описания ошибок в поисковиках — большинство проблем уже решены другими разработчиками;
• зарегистрируйся на платформе Stack Overflow — это сообщество разработчиков, где можно найти ответы на конкретные вопросы;
• изучай документацию MDN Web Docs — авторитетный источник по HTML и CSS.
• если ты уже занимаешься на курсах программирования — попроси помощи у преподавателя или других учеников: в нашей школе царит дружелюбная атмосфера и все помогают друг другу!

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFHGg7r8

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

Ментор для фронтендеров

Промпт помогает быстрее изучать незнакомые темы и прокачивать знания через общение с нейросетью как с техническим наставником.

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

Продуктивность и тайм-менеджмент

Набор промптов для работы с личной эффективностью: от постановки целей до борьбы с прокрастинацией. Рекомендуется адаптировать под конкретную профессию и распорядок дня.

Постановка целей по SMART

Коучинг по модели GROW

Оптимизация рабочих процессов

Приоритизация по Эйзенхауэру

Техника Помидора

Борьба с прокрастинацией

Еженедельная рефлексия

Работа с резюме

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

Поиск слабых мест

Акцент на достижениях

Вступление

Усиление опыта

Оформление для ATS

Адаптация под вакансию

Сопроводительное письмо

Сравнение с топами

Обход ATS-систем

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

Этот фрагмент нужно вставить в резюме с уменьшенным размером шрифта и цветом, совпадающим с фоном документа.

Вместо вывода

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

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 и постоянно развиваться.

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

Оказалось, что утечка произошла из-за самой Apple — компания просто забыла отключить sourcemaps в продакшн-сборке сайта.

Что именно утекло

В открытый доступ попали:

• компоненты интерфейса на Svelte и TypeScript,
• исходники модулей API,
• конфиги, константы и хранилища состояния,
• а также логика маршрутизации и региональные страницы (us/iphone/ и др.).

Проект был загружен на GitHub как apps.apple.com, получил тысячи звезд и форков, прежде чем его удалили по жалобе правообладателя — то есть Apple.

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

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

В README автор честно указал, что репозиторий создан «в образовательных целях» и весь код принадлежит Apple Inc. Правда, в конечном итоге это не уберегло его от сноса.

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

Сегодня причислять себя к Senior-грейду без знания основ контейнеризации — неоправданно.

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

Давайте разбираться, что должен знать фронтенд-разработчик про Docker.

Что такое Docker?

Docker — это программа для создания, развёртывания и управления приложениями в контейнерах. Контейнер создаётся на основе образа, который описан в Dockerfile.

Dockerfile — по сути, инструкция для создания контейнера. В нём описывается окружение, зависимости и команды для запуска приложений внутри, например, прокси-сервера или микросервиса авторизации.

Какие проблемы решает Docker во фронтенде?

В небольшом проекте работа с web-приложением сводится к использованию четырёх команд: start, build, test, deploy.

А вот запуск веб-приложения в большом и устоявшемся коммерческом проекте выглядит так:

• Запусти Nginx, чтобы отдать клиент.
• Подними (а перед этим установи) бекенд на Go и кэш на Redis, чтобы заработало API.
• Запусти БД, чтобы были данные.
• Запусти вспомогательные сервисы для API, например, аутентификацию или backoffice.

Без контейнеризации запуск сложного приложения превращается в филиал ада: разработчики тратят время на запуск инфраструктуры, у пользователей MacOS не работает то, что работает у пользователей Ubuntu, а порты Postgres конфликтуют с портами локально поднятого почтового сервера.

Так ноутбук начинает выполнять функцию обогревателя для помещения площадью 40 квадратных метров 🙂

Для решения каких задач фронтенд-разработчики выбирают Docker чаще всего?

На стороне фронтенда Docker чаще всего используют для:

• Запуска и работы web-приложения.
• Запуска инфраструктуры для web-приложения.
• Запуска тестов (создание скриншотов, e2e-тесты).
• Сборка приложения на CI.

Что же должен знать фронтенд-разработчик про Docker?

Основные команды для работы с Docker

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

Базовое управление контейнерами также доступно через интуитивно понятный Docker UI.

Важно: все основные команды имеют полезные аргументы. Полный список аргументов вы можете найти в документации.

Как создать базовый Docker-образ для веб-приложения?

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

Образ стандартного web-приложения выглядит примерно так:

При создании Dockerfile рекомендуем следовать минимальному набору лучших практик:

• Использовать базовые образы, чтобы не нагружать образ лишними модулями.
• Добавлять .dockerignore, чтобы исключать лишние файлы из сборки.
• Не запускать контейнер от root, чтобы снизить риски для безопасности.
• Проверять сторонние образы с помощью docker scan, опять же, чтобы снизить риски для безопасности.

Как отправить образ в Container Registry?

Container Registry — это хранилище для Docker-образов.

Container Registry можно сравнить с Github, только вместо репозиториев — готовые для развёртывания образы.

Для работы с Container Registry есть несколько основных команд:

По тегу latest вы всегда можете получить последнюю версию вашего контейнера.

Популярные Container Registry:

• Docker Hub (публичный, простой и бесплатный для открытых проектов);
• GitHub Container Registry (платный, интегрирован с GitHub);
• Google Container Registry (платный);
• Yandex Container Registry (платный).

Важно: старайтесь подбирать Container Registry под экосистему, в которой будет работать ваше приложение. Это сэкономит много сил и времени.

Как запустить Docker-контейнер локально и на сервере?

Для локального запуска контейнера потребуется пройти простой пайплайн:

Если вы хотите запустить контейнер на удалённом сервере с установленным Docker, то вам потребуется пройти пайплайн посложнее:

Важно: в данном примере мы используем в качестве Container Registry — Docker Hub.

Как подключить фронтенд к бэкенду внутри Docker?

Чтобы не настраивать общение клиента и сервера через порты, хорошая практика — объединять сервисы в рамках единой Docker-сети.

Обычно этой задачей занимается файл-оркестратор docker-compose.yml:

Чтобы поднять весь стэк, нам понадобятся команды:

Ключевые моменты:

• Сервисы в одной сети могут общаться по имени (в примере фронтенд обращается к бэкенду по http://backend:5000);
• depends_on гарантирует порядок запуска, но не ждёт готовности сервиса;
• Для продакшена можно разделить конфигурации на docker-compose.yml и docker-compose.prod.yml.

Бонус: Как управлять контейнерами через UI?

В случае отсутствия опыта контейнеризации у команды разработки, управление контейнерами можно осуществлять через UI (вместо терминала) при помощи Portainer.

Portainer — это легковесная панель управления Docker-контейнерами. Через удобный графический интерфейс он позволяет выполнять операции, которые обычно отправляются через терминал (docker run, docker ps, docker compose up).

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

Portainer не заменяет необходимость знания Docker, но значительно ускоряет и упрощает такие рутинные операции, как развёртывание и мониторинг.

Когда Docker необходим, а когда можно обойтись?

Используйте Docker когда:

• работаете в команде с разными ОС;
• проект имеет сложные внутренние и внешние зависимости;
• нужно обеспечить идентичность разных сред: разработки, тестирования, продакшена;
• работаете с full-stack приложениями, где фронтенд тесно связан с бэкендом.

Без Docker можно обойтись когда:

• работаете над небольшим проектом;
• вся команда использует одинаковое железо и ОС;
• проект не имеет сложных зависимостей;
• нет необходимости в изоляции окружений.

Заключение

В последние годы Docker прочно вошёл в арсенал фронтенд-разработчиков, перестав быть инструментом исключительно для бэкенда и DevOps.

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

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

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

Буду рад каждому, кто подписался ✨

Возможно, вам будет интересно:

Делитесь своими находками и полезными командами для работы с Docker в комментариях!

История: золотой век мейнфреймов и становление цифровой инфраструктуры

В 1960-80-е годы, во время «экономического чуда», Япония массово внедряла компьютеры. Стандартом стали мейнфреймы IBM, а COBOL — идеальным языком для них.

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

Принцип «Работает — не трогай»

Из истории вытекает первая и главная причина живучести COBOL — эффект path dependency (зависимость от предшествующего развития).

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

Из-за этого эффекта инженеры были ограничены в своём выборе. При этом каждый программист знает, что не стоит трогать legacy, которое работает. А чем дольше его не трогать — тем старше и больше оно становится. Чем старше и больше — тем страшнее, дороже и рискованнее его изменять.

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

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

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

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

Экономика: стоимость замены против стоимости поддержки

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

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

Следующий вопрос — экономическая выгода. Руководство компаний справедливо задаётся вопросом: «Какую прибыль принесет нам этот переход?». Чаще всего ответ — «Никакой, мы просто получим систему, которая делает то же самое, но на другом языке». С точки зрения ROI (возврата инвестиций) проекты миграции или модернизации выглядят крайне непривлекательно.

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

Культура: японский консерватизм и системный подход

Экономическая рациональность не существует сама по себе. Она подкрепляется и японской культурой, которая символизирует надёжность, стабильность, долговечность и лояльность.

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

Ещё одна особенность — система пожизненного найма.

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

Такая традиция создала уникальную среду: инженеры, начавшие работать с COBOL в 1980-х, оставались в компаниях до пенсии, накапливая и передавая бесценные знания. Это создавало внутреннюю стабильную экосистему экспертизы.

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

Решение кадрового кризиса: не вопреки, а благодаря

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

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

Крупные корпорации передают поддержку COBOL-систем специализированным IT-гигантам, таким как Fujitsu, NEC, NTT Data, IBM Japan. Внутри этих компаний существуют целые департаменты, которые:

1. Целенаправленно нанимают и обучают молодых инженеров работе с COBOL и мейнфреймами.

2. Предлагают им стабильную карьеру с высокой (из-за низкой конкуренции) зарплатой и социальными гарантиями.

3. Разрабатывают инструменты модернизации: транспайлеры (конвертирующие COBOL в Java, в том числе на базе AI), эмуляторы и платформы для запуска legacy-кода в облаке.

Проблема кадров осознана и решается решается разными путями. Но возможно ли и нужно ли поддерживать COBOL бесконечно?

Есть ли у COBOL преимущества сегодня?

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

Безусловный минус — стоимость поддержки. К 2025 году затраты на поддержку COBOL-решений могли составить до 12 триллионов йен в год или 80 миллиардов долларов, что уже превышает некоторый психологический барьер. Этому прогнозу уже несколько лет, так что сегодня компании стоят перед сложным выбором: вкладываться в модернизацию или продолжать поддержку.

В конечном итоге, живучесть COBOL в Японии — это не признак технологической отсталости, а следствие расчёта, уважения к стабильности и долгосрочной стратегии управления legacy. Эти старые системы — всё ещё ядро национальной цифровой инфраструктуры: дорогое в обслуживании, но надёжное.

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

• Решить, с какого языка/технологии вы хотите начать.
• Решить, на каком ресурсе вы хотите обучаться.
• Выделить время на само программирование.

Звучит просто, однако у вас уйдёт много времени на исследования, чтобы решить, что вам подходит и на каком ресурсе обучаться.

Некоторые люди начинают с относительно низкоуровневого программирования на C и C++. Другие выбирают более традиционный путь, изучая Java или C#. Есть и те, кто начинает с высокоуровневых или скриптовых языков вроде Python, Ruby или JavaScript.

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

Низкоуровневые языки: близко к «железу»

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

Примеры: C (для ОС вроде Linux), C++ (для игр на движке вроде Unreal Engine), Assembler (для оптимизации критических частей кода).

Плюсы:

• Полный контроль: вы решаете, как использовать ресурсы. Так, в C++ можно вручную выделять память для массивов, избегая ненужных копий данных.
• Высокая скорость: прямой доступ к памяти позволяет писать код, который работает быстрее (это важно для работы с играми или серверами).
• Основы основ: такие языки учат, как компьютер работает изнутри, чтобы в будущем ценить удобства других языков. Например, вы узнаёте, почему «утечка памяти» — это проблема.
• Эффективность: низкоуровневые языки мотивируют думать об оптимизации заранее, снижая расход батареи или CPU.
• Компактность: минимальная библиотека, приложения получаются лёгкими (идеально для embedded-систем, как в IoT-устройствах).

Минусы:

• Всё-таки это сложно: рутинные задачи (например, чтение файла) требуют больше кода и внимания к деталям, рискуя ошибками вроде переполненного буфера.
• Ручное управление памятью: можно легко «забыть» освободить память, вызвав утечки или краши. Например, в C нужно использовать malloc/free, иначе программа съест всю RAM.
• Много копипасты: придётся писать шаблонный код, и делать это часто.
• Платформо-зависимость: код для Windows может не работать на Linux без правок.

Среднеуровневые языки: баланс контроля и удобства

Эти языки предлагают готовые инструменты, упрощающие работу, но требуют строгой проверки типов данных. Для их запуска нужна специальная программа (среда выполнения). Они идеальны для приложений, серверов и игр.

Примеры: Java (для Android-приложений), C# (для Unity-игр или .NET-серверов).

Плюсы:

• Автоматическая память: память очищается автоматически благодаря сборщику мусора, что избавляет от ручной работы и снижает вероятность ошибок, вроде утечек памяти в больших проектах. При этом можно получить доступ к низкоуровневым функциям для особых задач, например, через специальные инструменты в Java.
• Богатые библиотеки: готовые инструменты для сетей, GUI или баз данных. Пример: Java’s Spring для веб-серверов.
• Кроссплатформенность: компиляция в байт-код (JVM для Java) позволяет запускать код везде. Например, пишешь на Windows, запускаешь на Linux.
• Безопасность: язык проверяет типы данных перед запуском программы, помогая заранее найти ошибки. Среда выполнения защищает от опасных сбоев, например, от переполненной памяти.
• Масштабируемость: встроенные инструменты для параллельных вычислений позволяют легко создавать программы, которые одновременно выполняют много задач (серверы для тысяч пользователей и т.п.).

Минусы:

• Дополнительная нагрузка от рантайма: Среда выполнения и автоматическая очистка памяти создают дополнительную нагрузку. Сборщик мусора может ненадолго останавливать программу, что заметно в играх или при обработке видео.
• Меньше контроля: абстракции скрывают детали памяти, усложняя оптимизацию (например, в Java сложно избежать боксинга примитивов).
• Повторяющийся код, которого много: приходится писать повторяющийся код и тренировать свою усидчивость, например, для доступа к данным объекта. Кстати, инструменты вроде Lombok могут упростить эту задачу.
• Зависимость от среды: для запуска программ нужна специальная среда (например, JVM для Java), что влияет на размер программ и замедляет их старт.
• Сложность интеграции: подключение кода на других языках, например, на C, требует писать специальные обёртки, что усложняет работу и снижает скорость.

Высокоуровневые языки: удобство и скорость разработки

Эти языки скрывают технические детали, позволяя сосредоточиться на создании логики программы. Подходят для веба, data science или скриптов.

Примеры: Python (для ML), Ruby (для веб-разработки), JavaScript (для фронтенда).

Плюсы:

• Простота: сложные задачи решаются в пару строк. Так, в JS async/await упрощает API-запросы.
• Быстрая разработка: динамическая типизация позволяет быстро писать и тестировать код без необходимости его компиляции.
• Богатые экосистемы: есть библиотеки для всего (к примеру, NumPy для данных в Python).
• Гибкость: легко менять код, идеально для прототипов или стартапов.

Минусы:

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

Чек-лист: как выбрать язык программирования для новичка

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

1. Определите, что вас вдохновляет, и выберите сферу. Подумайте, что вы хотите создавать: сайты, игры, мобильные приложения или серверы. Разные сферы требуют разных языков. Например, для веб-разработки подойдут JavaScript или Python, для мобильных приложений — Java, Kotlin, Swift или Dart, а для игр — C# или C++. Составьте список идей (например, сайт-визитка, игра, аналитика данных) и найдите, какие языки для них используют.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
2. Ищите язык с широким применением. Выбирайте языки, которые используются в разных областях, чтобы легче переключаться между задачами. Например, Kotlin подходит для мобильной разработки, веба и серверов, а C# — для десктоп-приложений, игр (Unity) и бэкенда. Это даёт гибкость и упрощает изучение новых языков в будущем.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
3. Проверьте спрос на рынке труда. Если цель — смена профессии, изучите вакансии на HH.ru или LinkedIn. Введите «junior Python», «junior Java» и сравните, где больше предложений и какие требования. Избегайте языков с низким спросом, если хотите быстро найти работу. Например, Java, Kotlin, Python и JavaScript популярны для найма.
   — Владислав Масунов, Head of Development
4. Опробуйте языки на практике. Напишите простые программы (например, "Hello World" или калькулятор) на нескольких языках, чтобы понять, какой синтаксис вам ближе. Используйте онлайн-редакторы вроде Replit или CodePen. Например, попробуйте TypeScript для веба (он поддерживает типизацию и разные подходы к программированию) или C++ для понимания работы с памятью. Это поможет почувствовать, к чему лежит душа.
   — Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS; Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
5. Выберите язык с хорошей документацией и сообществом. Убедитесь, что у языка много обучающих материалов и активное сообщество. Например, TypeScript имеет богатую документацию и поддержку, что упрощает старт. Проверьте ресурсы вроде LearnPython.org, freeCodeCamp для JavaScript или Telegram-чаты для C++. Это поможет быстрее решать вопросы.
   — Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS
6. Учитывайте сложность и карьерные цели. Для небольших проектов или быстрого старта берите Python или PHP — они проще и подходят для веб-разработки или скриптов. Для сложных задач с высокой нагрузкой (например, серверы или оптимизация) попробуйте C++ или Go. Если цель — работа в крупных компаниях, Java и Kotlin востребованы и часто используются с ИИ-инструментами. Выбирайте, исходя из сложности и ваших амбиций.
   — Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
7. Смотрите на универсальность и переход к другим языкам. Выбирайте язык, который учит основам программирования и упрощает переход к другим. Например, изучение C# может помочь освоить Java, а затем — Android-разработку. TypeScript учит объектно-ориентированному и функциональному программированию, что полезно для разных задач. Это создаёт базу для дальнейшего роста.
   — Аня Жаркова, руководитель мобильной разработки в USETECH; Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS
8. Не гонитесь за гилти плежа. Избегайте языков, которые изучают «для удовольствия» без практического применения. Выбирайте те, которые можно применить в реальных проектах или которые востребованы в индустрии. Например, вместо нишевых языков берите Python, Java или Kotlin: они имеют чёткие сценарии использования.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
9. Практикуйтесь с ИИ-инструментами. Если хотите работать в крупных компаниях, освойте язык, который хорошо сочетается с ИИ-инструментами (например, Go или Java). Практикуйтесь с ИИ-агентами по типу GitHub Copilot для автоматизации задач — это ценится работодателями.
   — Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
10. Составьте план развития. Создайте roadmap: определите, какие проекты хотите делать через 3-6 месяцев (например, мобильное приложение или веб-сервис), и подберите язык под эти цели. Если выбрали C#, начните с десктоп-приложений, затем попробуйте Xamarin для кроссплатформенной разработки. Постепенно добавляйте новые языки, опираясь на первый.
    — Аня Жаркова, руководитель мобильной разработки в USETECH

Если не определились, предлагаем пройти квиз и расставить всё по полочкам:

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

Список разбит по категориям: от браузеров и гейминга до утилит безопасности и инструментов для продуктивности.

Неважно, опытный вы пользователь или новичок — здесь найдётся что-то полезное для каждого.

Браузеры

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

• Большинство пользователей: Chrome, Edge или Safari
• Защита приватности: Firefox, Brave, Ungoogled Chromium
• Опытные пользователи: Vivaldi
• Максимальная анонимность: Tor Browser

Google Chrome

Chrome остаётся самым популярным браузером в мире — и не просто так. Он быстрый, стабильный и отлично интегрируется с экосистемой Google. Огромная библиотека расширений из Chrome Web Store позволяет настроить браузер под любые задачи. Синхронизация между устройствами работает безупречно: вкладки, пароли, закладки и история всегда под рукой.

Минус один, но существенный: Chrome прожорлив. Если у вас открыто больше десятка вкладок, он может съесть несколько гигабайт оперативной памяти. На компьютерах с 8 ГБ RAM и меньше это становится проблемой.

Mozilla Firefox

Firefox — это выбор тех, кто ценит приватность и открытость. Mozilla не зарабатывает на продаже ваших данных, а сам браузер активно развивается сообществом. Встроенные инструменты защиты от трекинга работают из коробки, блокируя рекламные сети и скрипты слежения.

По скорости Firefox не уступает Chrome, а по потреблению памяти даже выигрывает. Библиотека расширений чуть меньше, чем у Chrome, но все основные инструменты доступны.

Microsoft Edge

Edge построен на том же движке Chromium, что и Chrome, но при этом лучше оптимизирован для Windows. Microsoft вложилась в производительность: браузер работает быстро, потребляет меньше ресурсов и отлично интегрируется с системой.

Особенно приятны функции вроде Collections (коллекции вкладок для организации исследований), режим чтения и встроенный скриншотер. Edge поддерживает все расширения Chrome, так что переход безболезненный.

Brave

Brave — это Chrome на стероидах приватности. Браузер блокирует рекламу и трекеры по умолчанию, что делает сёрфинг быстрее и безопаснее. При этом он полностью совместим с расширениями Chrome.

Есть интересная фишка: Brave Rewards позволяет зарабатывать криптовалюту за просмотр приватной рекламы (если захотите её включить). Спорная механика, но как опция — почему нет. Для тех, кто хочет Chrome без Google и с упором на приватность, Brave — отличный выбор.

Safari (только macOS)

Если у вас Mac, Safari заслуживает внимания. Это самый энергоэффективный браузер для macOS: на MacBook он даёт ощутимо больше автономности по сравнению с Chrome или Firefox. Интеграция с экосистемой Apple безупречна: Handoff, синхронизация через iCloud, Reading List, автозаполнение паролей.

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

Ungoogled Chromium

Для ультраосторожных Ungoogled Chromium удаляет всё отслеживание и сервисы Google — но вам придётся настраивать всё самостоятельно, так как в нём нет автообновлений или встроенной синхронизации.

Для максимально осторожных пользователей — это Chrome, из которого убрали всю телеметрию Google, отслеживание и облачные сервисы. Браузер работает, но требует ручной настройки: отсутствуют автоматические обновления и встроенная синхронизация между устройствами.

Tor Browser

Выводя приватность на следующий уровень, Tor Browser маршрутизирует ваш трафик через сеть Tor, анонимизируя ваш IP и многократно шифруя соединение. Он медленнее по задумке, но идеален, если ваш приоритет — максимальная анонимность, а не скорость или удобство.

Vivaldi

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

Arc

Наконец, Arc — когда-то новичок на рынке браузеров, нацеленный на переосмысление UX: замена традиционной панели вкладок на боковую панель, акцент на веб-приложениях, интегрированные разделённые виды и easels для заметок и доски. К сожалению, компания за Arc прекратила разработку, чтобы полностью переключиться на ИИ с новым браузером, который сейчас в закрытой бета-версии.

Управление паролями

• Лучший бесплатный выбор: Bitwarden
• Также отлично: 1Password, Dashlane, KeePass

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

Также не будем забывать о passkeys (ключах доступа). Если говорить практически, можно сказать, что passkeys объединяют концепцию пароля и двухфакторной аутентификации (2FA) в одно плавное действие, но гораздо безопаснее и гораздо менее раздражающе.

Bitwarden

Полностью опенсорсный, зашифрованный и щедрый даже в бесплатной версии. Вы получаете неограниченное количество паролей, синхронизацию между устройствами и приложения для всех платформ. Премиум ($10/год) добавляет безопасный обмен файлами и инструменты 2FA. Также есть доступные семейные и командные планы.

1Password

Премиум-решение с отполированным интерфейсом, сильной кроссплатформенной поддержкой и отличными функциями вроде Travel Mode (режим путешествий) и полной интеграцией passkeys.

Dashlane

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

KeePassXC

Отличная оффлайн-альтернатива, если хотите полного контроля и не против ручной синхронизации (или использования чего-то вроде Syncthing или Dropbox для синхронизации базы данных).

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

Продвинутые утилиты и дополнения к ОС

• Поиск + лаунчеры: Everything или Wox (Windows), Alfred или Raycast (macOS)
• Пакетные менеджеры: WinGet, Homebrew (macOS)
• Для пользователей Windows: PowerToys
• Для пользователей Mac: Rectangle
• История буфера обмена: ClipClip, Flycut (macOS)
• Скриншоты + аннотации: Monosnap

Winget

Официальный менеджер пакетов Microsoft, встроенный в Windows 10 и 11. Работает похоже на Chocolatey, но разработан и поддерживается Microsoft. Homebrew — самый популярный менеджер пакетов для macOS. Позволяет быстро устанавливать, обновлять и управлять приложениями и CLI-инструментами с помощью команд в терминале.

Everything

Что касается поиска, Everything остаётся золотым стандартом сверхбыстрого поиска по именам файлов в Windows. Он индексирует диски за секунды и выдаёт почти мгновенные результаты с минимальной нагрузкой на систему. Если нужен функционал шире базового поиска, Wox использует движок Everything и добавляет мощные возможности лаунчера: поиск файлов, запуск приложений, калькулятор, перевод текста и расширения через плагины. Получается более гибкий опыт в духе Spotlight для Windows.

Command Palette/Alfred/Raycast

В который раз Microsoft не смогла существенно улучшить встроенный поиск Windows, хотя Command Palette в PowerToys даёт неплохой компромисс для тех, кто не хочет ставить сторонние утилиты.

На macOS Alfred по-прежнему главный лаунчер и утилита поиска. Он быстрый, интуитивный и в бесплатной версии включает историю буфера и настраиваемые поиски; расширенная автоматизация и «воркфлоу» доступны в Powerpack.

Тем, кто хочет современную облачно-интегрированную альтернативу с готовыми расширениями и встроенной поддержкой Notion, GitHub и Slack, стоит присмотреться к Raycast — это стильный, дружественный к разработчикам вариант, который стремительно набирает популярность.

Менеджеры буфера обмена

Они позволяют возвращаться к ранее скопированному — тексту, изображениям, ссылкам — и сильно ускоряют рутинные операции.

В Windows встроенная история буфера (Win + V) кое-как выручает, но продвинутым пользователям обычно хочется большего. В числе бесплатных рекомендаций — ClipClip для Windows и Flycut для macOS.

Когда речь о скриншотах и аннотациях, штатные инструменты macOS и Windows заметно выросли. Но многим всё равно удобнее сторонние решения. Нам по-прежнему нравится Monosnap за простоту и возможность мгновенно заливать снимки в облако для шаринга (и это бесплатно).

PowerToys — набор полезных утилит от Microsoft для продвинутых пользователей Windows, повышающих продуктивность и упрощающих рабочие процессы. Среди инструментов: FancyZones для продвинутого раскладывания окон, PowerRename для пакетного переименования, Keyboard Manager для ремапинга клавиш, универсальный color picker и другие.

Rectangle и Magnet — два самых популярных приложения на macOS для закрепления окон: быстрые выравнивание и ресайз по хоткеям или перетаскиванием, примерно как по умолчанию в Windows. Пользователям, пришедшим с Windows и скучающим по системному снапингу, одно из них жизненно необходимо.

Широко используемая альтернатива в Windows — FancyZones (часть PowerToys), предлагающая продвинутое управление окнами: настраиваемые сетки, зоны привязки и поддержку нескольких мониторов — поэтому это фаворит пауэр-пользователей на Windows.

Для рутины и создания проектов

• Бесплатные инструменты: FreeOffice, LibreOffice и WPS Office
• Microsoft Office за единовременную плату $49, Office 2024 — $129
• Заметки: Notion, OneNote, Obsidian
• Бесплатный PDF-редактор: PDFsam
• Почтовые клиенты: Thunderbird, eM Client

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

Microsoft Office остаётся отраслевым стандартом для профессиональной продуктивности. Подписка Microsoft 365 открывает доступ к Word, Excel, PowerPoint, Outlook и включает 1 ТБ облачного хранилища.

Среди бесплатных альтернатив LibreOffice — мощный open-source комплект с сильным сообществом (хотя интерфейс некоторым кажется старомодным). Если нужна внешне более майкрософтовская альтернатива, попробуйте FreeOffice или WPS Office Free — у них хорошая совместимость.

На macOS Pages, Numbers и Keynote предустановлены и более чем достаточны для большинства задач, особенно если вы в экосистеме Apple.

Знания и ведение заметок

Notion стал универсальной платформой организации: заметки, базы данных, to-do, управление проектами, создания совместных рабочих пространств. Если нужны более локальные заметки с синхронизацией между устройствами и поддержкой Markdown, Obsidian — любимец студентов и исследователей.

Для быстрых кроссплатформенных заметок OneNote — крепкий бесплатный вариант от Microsoft. В качестве альтернатив — Simplenote или open-source Joplin.

Если вы занимаетесь академической работой и научными статьями, Zotero — отличный open-source менеджер источников с интеграцией в браузер и совместными коллекциями. Milanote предлагает визуальный подход к заметкам и планированию — идеально для креативных пользователей.

Работа с PDF

Хотя Adobe Acrobat остаётся премиальным редактором PDF, бесплатные альтернативы вроде PDFsam позволяют без усилий объединять, разбивать, редактировать и поворачивать страницы.

Инструменты для дизайна и создания контента

Для дизайна два выделяющихся приложения хорошо дополняют набор продуктивности. Figma Desktop — совместная платформа интерфейс-дизайна, широко используемая UI/UX-дизайнерами и фронтенд-разработчиками. Десктоп-версия работает быстрее, чем браузер, и лучше интегрируется с ОС — это удобно для сложных дизайн-систем и коллаборации в реальном времени.

Canva с интуитивным drag-and-drop превосходно чувствует себя и как десктоп-приложение. Отлично подходит для быстрых графических материалов для соцсетей, маркетинга, постеров и презентаций. Благодаря тысячам шаблонов и совместной работе это фаворит как у профи, так и у новичков.

Почтовые клиенты

Если вы предпочитаете отдельный почтовый клиент, у eM Client много функций, бесплатный — до двух аккаунтов. Mozilla Thunderbird — мощная open-source альтернатива с удобной настраиваемостью, а Mailbird — вариант с упором на продуктивность для тех, кого не пугает подписка.

Инструменты разработчика

• Редакторы кода и текста: VS Code, Cursor, Sublime Text
• Система контроля версий: SourceTree, GitHub Desktop
• Контейнеры: Docker
• Локальные LLM: Ollama
• SFTP, загрузка файлов: WinSCP, Forklift

Для разработчиков Visual Studio Code — безусловный вариант. Бесплатный, лёгкий, но мощный, кроссплатформенный — тысячи расширений покрывают практически любой язык, фреймворк или инструмент. Набирающая популярность альтернатива — Cursor, редактор на базе VS Code с усиленной AI-помощью. Он подходит для связки с LLM: даёт inline-подсказки, генерирует код, рефакторит и позволяет редактировать кодовую базу.

При этом Sublime Text остаётся для скорости и простоты, а Notepad++ — отличный лёгкий редактор для быстрых правок в Windows.

Для Git графические клиенты SourceTree и SmartGit дают понятный интерфейс для управления репозиториями на GitHub, GitLab и не только. GitHub Desktop раньше был простоват и не слишком хорош, но сейчас существенно прибавил — всё ещё простой для работы, но в хорошем смысле.

Для локальных окружений, API-тестирования или терминального воркфлоу инструментов — пруд пруди. Например, Docker Desktop стал стандартом для тех, кто собирает и запускает контейнеризированные приложения на разных платформах. Он упрощает настройку окружений и держит систему чистой.

Ollama позволяет запускать большие языковые модели (LLM) локально с минимальной настройкой. Поддерживает модели вроде LLaMA, Mistral и другие open-weight альтернативы GPT, так что можно работать с ИИ прямо на своём компьютере без отправки данных в облако.

Если вы работаете с облачными хранилищами или SFTP, WinSCP (Windows) и ForkLift (macOS) — отличные клиенты с двухпанельным управлением файлами, синхронизацией и автоматизацией. На Mac также популярны Commander One и Transmit — у них есть встроенные подключения к удалённым и облачным путям.

Безопасность

И Windows, и macOS сегодня предлагают более чем достойную встроенную защиту. С защитой в реальном времени, интеграцией с файерволом и биометрией вроде Windows Hello и Touch ID. Для обычных пользователей, которые соблюдают гигиену безопасности: не скачивают сомнительное ПО, используют менеджеры паролей и включают 2FA — встроенной защиты часто хватает.

Для продвинутых пользователей есть дополнительные варианты.

Отличное первое дополнение — Malwarebytes. Это давний фаворит в обнаружении и удалении malware, adware и руткитов; бесплатная версия по-прежнему хороша для ручных сканов. В платной — защита в реальном времени без ощутимой просадки производительности.

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

Ещё один отличный инструмент — VirusTotal: бесплатный веб-сервис, который проверяет файлы и URL через десятки антивирусных движков. Прежде чем открывать подозрительную загрузку, можно залить файл на VirusTotal.com или использовать их расширение для браузера, чтобы проверять ссылки в реальном времени. Быстро, просто и удобно для осторожных пользователей.

Мы не поклонники установки антивирусов на каждый компьютер и не полностью в курсе, какие сейчас показывают лучшие результаты. Тем не менее, AV-Test давно и регулярно оценивает популярные решения, поэтому советуем смотреть их свежие отчёты. В текущем списке высокооценённых — Avast, BitDefender, ESET и другие; многие из них предлагают бесплатные версии для пробы.

Удалённый доступ и вспомогательные утилиты

RustDesk стал современным, ориентированным на приватность аналогом TeamViewer. Он с открытым исходным кодом, быстрый и работает кроссплатформенно.

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

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

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

Редактирование изображений и видео

• Профессиональный видеомонтаж: DaVinci Resolve
• Простой видеомонтаж: CapCut
• Редакторы изображений: GIMP, PhotoDemon, Pixelmator Pro
• Бесплатное улучшение изображений: Upscayl
• RAW-редактирование: RawTherapee
• Видеоконвертация: HandBrake

Если вам нужен бесплатный инструмент для редактирования изображений, GIMP — один из самых мощных вариантов. Он предоставляет профессиональные возможности, такие как слои, маски и настраиваемые плагины, что делает его идеальным для продвинутых пользователей. Если вы ищете более лёгкий редактор с чистым интерфейсом, стоит обратить внимание на PhotoDemon. Он работает как портативное приложение на Windows, поддерживает слои и редактирование — отличный выбор для быстрых правок или ретуши.

Если вы хотите увеличивать разрешение изображений без потери качества, Upscayl — мощный и бесплатный инструмент для апскейла. Он кроссплатформенный, и по нашим тестам показывает результаты на уровне платных решений вроде Topaz.

Для векторной графики — логотипы, иллюстрации — Inkscape является достойным open-source вариантом с полной поддержкой редактирования SVG. Krita — ещё один отличный бесплатный инструмент, особенно подходящий для цифровой живописи и художественного творчества.

Для редактирования RAW-фотографий, Darktable и RawTherapee — два высококлассных open-source аналога Adobe Lightroom. Их широко используют фотографы, которым нужна работа с изображениями без подписки.

Для простых GIF-анимаций ScreenToGif — удобная утилита, мгновенно записывающая область экрана и экспортирующая в GIF или другие форматы с оверлеями.

Среди платных фоторедакторов Adobe Photoshop остаётся лидером, но для macOS есть Pixelmator Pro — мощное приложение с разовой оплатой, а Affinity Photo предлагает профессиональные возможности по более доступной цене.

Видеомонтаж и конвертация

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

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

Для пользователей macOS iMovie предустановлен и остаётся надёжным вариантом для базовых видео. Если вам нужно просто конвертировать или сжимать видео в современные форматы, HandBrake — проверенное бесплатное решение с поддержкой и вариацией входных и выходных форматов.

Тем, кто ищет топовый профессиональный монтаж, подойдут Adobe Premiere Pro и Final Cut Pro, но там есть дорогая подписка и более высокий порог входа.

Коммуникации и совместная работа

• Для повседневной связи: WhatsApp, Messenger и Zoom, если у вас нет FaceTime
• Для приватности: Signal
• Для работы: Slack, Teams
• Для игр и общения: Discord

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

Для личной переписки WhatsApp и Facebook Messenger остаются самыми массовыми платформами по всему миру. У них есть десктопные клиенты и встроенное сквозное шифрование по умолчанию. Telegram также крайне популярен благодаря синхронизации между устройствами и поддержке крупных чатов. Пользователи Apple продолжают активно использовать iMessage для приватного, шифрованного общения в экосистеме Apple.

Из видеоконференций Zoom остаётся одним из лидеров для групповых звонков и онлайн-ивентов, предлагая локальные записи, демонстрацию экрана и комнаты (breakout rooms). Однако бесплатный тариф ограничивает 1:1 звонки 40 минутами, если не перейти на платный план. Zoom поддерживает сквозное шифрование, но при включении E2EE отключаются некоторые функции вроде облачной записи и комнат.

Google Meet — отличный браузерный аналог без необходимости установки, который заметно улучшился по качеству и удобству использования. Многие компании применяют Meet в ежедневной работе и гибридных форматах. Если ваша организация использует Microsoft 365, скорее всего, вы работаете в Microsoft Teams, который уже заменил Skype на корпоративном уровне. Teams поддерживает большие созвоны, обмен файлами и глубоко интегрирован с Office. Сквозное шифрование доступно, но только для 1:1 звонков.

FaceTime по-прежнему отличный для пользователей Apple, и благодаря новым обновлениям к звонку теперь могут присоединяться и пользователи Android/Windows по ссылке через браузер.

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

Для рабочих коммуникаций Slack и Teams продолжают использоваться в бизнес-среде. Бесплатный тариф Slack ограничивает историю 90 днями и звонки, но остаётся любимцем стартапов и малых команд благодаря интеграциям и ботам. Cisco Webex — также крепкий вариант, особенно популярен в корпоративной среде.

Если вы работаете с креативными командами, сообществами или геймерами, Discord стал явным лидером. Изначально созданный для игр, он превратился в полноценную коллаборативную платформу с текстом, голосом и видео, стримингом экрана и ботами для автоматизации. Многие комьюнити — и даже IT-компании — используют Discord как основной рабочий инструмент.

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

Гейминг, моддинг и стриминг

• Игровые платформы: Steam, Epic Games, EA App, Ubisoft, GOG
• Последние драйверы для GPU: Nvidia GeForce, AMD Radeon, Intel Arc
• Стриминг: OBS Studio

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

Не менее важно установить Epic Games Store. Хотя библиотека меньше, он регулярно раздаёт бесплатные игры, доступные любому с аккаунтом Epic. Это также must-have, если вы играете в Fortnite.

Помните: не все издатели размещают игры на Steam или Epic. Для тайтлов EA понадобится EA App (ранее Origin), для Ubisoft — Ubisoft Connect, для Blizzard/Activision — Battle.net, а GOG Galaxy не только предлагает DRM-free классику, но и может агрегировать игры из других лаунчеров.

Некоторые сверхпопулярные игры распространяются отдельно: Minecraft (через Minecraft.net или Microsoft Store), Roblox, League of Legends и Valorant (через лаунчер Riot Games). Если вы новичок и ищете что-то лёгкое, можно начать с free-to-play тайтлов или классики вроде Brutal Chess или GZDoom.

Если вы играете с геймпадом, Windows поддерживает Xbox-контроллеры из коробки. PlayStation-контроллеры теперь тоже отлично работают: Steam через Steam Input поддерживает DualShock 4 и DualSense практически во всех играх. При необходимости глубокой кастомизации можно использовать DS4Windows, но большинству хватает возможностей Steam.

Если вас интересует моддинг, хороший менеджер модов время в этой жизни:

• Mod Organizer 2 — лучший для RPG Bethesda (Skyrim, Fallout).
• Vortex (от Nexus Mods) — дружелюбный к новичкам и поддерживает широкий перечень игр.

Для записи геймплея или стриминга Nvidia ShadowPlay и AMD Radeon ReLive подходят для простых задач. Но для стриминга с вебкой, сценами, оверлеями или многосценовым продакшеном OBS Studio — безальтернативный лидер. Он бесплатный, open-source и подходит как новичкам, так и про-стримерам (Twitch, YouTube, Kick и т.д.). SignalRGB помогает синхронизировать весь RGB-зоопарк и задавать динамические эффекты.

Мониторинг железа и разгон

• Мониторинг: CPU-Z, HWMonitor, HWiNFO64
• Настройка и разгон: Afterburner, FanControl, ThrottleStop, SignalRGB

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

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

Для более широкого мониторинга HWMonitor показывает температуры, напряжения и скорости вентиляторов в реальном времени. Если нужно ещё глубже и с более гибким интерфейсом — HWiNFO64 считается одним из лучших: поддерживает логирование датчиков и интеграцию с оверлеями (например, RTSS или Rainmeter).

Чтобы проверить хранилище, CrystalDiskMark измеряет скорость чтения/записи SSD и HDD — это помогает понять, соответствует ли диск заявленным характеристикам. Глубже оценить здоровье накопителя можно в Hard Disk Sentinel, который анализирует SMART-данные, оценивает срок службы и предлагает ограниченный ремонт.

С точки зрения охлаждения, всё больше геймеров используют утилиты для настройки вентиляторов. FanControl — актуальный бесплатный фаворит: поддерживает сложные кривые оборотов, привязку к датчикам, и совместим с большинством современных материнских плат. На Mac одной из лучших утилит остаётся Macs Fan Control.

Для настройки видеокарт долгое время стандартом был MSI Afterburner — для разгона, настройки вентиляторов и мониторинга с RTSS-оверлеем. Однако из-за замедления обновлений многие сегодня используют встроенные утилиты от Nvidia (GeForce Experience/Control Panel) и AMD (Adrenalin Software).

Если вы меняете видеокарту или подозреваете проблемы с драйверами, обязательно используйте Display Driver Uninstaller (DDU) — он полностью очищает систему от старых драйверов перед переустановкой.

Если вы играете на ноутбуке или хотите снизить нагрев и повысить автономность, ThrottleStop остаётся одним из лучших инструментов для андервольта CPU и настройки энергопрофилей.

Тем, кто серьёзно подошёл к разгону CPU и GPU, пригодятся фирменные инструменты вроде Intel XTU (для Intel) и AMD Ryzen Master — они дают контроль над частотами, напряжениями и лимитами мощности.

Управление файлами

• Поиск больших файлов: SpaceSniffer, WizTree, Disk Drill (macOS)
• Поиск дубликатов: dupeGuru
• Архивы и ZIP: PeaZip, The Unarchiver
• Очистка: BCUninstaller, CCleaner Portable, AppCleaner (macOS)

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

На macOS — GrandPerspective и Disk Drill предлагают аналогичный функционал, а DaisyDisk — один из самых красивых платных вариантов с молниеносным сканированием.

Если дубликаты засоряют диск, dupeGuru (open-source) отлично справляется с поиском повторяющихся изображений и музыки, даже слегка изменённых.

Для пакетного переименования файлов (например, фоточек с камеры) существует гибкий Bulk Rename Utility. Если нужно что-то попроще: PowerRename из PowerToys (Windows) или встроенный инструмент в Finder (macOS) подходят большинству.

Встроенный File Explorer в Windows недавно получил вкладки и стал удобнее, но Files (open-source) — современная альтернатива с улучшенным UX. Кто-то ещё пользуется Total Commander или Directory Opus, благодаря расширяемости и скриптам, хотя новичкам они кажутся устаревшими. Для просмотра изображений по-прежнему незаменим IrfanView.

Для работы с архивами, если не устраивает встроенный ZIP-менеджер Windows, скачайте 7-Zip или PeaZip. На Mac лучшим бесплатным инструментом остаётся The Unarchiver.

Для очистки системы важно выбирать надёжные утилиты. На Windows, BCUninstaller (Bulk Crap Uninstaller) — один из самых проверенных для удаления программ и их хвостов. BleachBit и Wise Disk Cleaner — безопасные альтернативы CCleaner (лучше использовать Portable-версию, так как стационарная испортила репутацию). На Mac AppCleaner всё ещё любим за полное удаление приложений без мусора.

Если вы организуете большую библиотеку медиа, стоит взглянуть на open-source TagSpaces, позволяющий тегировать файлы локально, без облака.

Облачное хранилище и резервное копирование

• Простая синхронизация: Dropbox, Google Drive
• Фото между устройствами: Apple iCloud, Google Photos
• Приватность: pCloud, Proton Drive, Internxt
• Полные бэкапы: Backblaze, IDrive

Базовое облачное хранилище

Dropbox — один из самых простых в использовании, хотя бесплатных 2 ГБ мало.

Google Drive — 15 ГБ бесплатно, используется Gmail, Docs и Photos. Идеален для Android.

OneDrive — идёт в комплекте с Windows и Microsoft 365. 1 ТБ включён в большинство Office-планов. Хотя по скорости и интерфейсу уступает Dropbox/Google.

iCloud Drive — лучший выбор для пользователей Apple, глубокая интеграция с macOS/iOS. Бесплатно 5 ГБ, далее по планам до 2 ТБ.

Proton Drive — шифрованная альтернатива от создателей ProtonMail.

Фото и видео

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

На Windows мы часто рекомендуем Google Photos, который предлагает аналогичный набор функций и автоматизацию. Для пользователей Android — это стандарт по умолчанию. Да, раньше было безлимитно, теперь фото занимают общее место Google Drive (15 ГБ), которое быстро заканчивается.

Полные бэкапы

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

Backblaze — топ в этой категории: фиксированная цена (~$8/месяц за устройство), безлимитное хранилище, минимум настроек: установил и забыл.

IDrive — более контролируемый вариант, поддерживает несколько устройств, внешние диски и версионность файлов.

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

Профессионалам — Acronis Cyber Protect: клон дисков, анти-вымогатель, гибридное облако.

Для особо чувствительных данных

Если вы храните личные финансовые документы или медицинские сведения, стоит выбрать end-to-end решений.

pCloud предлагает клиентское шифрование (через платный «Crypto»). Даже при взломе аккаунта файлы не расшифруются без ключа.

Proton Drive — аналогичный подход, с прозрачностью open-source.

Прочие полезные инструменты, не вошедшие в другие разделы

Google Earth — для любителей карт и планировки.

qBittorrent — лучший torrent-клиент: чистый, без рекламы, с поиском. Альтернатива — легковесный Transmission или кастомизируемый Deluge.

iMazing — must-have для владельцев iPhone: резервные копии, экспорт медиа, проверка батареи, конвертация HEIC.

AirDroid — аналог для Android: управление файлам, уведомления, SMS с ПК.

Rufus — лидер по созданию загрузочных USB-дисков для Windows/Linux.

Open Shell — возвращает классическое меню «Пуск» в стиле Windows 7.

Stretchly — напоминает делать перерывы — полезно удалёнщикам и фрилансерам.

AutoHotkey — скриптовый движок для Windows: переназначение клавиш, макросы, автоматизация.

VPN: бесплатные — ProtonVPN, Windscribe, TunnelBear (с лимитом). Платные — ProtonVPN, NordVPN.

Calibre — лучшее бесплатное решение для чтения, организации и конвертации e-book (EPUB, MOBI, PDF и др.).

Заключение

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

Несколько советов напоследок:

1. Не захламляйте систему. Устанавливайте только то, что действительно используете. Чем меньше фоновых процессов — тем быстрее работает компьютер.
2. Следите за обновлениями. Большинство программ обновляются автоматически, но некоторые требуют ручного апдейта. Свежие версии — это не только новые функции, но и закрытые уязвимости.
3. Делайте резервные копии. Никакие утилиты не спасут от отказа жёсткого диска. Регулярный бэкап на внешний носитель или в облако — обязательная практика.
4. Экспериментируйте. Попробуйте несколько браузеров, редакторов, плееров. То, что подходит большинству, может не подойти именно вам.
5. Читайте отзывы. Перед установкой незнакомого приложения загляните на форумы или Reddit. Сообщество быстро выявляет проблемы и подводные камни.

Теперь ваш компьютер готов к работе, учёбе, развлечениям — и чему угодно ещё. Главное — не забывайте, что инструменты важны, но ещё важнее то, как вы их используете. Удачи!

Есть веская причина, по которой многие разработчики задумываются, прежде чем использовать в 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() с тем же доверием.

В повседневной работе с 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;
• при очистке и валидации форм.

Если вы уже уверенно используете ||, && и ??, переход на ||=, &&= и ??= будет естественным — здесь всё дело лишь в привычке.

Теперь Bun официально позиционируется как full-stack платформа для фронтенда и бэкенда. И она объединяет сервер, сборщик, менеджер пакетов вместе с тест-раннером в одном инструменте.

В новую версию добавлены десятки ключевых функций: встроенные клиенты для Redis, MySQL, PostgreSQL и SQLite, единый SQL API, улучшенные WebSocket-модули, переработанный тест-раннер и поддержка VSCode Test Explorer.

Full-stack по-умному

Главное новшество — режим full-stack Bun.serve() с поддержкой роутинга, cookies и WebSockets.

Теперь фронтенд и бэкенд можно запускать в одном процессе без проблем с CORS, а приложение собрать в единый исполняемый файл с помощью bun build --compile.

Разработчики могут напрямую импортировать HTML, запускать React-приложения с хот-перезагрузкой и собирать проект одной командой bun init --react. По данным команды, скомпилированные React-приложения в Bun работают до 1,8 раза быстрее, чем через nginx.

Новый SQL и встроенный Redis

Bun 1.3 представил унифицированный Bun.SQL API — теперь один и тот же код работает с MySQL, PostgreSQL, SQLite и MariaDB. Добавлен хелпер sql.array() для работы с массивами в PostgreSQL, улучшена поддержка JSON и Unix-сокетов.

Кроме того, в рантайм встроен Redis-клиент, который поддерживает 66 команд, автоматическое переподключение, очереди сообщений и Pub/Sub. По данным разработчиков, он значительно быстрее ioredis, а поддержка кластеров и Lua-скриптов появится в будущих релизах.

Новые возможности

Среди прочих улучшений — Zstandard-сжатие, нативная поддержка YAML, API для безопасного хранения секретов (Bun.secrets), и серьезный прирост производительности: операции с криптографией ускорены до 400х, установка пакетов — до 2,5х.

Также обновлен менеджер пакетов с интерактивным bun update, изолированными установками и API для проверки безопасности зависимостей.

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

Bun 1.3 превращает экспериментальный рантайм в полноценную платформу для веб-разработки, способную заменить Node.js, Vite и Redis-CLI одновременно.

Разработчики называют релиз «началом новой эпохи», цель которой — сделать Bun лучшим способом писать и развертывать JavaScript-приложения.

Я провела анализ около 70 учебных программ от онлайн-школ. В результате я отобрала 34 наиболее эффективных курса, разбила их на три блока: мой личный топ-10, ещё 16 курсов для углубления в специализацию и 8 бесплатных стартовых уроков для начала обучения.

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

ТОП-10 лучших курсов Vue.js в 2026 году

1. Vue.js от Skillbox — TypeScript и Vue.js через создание трех сложных проектов: каталога фильмов, аудиоплеера и блога с пожизненным доступом к материалам.
2. Vue.js разработчик от OTUS — профессиональное освоение Vue.js с персональным проектом на выбор: панель управления рассылками или модернизация CRM-системы.
3. Фронтенд-разработчик от Skillbox — 17 реальных проектов в портфолио, включая задания от Газпромбанк.Тех с гарантией трудоустройства или возвратом средств.
4. Frontend-разработчик с нуля до Middle от GeekBrains — полный стек технологий от HTML до Vue.js с развитием soft skills и стажировкой у партнеров.
5. Интенсив по программированию от SkillFactory — освоение JavaScript и Vue.js с возможностью очного обучения в Москве и налоговым вычетом.
6. Vue.js от html.academy — интенсивная практика с реальными задачами от IT-компаний и персональной карьерной консультацией.
7. Vue.js от Loftschool — два готовых проекта в портфолио: таск-менеджер и виртуальная пиццерия с поддержкой учебного центра.
8. Vue.js от Level Up — интенсив с созданием SPA-приложения и персональными воркшопами от преподавателя.
9. Vue.js от Learn.Javascript — комбинированное изучение Vue.js и Nuxt.js с проектом приложения доставки еды и онлайн-трансляциями.
10. JavaScript от Специалиста — сертификат на двух языках с еженедельными вебинарами.

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

Онлайн-курсы Vue.js

1. Vue.js | Skillbox

Используйте промокод kursfinder, чтобы получить скидку 50%

Получить скидку >>>

Курс последовательно познакомит вас с TypeScript, а затем с Vue.js. Вы приобретете навыки создания сложных интерактивных веб-приложений и систем, свободных от багов и программных ошибок. В программе — разработка проектов различной сложности: каталоги фильмов, стриминговые сервисы и блог-платформы. Вы освоите написание понятного структурированного кода, что сократит время разработки и тестирования приложений. Полученные знания дополнят вашу базу в верстке и JavaScript, позволив создавать сложные веб-приложения профессионального уровня.

• Стоимость: 99 672 рубля
• Длительность: 2 месяца
• Формат обучения: видеолекции, практика, тренажеры
• Сертификат: сертификат установленного образца

Кому подойдет:

• фронтендерам.

Преимущества:

• портфолио с тремя крупными проектами: каталог фильмов, аудиоплеер и блог;
• решение реальных задач от партнеров курса во время практики;
• пожизненный доступ ко всем материалам и будущим обновлениям;
• персональная обратная связь по всем работам;
• мобильная версия платформы с синхронизацией прогресса;
• беспроцентная рассрочка на оплату;
• налоговый вычет до 13% от стоимости обучения.

Недостатки:

• ограниченное количество мест на курс.

Программа обучения:

• Работа с TypeScript и современными инструментами разработки
• Фундаментальные принципы Vue на практических примерах
• Организация взаимодействия между компонентами
• Управление состоянием страниц и приложений
• Настройка хранилища Pinia для данных
• Методы тестирования Vue-компонентов
• Построение архитектуры и структуры проекта
• Освоение Nuxt и серверного рендеринга
• Анализ различий между Vue 2 и Vue 3
• Дополнительные практические занятия и кейсы

Ознакомиться с полной программой >>>

2. Vue.js разработчик | OTUS

Курс позволяет освоить Vue.js на профессиональном уровне, уделяя внимание архитектуре компонентов, синтаксису фреймворка и принципам реактивности. По завершении обучения вы сможете самостоятельно разрабатывать масштабируемые веб-приложения с нуля. В рамках программы предусмотрена работа над персональным проектом по выбору: создание панели управления для email-рассылок, модернизация CRM-системы или другие практические задачи. Готовый проект пополнит ваше портфолио и станет весомым аргументом при трудоустройстве в IT-сфере.

• Стоимость: 71 000 рублей
• Длительность: 3 месяца
• Формат обучения: онлайн-трансляции, домашние задания, проектная работа, общение с экспертами на вебинарах
• Сертификат: сертификат установленного образца

Кому подойдет:

• новичкам в Vue-разработке;
• JavaScript-разработчикам с навыками CSS и HTML;
• backend-разработчикам, которые хотят освоить fullstack.

Преимущества:

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

Недостатки:

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

Программа обучения:

• Работа Vue с GraphQL
• Подключение WebSockets во Vue-приложениях
• Освоение TypeScript
• Создание десктопных приложений на Electron
• Серверный рендеринг с помощью Nuxt
• Работа с библиотеками в экосистеме Nuxt
• Выбор темы и организация проектной работы
• Реализация интерактивных интерфейсов и Web Components
• Организация кода и паттерны проектирования во Vue

Ознакомиться с полной программой >>>

3. Фронтенд-разработчик | Skillbox

Используйте промокод kursfinder, чтобы получить скидку 60%

Получить скидку >>>

Курс построен на практическом подходе, максимально приближенном к реальной работе. Обучение включает изучение теоретических основ с интерактивными материалами и выполнение 17 проектов для портфолио. Вы освоите полный стек технологий для создания сайтов любой сложности: HTML, CSS, Vue.js, TypeScript, JavaScript. Параллельно с техническими навыками развиваются soft skills: работа в команде, планирование задач, решение нестандартных проблем. После завершения программы карьерные консультанты помогут сформировать портфолио и подготовиться к собеседованиям в компаниях-партнерах.

• Стоимость: 152 150 рублей
• Длительность: 7 месяцев
• Формат обучения: видеоуроки, текстовые материалы, тесты, интерактивные тренажеры, проекты
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• тем, кто хочет построить карьеру в IT;
• тем, кто хочет зарабатывать на фрилансе.

Преимущества:

• интеграция ИИ-инструментов в рабочие процессы разработчика;
• реалистичные проектные задания от компаний «Газпромбанк.Тех», WhiteMark и платформы «Маруся»;
• до 17 завершенных проектов с реальными кейсами партнеров;
• гарантированная помощь в поиске работы или возврат оплаты;
• проверка домашних заданий в течение суток;
• годовое обучение английскому для веб-разработчиков.

Недостатки:

• не выявлено.

Программа обучения:

• Подготовка материалов к публикации
• Верстка интерактивных элементов
• Создание адаптивных стилей
• Верстка адаптивных блоков интерфейса
• Разработка динамических интерфейсных решений
• Подготовка верстки к запуску в продакшен
• Углубленная работа с объектной моделью документа
• Обработка и валидация пользовательского ввода

Ознакомиться с полной программой >>>

4. Frontend-разработчик с нуля до Middle | GeekBrains

Используйте промокод kursfinder, чтобы получить скидку 7%

Получить скидку >>>

Каждое занятие включает практические задания по ключевым направлениям веб-разработки. Через несколько месяцев обучения вы освоите адаптивную верстку на HTML и CSS, создание интерактивных элементов на JavaScript, проектирование макетов в Figma и работу с фреймворком Vue.js. Курс дополнен реальными задачами от компаний-партнеров — вы сможете выбрать подходящие проекты и расширить портфолио новыми работами.

• Стоимость: 142 128 рублей
• Длительность: от 6 месяцев
• Формат обучения: видеоуроки, онлайн-занятия по расписанию, тренажеры, мини-кейсы, персональная обратная связь
• Сертификат: сертификат установленного образца

Кому подойдет:

• людям, которые хотят освоить веб-программирование с нуля;
• IT-специалистам из смежных сфер.

Преимущества:

• персональная консультация менеджера с дополнительной скидкой;
• помощь в поиске работы и стажировки у компаний-партнеров;
• решение реальных задач от «Газпромбанк.Тех»;
• 15+ завершенных проектов с кейсами известных компаний;
• индивидуальные комментарии наставников по домашним заданиям;
• доступ к эксклюзивной базе предложений работы.

Недостатки:

• в базовом тарифе нет помощи наставника и содействия в трудоустройстве.

Программа обучения:

• Принципы работы компьютера и интернета
• Освоение профессионального окружения разработчика
• Эффективное взаимодействие в команде
• Подготовка материалов к публикации
• Создание контентных блоков и гибких компонентов
• Верстка частей страницы и форм ввода
• Разработка responsive-разделов и анимаций
• Подготовка верстки к промышленной эксплуатации
• Основы верстки в React-окружении
• Реализация бизнес-логики в React-компонентах
• Управление состоянием и информацией в приложении

Ознакомиться с полной программой >>>

5. Интенсив по программированию | SkillFactory

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

• Стоимость: от 104 940 рублей
• Длительность: от 4 месяцев
• Формат обучения: видеоуроки, вебинары, тренажеры
• Сертификат: сертификат и диплом

Кому подойдет:

• новичкам без опыта в IT.

Преимущества:

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

Недостатки:

• в базовом тарифе нет курса английского для IT.

Программа обучения:

• Создание веб-страниц
• Изучение JavaScript
• Освоение TypeScript и вспомогательных средств разработки
• Разработка приложений на React.js
• Проектирование приложений и основы бэкенда
• Профессиональное ориентирование и подготовка к трудоустройству

Ознакомиться с полной программой >>>

6. Vue.js | html.academy

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

• Стоимость: от 53 760 рублей
• Длительность: от 3 месяцев
• Формат обучения: теоретические материалы, практические задания, проектные работы
• Сертификат: нет

Кому подойдет:

• IT-специалистам с навыками программирования на JavaScript;
• людям, которые хотят погрузиться в веб-разработку с нуля.

Преимущества:

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

Недостатки:

• отсутствие документа об окончании курса;
• нет возможностей для онлайн-взаимодействия с преподавателем.

Программа обучения:

• Ключевые особенности фреймворка Vue.js
• Начало работы с Vue.js
• Отображение компонентов в интерфейсе
• Создание компонента счетчика
• Реализация функций компонентов
• Конструкции: условная отрисовка и работа со списками
• Типы и обработка взаимодействий
• Способы связи между компонентами
• Использование слотов и динамического контента
• Организация двустороннего обмена данными
• Обзор Vue Test Utils и Vitest
• Разработка через тестирование

Ознакомиться с полной программой >>>

7. Vue.js | Loftschool

Шестинедельная программа развивает компетенции веб-программирования и дополняет портфолио авторским SPA-проектом. В рамках курса изучается Vue.js для одностраничных приложений, продвинутый JavaScript, методики End-to-End и Unit-тестирования, технологии внедрения анимации. Еженедельный план содержит групповые сессии по развитию профессиональных и личностных навыков, цикл персональных воркшопов под руководством преподавателя, активную фазу реализации собственного приложения.

• Стоимость: по запросу
• Длительность: 6 недель
• Формат обучения: теоретические материалы, практические задания, проект, групповая работа с наставниками
• Сертификат: сертификат установленного образца

Кому подойдет:

• опытным IT-специалистам.

Преимущества:

• насыщенный учебный план с упором на практические задания;
• сопровождение наставника от начала обучения до выпуска;
• готовое SPA-приложение с админ-панелью для портфолио;
• безлимитное использование учебных материалов;
• совместная работа с группой над развитием гибких навыков;
• активность в Telegram-чате с преподавателем и студентами;
• помощь в старте профессионального пути в веб-разработке.

Недостатки:

• не указана стоимость.

Программа обучения:

• Представление наставника и участников группы
• Создание макета дипломного проекта с использованием webpack
• Размещение работы на GitHub для проверки наставником
• Доработка верстки для разных устройств
• Подключение данных из админ-панели к лендингу
• Проверка компонентов приложения
• Групповая разработка под руководством наставника
• Финальная корректировка проекта
• Сдача работы на итоговую проверку
• Внесение результатов в дипломные документы

Ознакомиться с полной программой >>>

8. Vue.js | Level Up

Комбинированный курс по Vue.js и Nuxt.js демонстрирует возможности фреймворков для разработки интерфейсов и веб-решений. Вы выполните практикумы, включая проект приложения доставки еды. Доступны онлайн-обучение на платформе или занятия в петербургском образовательном центре. Программа создана специально для начинающих frontend-разработчиков, которые хотят углубить знания в веб-программировании и повысить свою квалификацию.

• Стоимость: 38 990 рублей
• Длительность: 1,5 месяца
• Формат обучения: очные занятия с преподавателем в Санкт-Петербург или онлайн, практические задания
• Сертификат: нет

Кому подойдет:

• новичкам с базовыми знаниями JavaScript;
• IT-разработчикам с опытом.

Преимущества:

• интенсивные занятия под руководством преподавателя;
• глубокое освоение расширенного стека современных инструментов;
• три приложения на Vue.js и одно на Next.js;
• несколько дополнительных мини-приложений для пополнения кейсов;
• ведение курса опытным веб-программистом с многолетней практикой;
• детальный разбор всех практических заданий.

Недостатки:

• нет сертификата;
• фиксированное расписание.

Программа обучения:

• Знакомство с возможностями Vue.js
• Переход к полноценной работе с Vue-cli
• Изучение продвинутых концепций Vue
• Применение роутинга и менеджеров состояний
• Работа с Vuex и Pinia
• Освоение Nuxt.js для production-проектов

Ознакомиться с полной программой >>>

9. Vue.js | Learn.Javascript

Курс посвящен веб-разработке на Vue 3. Вы изучите функционал фреймворка, освоите различные подходы к решению профессиональных задач и реализуете проект. В работе будут применяться как готовые UI-компоненты с изменяемой конфигурацией, так и созданные самостоятельно. Помимо Vue 3, программа включает JavaScript и TypeScript. Консультации по практическим заданиям проходят на еженедельных вебинарах.

• Стоимость: 24 700 рублей
• Длительность: 2 месяца
• Формат обучения: онлайн-занятия, домашние задания, проектные работы
• Сертификат: сертификат на двух языках

Кому подойдет:

• IT-разработчикам со знанием основ программирования на JavaScript, CSS и HTML.

Преимущества:

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

Недостатки:

• редкий набор групп на обучение;
• онлайн-трансляции проводятся в фиксированное время.

Программа обучения:

• Изучение Vue и создание компонентов
• Современные подходы к веб-программированию
• Знакомство с Composables, библиотеками VueUse и Pinia
• Продвинутые техники разработки на Vue
• Принципы реактивного программирования и рендеринга
• Практическое использование inject и provide
• Применение Vue Test Utils и Vitest для тестирования приложений

Ознакомиться с полной программой >>>

10. JavaScript | Специалист

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

• Стоимость: 31 990 рублей
• Длительность: 36 ак.часов
• Формат обучения: очно и онлайн, практика
• Сертификат: сертификат установленного образца

Кому подойдет:

• IT-специалистам, обладающим навыками веб-разработки на JavaScript;
• веб-дизайнерам;
• менеджерам frontend-проектов.

Преимущества:

• несколько форматов обучения – очно, онлайн или по индивидуальному плану;
• 12 академических часов бесплатно для занятий в компьютерных классах образовательного центра;
• дополнительная скидка до 30% при изучении курса в рамках дипломных программ;
• возможность бесплатных занятий в компьютерном классе образовательного центра;
• частый набор групп на очное и онлайн-обучение.

Недостатки:

• небольшое количество практических заданий.

Программа обучения:

• Основы программирования на Vue.js: компоненты, шаблоны, свойства
• Продвинутая работа с компонентами
• Создание анимаций и переходов
• Разработка веб-сайтов и работа с реактивностью

Ознакомиться с полной программой >>>

Еще 16 дополнительных курсов Vue.js

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

• Vue JS от itProger. Оформив подписку на сайте, вы получите полный доступ к курсу по Vue JS, где научитесь создавать компоненты и собирать из них современные веб-сайты. К каждому заданию школа подготовила подробную методичку решения, готовый проект-пример и ответы для самопроверки — это поможет осваивать материал в комфортном темпе и сразу видеть, как должен выглядеть итоговый результат.
• Игра на Vue.js от Stepik. На курсе вы создадите полноценную игру на Vue.js — от проектирования интерфейса до программирования игровой логики на JavaScript, а затем опубликуете готовое приложение в каталоге ВКонтакте; в процессе работы вы разработаете интерактивное приложение, сгенерируете идею через чат-бот и выполните самостоятельный проект для своего портфолио.
• Фреймворк Vue.JS от Frontendblock. Если ваша цель — за 4 недели разобраться во всех возможностях и опциях третьей версии Vue.js, этот экспресс-курс для вас. Все уроки записаны заранее и построены по принципу «теория + практика». Ваши работы будут проверяться, а кураторы предоставят обратную связь. В процессе вы сделаете два проекта разной сложности, и они автоматически пополнят ваше портфолио. Есть три формата участия: можно учиться самостоятельно, с поддержкой куратора или выбрать полностью индивидуальный план.
• Vue.js 3, Vue Router и Pinia от Stepik. В этом курсе вам предстоит освоить Vue, Vue Router и Pinia на практике, создавая два полноценных приложения. Вы разработаете сервис для отображения прогноза погоды и SaaS-платформу для хранения веб-закладок. Курс идеально подойдет тем, кто уже уверенно чувствует себя в основах HTML, CSS и JavaScript и готов погрузиться в изучение одного из самых востребованных фронтенд-фреймворков — Vue.js.
• Frontend разработчик на HTML, CSS и JavaScript от Stepik. Вы изучите HTML, CSS, JavaScript, Figma, Photoshop, VS Code, Emmet, BEM, Bootstrap, Vue, Git, GitHub, Gulp. Также на курсе вам расскажут, как составить портфолио, резюме и взять первый заказ на фрилансе.
• Курс Vue.js от CyberBionic Systematics. Начните свой путь во Vue.js с уверенностью! Этот курс создан для новичков, которые хотят освоить востребованный фреймворк для быстрой и качественной разработки. Вы научитесь работать с формами, компонентами, динамическими данными и анимациями. А после успешного завершения курса получите именной сертификат — ваше первое официальное подтверждение новых навыков.
• Frontend Junior (JavaScript + HTML/CSS + Vue.js) от Stepik. На курсе вы освоите веб-разработку с полного нуля: вы не только изучите основы HTML и CSS, но и глубоко познакомитесь с JavaScript, научитесь работать с популярным фреймворком Vue.js и сможете писать чистый, структурированный код, который ценят в профессиональной среде.
• Vue JS и Vuex - пишем реальный проект с нуля от Udemy. Очень практический курс, который учит веб-разработке на Vue JS и Vuex через создание настоящего проекта. Вы пройдете весь путь — от пустой папки до полностью рабочего приложения. Поймете, как правильно структурировать программу, создавать компоненты и модули, которые легко масштабировать, и дробить код на небольшие, удобные части. В каждом уроке есть доступ к готовому исходному коду, так что вы всегда сможете свериться и найти свои ошибки.
• Vue.js 2.5 Создаем сайт на Vue.JS с Firebase, Vuex и Router от Udemy. Это практическое руководство по созданию сайта с использованием мощной связки технологий: Vue.js, Vuex и Router. Вы научитесь делать динамические и многофункциональные веб-приложения, прокачаете свои навыки в структурировании кода, работе с большими массивами данных и проектировании интерфейсов разной степени сложности. Материал курса разделен на тематические блоки, и каждый включает в себя практическую часть.
• Игра на Vue.js от Udemy. Интересный видеокурс по основам Vue.js, где вы будете создавать настоящую игру. Обучение разделено на две большие части. Первая посвящена интерфейсу: вы с нуля, используя HTML и CSS, сверстаете визуальную часть игры. Во второй части вы займетесь фреймворком Vue.js: напишете структурированный код, добавите алгоритмы и свяжете их с игровой механикой. В финале преподаватель посоветует, куда двигаться дальше и в каком направлении развиваться в IT.
• Vue.js 2 с нуля до про от Tocode. Этот курс поэтапно проведет вас по всем ключевым концепциям и возможностям фреймворка. Он предназначен для подготовки сильных разработчиков и содержит множество практических заданий разного уровня с комментариями и советами от экспертов. В итоге вы получите актуальные знания и навыки для создания динамичных и масштабируемых проектов.
• JavaScript. Программирование от основ до веб-приложений(+Vue.js) от Stepik. На курсе вы освоите JavaScript через решение практических задач, с которыми сталкиваются разработчики в реальной работе. Вам предстоит создать собственное веб-приложение с интерактивными интерфейсами, работой с API и хранением данных, а также познакомиться с React и GitHub. В завершение вы изучите современные фреймворки, включая Vue.js, что позволит вам уверенно работать с самыми востребованными технологиями в веб-разработке.
• Vue Level 2 от Дмитрия Лаврик. Здесь вас ждет полное погружение в разработку одностраничных приложений. Вы не просто изучите теорию, а на практике разберетесь с реальными challenges — от построения архитектуры до обработки серверных ошибок и настройки прав доступа. После каждого занятия — домашняя работа с персональной проверкой автора курса. Всегда можно задать вопрос лично Дмитрию во время живых занятий или в закрытом комьюнити, где собираются такие же увлеченные разработчики.
• Vue.js - Разработка клиентских приложений от Учебного центра «Шифт». Если вы уже работаете с веб-разработкой, но хотите вывести свои навыки на новый уровень, этот курс станет вашим надежным проводником в мир Vue.js. Вы глубоко поймете философию фреймворка и научитесь применять его для создания сложных интерфейсов — от концепции до реализации. Здесь дают именно те знания, которые сразу можно перенести в рабочие проекты.
• Фронтенд - разработчик на Vue.js от Специалист.ru. Это ваш шанс не просто изучить технологии, а полноценно освоить профессию. Начнете с верстки, постепенно перейдете к JavaScript и Git, а затем глубоко погрузитесь во Vue.js. В финале — два ценных документа: государственный диплом о повышении квалификации и международный сертификат. Идеальный вариант для тех, кто хочет не просто научиться программировать, но и получить официальное подтверждение своих знаний.
• Vue.js от Ильи Кантора. На основе проекта вы освоите возможности Vue, различные подходы к решению практических задач и ключевые библиотеки экосистемы. В процессе работы вы разработаете компактную библиотеку переиспользуемых UI-компонентов. Параллельно с изучением Vue будут рассмотрены смежные темы фронтенд-разработки: создание одностраничных приложений, работа с инструментами сборки, освоение Vite, основы тестирования и другие важные аспекты современной веб-разработки.

Бесплатные курсы Vue.js

Начать знакомство с фреймворком можно без финансовых вложений. Хорошие курсы по Vue.js бесплатно познакомят с основами и помогут оценить перспективы дальнейшего углубленного изучения. Такие программы идеально подходят для знакомства с технологией и понимания ее возможностей. Практические задания и понятные объяснения сделают старт в разработке комфортным и интересным.

1. Vue.js — webDev. Вы рассмотрите работу с JavaScript фреймворком Vue JS актуальной второй версии, а также изучите все необходимые темы и понятия, которые нужны, чтобы начать разрабатывать на Vue.
2. Уроки по Vue.js — ITDoctor. Курс состоит из двух глав, в которых вы научитесь работать с различными директивами на Vue.js, создавать циклы, методы и вычисляемые свойства. Плейлист подойдет для веб-разработчиков, которые уже имеют опыт в работе с языками HTML, CSS, JS и желательно понимающих, как работать с гитом.
3. Бесплатный курс по Vue.js — JavaScript.Ninja. Курс по Vue.js от сообщества @vuejs_club, с помощью которого вы узнаете о компонентах, двустороннем связывании и еще о многих темах. Для наглядности автор рассматривает примеры разработки веб-приложений на демонстрации экрана. Дополнительно в содержании курса представлено несколько практикумов для самостоятельной работы.
4. Уроки Vue.js для начинающих — Гоша Дударь. В этом видеокурсе вы изучите основные моменты, которые позволят создавать приложения и сайты на Vue.js. Спикер расскажет, как создавать базовые сайты и веб-приложения с нуля.
5. Постигаем Vue js: урок 0 - установка и основные понятия — JAVA И SКРИПТЫ. Подборка обучающих видео, направленная на обучение разработчиков, которые имеют опыт программирования на JavaScript. Автор подробно рассмотрит темы по отрисовке графических объектов, подбора стилистики для проекта, работе с реактивностью, пользовательскими событиями и так далее.
6. Vue 3 фундаментальный курс от А до Я — Ulbi TV. В этом ролике вы разберете основные концепции Vue 3 и пройдетесь по нему от А до Я. Разработаете приложение с основными кейсами, которые встречаются везде: CRUD, сортировка, поиск, пагинация, динамическая пагинация. Также вы сделаете mixins, directives, изучим vuex и composition api.
7. Vue 3 — AVIS TV. Теоретический курс, автор которого рассказывает о ключевых особенностях фреймворка Vue.js и его применении в среде веб-разработке. Вы узнаете, как установить программное обеспечение на компьютер и использовать его для создания проектов разной сложности.
8. Vue 3 для начинающих / Разработка интернет-магазина Vue Sneakers — Archakov Blog. Курс по Vue 3 для начинающих, в котором вы будете разрабатывать полноценный проект Vue Sneakers, а хранить данные будете на бесплатном сервисе Mokky.

Что такое Vue.js и каковы его ключевые преимущества перед другими фреймворками

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

Понятный без долгого изучения

Фреймворки напоминают сборку мебели по запутанной инструкции — приходится постоянно сверяться со справочником. Vue же работает интуитивно: свяжите поле ввода и данные одной строкой v-model, организуйте цикл элементов через v-for, настройте реакцию на события через v-on. Код читается как обычное предложение — это ценится в командах, где важно быстро понимать друг друга.

Не требует революционных изменений

Если уже есть рабочий проект на чистом JavaScript или jQuery, Vue не заставит все переписывать. Можно внедрять его точечно — например, сделать интерактивным только фильтр товаров в каталоге или форму обратной связи. Это спасает, когда нужно модернизировать интерфейс без остановки основного функционала.

Сам заботится о скорости

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

Единая экосистема

Для типовых задач уже есть проверенные решения: Vue Router для навигации, Pinia для управления состоянием, Nuxt.js для сложных приложений. Они созданы одной командой, поэтому стыкуются друг с другом. Например, Nuxt.js из коробки решает проблемы с SEO — генерирует страницы так, что их сразу видят поисковики.

Сообщество, которое помогает

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

В чем разница между Vue 2 и Vue 3

Архитектура и реактивность

Изменение скрыто «под капотом». Vue 2 использовал систему реактивности на основе Object.defineProperty. Это означало, что фреймворк мог автоматически отслеживать изменения только в тех свойствах, которые были в объекте с самого начала. Vue 3 перешел на современный стандарт JavaScript — Proxy. Теперь Vue отслеживает изменения, включая добавление или удаление свойств объекта и даже работу с массивами, без костылей. Для вас, как для разработчика, это означает предсказуемость и меньше скрытых ошибок.

Composition API — новый способ организации кода

Vue 2 предлагал только один способ структурировать логику компонента — Options API. Вся логика должна была быть разложена по «полочкам»: data, methods, computed и так далее. Это было просто для понимания новичкам, но в больших компонентах логика, относящаяся к одной задаче, оказывалась разбросана по разным разделам. Vue 3 представил Composition API — более гибкий подход, где вы группируете код по его функциональному назначению, а не по типу. Это похоже на написание обычных JavaScript-функций. Такой код легче организовать, переиспользовать и тестировать, особенно в сложных компонентах.

Производительность и размер

Vue 3 был переписан с прицелом на производительность. В результате базовая библиотека стала на 40% легче. Это ускоряет первоначальную загрузку приложения. Кроме того, механизм рендеринга был серьезно оптимизирован: Vue 3 научился умнее определять, какие части дерева компонентов нужно обновлять при изменении. Это приводит к меньшему количеству ненужных перерисовок и плавной работе интерфейса, особенно в приложениях с большим количеством динамических элементов.

Лучшая поддержка TypeScript

Если Vue 2 с TypeScript работал, но иногда вызывал головную боль из-за сложной типизации, то Vue 3 был изначально написан на TypeScript. Это означает, что поддержка типов стала первоклассной. Теперь ваша среда разработки (IDE) будет гораздо лучше понимать, что происходит в коде, предлагая умные подсказки и сразу находя многие ошибки. Это огромный плюс для поддержки и масштабирования больших проектов.

Фрагменты и телепортация

В Vue 2 каждый компонент должен был иметь один корневой элемент. Это часто приводило к появлению лишних div-оберток в разметке. Vue 3 позволяет компонентам возвращать несколько корневых элементов — так называемые Фрагменты (Fragments). Это делает DOM-дерево чище. Также появилась директива <Teleport>, которая позволяет «вырвать» кусок кода из одного места в компоненте и отрендерить его в другом месте DOM, что невероятно удобно для модальных окон, уведомлений и тултипов.

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

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

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

GPT-5 — флагманская reasoning-модель с упором на агентные сценарии, кодинг, интеллект и управляемость. «Из коробки» она хорошо решает широкий спектр задач, но качественные промпты (подсказки) заметно повышают стабильность, скорость и соблюдение инструкций. Ниже — проверенные практики, готовые шаблоны и заметки по параметрам API (reasoning_effort, verbosity, Responses).

Предсказуемость агентного рабочего процесса

Используйте API Responses для агентов

Responses сохраняет логические следы между вызовами инструментов: это снижает задержку, экономит токены и повышает качество планов за счёт механизма previous_response_id.

Контролируйте «рвение» агента

Сдержанный режим (меньше вызовов, ниже задержки):

• Установите reasoning_effort=low|medium.
• В подсказке ограничьте глубину поиска контекста и задайте ранние критерии остановки.

Проактивный режим (больше автономии и настойчивости):

• Поднимите reasoning_effort.
• Включите явное требование «не возвращаться к пользователю до полного решения».

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

При ограничении основного поведения сбора контекста полезно явно предоставить модели запасной вариант, облегчающий выполнение более короткого этапа сбора контекста. Обычно это делается в виде условия, позволяющего модели продолжать работу в условиях неопределенности, как «even if it might not be fully correct» в примере выше.

С другой стороны, если вы хотите поощрить автономность модели, увеличить настойчивость в вызове инструментов и сократить количество уточняющих вопросов или иных случаев возврата информации пользователю, рекомендуется увеличить reasoning_effort и использовать такой промпт, чтобы поощрить настойчивость и тщательное выполнение задачи:

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

«Преамбулы» к инструментам (чтобы пользователь понимал, что происходит)

GPT-5 обучен предоставлять чёткие предварительные планы и последовательные обновления о ходе работы с помощью сообщений «преамбулы инструмента».

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

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

Усилия рассуждения и повторное использование контекста

• reasoning_effort регулирует интенсивность размышлений и готовность к вызову инструментов. Значение по умолчанию — medium. Но для многошаговых задач повышайте этот показатель.
• Разбивайте сценарий на несколько ходов агента с сохранением previous_response_id в Responses — модель не тратит токены на перестройку плана.
• Настоятельно рекомендуют использовать API Responses в GPT-5, чтобы улучшить потоки агентов, снизить затраты и повысить эффективность токенов в приложениях. Авторы отмечают, что наблюдали статистически значимые улучшения в оценках при использовании API Responses по сравнению с завершением чата. Например, рост оценки Tau-Bench Retail с 73,9% до 78,2% был только благодаря переходу на API Responses и включению previous_response_id (функции передачи предыдущих элементов рассуждений в последующие запросы). Это позволяет модели ссылаться на предыдущие трассировки рассуждений, экономя токены и устраняя необходимость перестраивать план с нуля после каждого вызова инструмента, что снижает latency. Эта функция доступна всем пользователям API Responses.

Максимизация продуктивности в кодинге

GPT-5 умеет работать с крупными кодовыми базами, накатывать многофайловые изменения, рефакторить и строить новые приложения.

Рекомендованный стек для фронтенд-приложений

• Фреймворк: Next.js (TypeScript), React, HTML
• Стили/UI: Tailwind CSS, shadcn/ui, Radix themes
• Иконки: Lucide / Heroicons / Material Symbols
• Анимации: Framer Motion
• Шрифты: Inter, Geist, Mona Sans, IBM Plex Sans, Manrope

Разработка приложений с нуля

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

Соответствие стандартам разработки

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

Фрагмент подсказки ниже демонстрирует один из способов организации правил редактирования кода для GPT-5: не стесняйтесь изменять фактическое содержание правил в соответствии со своими предпочтениями в программном дизайне.

Форматирование Markdown

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

Иногда соблюдение инструкций Markdown, указанных в системном запросе, может ухудшаться в течение длительного разговора. Если вы столкнулись с такой ситуацией, стабильное соблюдение инструкций Markdown будет работать при добавлении их к каждому 3–5 пользовательскому сообщению.

Считаем расходы и настраиваем лимиты

OpenAI взимает плату за токены — единицы измерения текста. Один токен — это 4 символа английского текста или 2-3 символа русского:

• «привет» — это 2 токена,
• «hello» — 1 токен.

Вы платите за два типа токенов:

• входящие — ваш запрос к модели,
• исходящие — ответ модели.

Актуальные цены смотрите на сайте OpenAI.

Например, GPT-4o стоит $2.50 за миллион входящих токенов и $10 за миллион исходящих. Диалог на 1000 токенов обойдётся примерно в $0.01. При обработке 10 000 таких диалогов в день расходы составят $100 ежедневно.

Настройка финансовой защиты

Перед подключением API к приложению зайдите в настройки биллинга OpenAI и настройте три параметра:

• Usage limits — жёсткое ограничение расходов. При достижении лимита API перестаёт отвечать на запросы.
• Email notifications — уведомления при достижении определённого процента от лимита (например, 80%).
• Rate limits — ограничения по токенам (TPM) и запросам (RPM) в минуту для каждого API-ключа.

OpenAI показывает статистику с задержкой 5-10 минут. Для контроля в реальном времени используйте библиотеку tiktoken:

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

Я видел много задач, которые прекрасно решаются без LLM, но «пацаны не поймут». Если без LLM и правда никак, то научитесь считать: оптимизируйте промпты, не давайте агентам уходить в долгие циклы взаимодействия с моделями.

Работаем с ChatGPT из России

OpenAI официально не доступен российским пользователям. Если попробуете зайти на их сайт или отправить запрос к API напрямую — получите ошибку.

Можно купить подписку на любой сервис обхода блокировок за 200-500 рублей/месяц. Работает, но есть нюансы:

• скорость ответов снижается,
• соединение периодически разрывается,
• если сервис накроется — ваше приложение встанет.

Более надёжный вариант — арендовать виртуальный сервер в Европе или США за $5-10 в месяц и настроить на нём прокси-сервер. Придётся потратить пару часов на настройку, зато получите стабильное соединение под вашим полным контролем.

Пришлось настроить собственный прокси — это стабильно, надёжно и недорого.

Платим за API

OpenAI принимает только зарубежные карты, и есть несколько вариантов:

• Виртуальные карты типа Pyypl или RedotPay. Минус один — при пополнении теряете 10-20 рублей на каждой сотне из-за курса, но для личных экспериментов терпимо.
• Физические карты зарубежных банков. Нужно ехать в Казахстан, Армению или Грузию, либо искать посредников. Курс конвертации в таком случае будет менее грабительским.

Если возиться с обходом блокировок не хочется, есть отечественные аналоги:

• GigaChat.
• YandexGPT.

Ещё можно рассмотреть OpenRouter. Это агрегатор разных моделей, включая ChatGPT. Работает без смены IP, но платить всё равно придётся зарубежной картой. Цены чуть выше, чем напрямую у OpenAI.

В личных экспериментах использую OpenRouter, и мне нравится. Это «единое окно» в разные модели, работает без смены IP, совместимо с OpenAI. Также есть «обёртки» во всех популярных фреймворках, таких как langchain/langgraph, очень удобно.

С одной стороны, с агрегаторами (OpenRouter) проще в плане доступа, оплаты, использования единого OpenAI API для всех моделей, консолидированного учёта расходов. С другой стороны — есть минусы: риски безопасности, стоимость, ограничения глубокой настройки и набора функций / API, ошибки доступа и маршрутизации.

Подключаем API на Python

Установите библиотеку OpenAI:

Пример базового запроса по API:

GPT API работает как любой другой сервис — отправили POST-запрос, получили JSON с ответом.

Три главных параметра, которые влияют на ответы:

• max_tokens — сколько токенов (≈ слов) может содержать ответ. Поставите 50 — получите короткий ответ. Поставите 2000 — модель распишет подробно. Каждый токен стоит денег, помните об этом.
• temperature (от 0 до 2) — насколько предсказуемы ответы. При 0 модель выдаёт самый вероятный вариант. При 1.5 начинает фантазировать. Для технической документации ставьте 0.2, для креативных задач — 0.8-1.0.
• top_p — альтернатива temperature. Ограничивает выбор слов по вероятности. Обычно используют что-то одно: либо temperature, либо top_p.

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

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

Подключаем API на JavaScript

Установите библиотеку OpenAI:

Пример базового запроса по API:

Никогда не пишите API-ключ прямо в коде, используйте файл .env:

И библиотеку dotenv:

Чтобы не уволили и не засудили

В 2023 году инженеры Samsung отправили исходный код в ChatGPT, когда просили помочь с оптимизацией. После этого корпорация запретила сотрудникам работать с публичными нейросетями. И Samsung не одиноки — Amazon, Apple, JPMorgan Chase ввели похожие ограничения.

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

Люди внезапно утратили всю бдительность и запихивают в чаты что ни попадя. Безопасники реагируют по всем направлениям, вот и про DLP (Data Leak Prevention) вспомнили.

Как работать безопасно

Перед отправкой заменяйте настоящие данные на фейковые. Вместо «Иван Петров, +79291234045» пишите «USER_NAME, USER_PHONE». После получения ответа подставляйте реальные значения обратно.

API-ключи храните в переменных окружениях, а не в коде. Меняйте ключи каждые 30-60 дней. Настройте алерты на всплески запросов — если обычно делаете 100 запросов в день, а тут внезапно 10000, значит ключ утёк.

Когда ждать ответ целиком, а когда показывать по частям

В API есть два режима получения ответов: обычный и потоковый (streaming). В обычном режиме вы ждёте, пока модель сгенерирует весь текст, и получаете его целиком. В потоковом — ответ приходит частями.

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

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

Когда нужны фреймворки

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

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

Если цель сугубо академическая, и хочется детально разобраться, то лучше изучать «низкоуровневые» API. Если строите что-то прикладное, то удобнее, быстрее и проще взять фреймворк. Я люблю langchain/langgraph, но в последнее время DSPy всё увереннее завоёвывает моё сердечко.

Из фреймворков наиболее универсальное сочетание — LangChain + LangGraph. Также могу выделить LlamaIndex, Haystack, AutoGen, crewAI, Neurite, FlashRAG.

Чек-лист перед стартом

• Зарегистрируйтесь на сайте OpenAI и получите API-ключ в разделе настроек.
• Настройте финансовые лимиты в биллинге OpenAI: Usage limits, Email notifications и Rate limits.
• Подключите зарубежную карту для оплаты (виртуальную Pyypl/RedotPay или физическую карту зарубежного банка).
• Настройте VPN или прокси-сервер для доступа к API из России (или используйте OpenRouter).
• Установите библиотеку OpenAI для вашего языка программирования (pip install openai для Python или npm install openai для JavaScript).
• Создайте файл .env и поместите туда API-ключ.
• Напишите тестовый запрос с базовыми параметрами: model, messages, max_tokens, temperature.
• Настройте обработку ошибок и повторные попытки при сбоях соединения.
• Настройте мониторинг количества запросов и алерты на аномальную активность.

Почему скорость сайта так важна

В мире, где внимание пользователей рассеивается за восемь секунд, быстрая загрузка сайта становится критически важной. Статистика подтверждает: 53% мобильных пользователей покидают сайт, если он грузится дольше 3 секунд, а 70% потребителей отмечают, что скорость влияет на их решение о покупке. Walmart, например, зафиксировал рост конверсий на 2% за каждую секунду сокращения времени загрузки.

Быстрые сайты обеспечивают:

• Долгое пребывание пользователей на сайте;
• Больше просмотров страниц благодаря быстрой навигации;
• Меньше отказов из-за медленных загрузок;
• Выше конверсии и доходов, так как скорость напрямую влияет на покупки;
• Лучшую удовлетворенность и удержание пользователей;
• Рост органического трафика, так как Google учитывает Core Web Vitals в SEO-ранжировании;
• Экономию на CDN и трафике, ведь оптимизированные сайты потребляют меньше данных;
• Повышение качества рекламы в Google Ads, так как быстрые страницы снижают стоимость кликов.

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

Как измерить производительность сайта

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

• Google PageSpeed Insights: быстрый аудит Core Web Vitals с рекомендациями.
• Chrome Lighthouse: встроенный в DevTools инструмент для анализа производительности, SEO и лучших практик.
• WebPageTest: детализированные метрики, визуализация загрузки и советы по оптимизации.
• GTmetrix: анализ скорости загрузки с рекомендациями.
• CrUX в Google Search Console: реальные данные пользовательского опыта (Core Web Vitals) для SEO.

Лабораторные инструменты дают контролируемые метрики, а мониторинг реальных пользователей (через Web Vitals JS, SpeedCurve или Calibre) показывает, как сайт работает в реальных условиях. Это поможет определить приоритеты для оптимизации.

Чек-лист оптимизации фронтенда 2025

Производительность — это командная работа. Бэкенд должен быть масштабируемым, UX-дизайнеры — балансировать визуал и скорость, а фронтенд-разработчики — реализовывать оптимизированный код. Этот чек-лист подходит для любой платформы: от Next.js и Astro до WordPress и PHP. Адаптируйте его под ваш проект, уделяя внимание ключевым метрикам, таким как LCP, CLS и INP (новый показатель, заменивший FID в 2024 году).

HTML

HTML — основа страницы, и его оптимизация ускоряет загрузку и улучшает пользовательский опыт.

• Приоритизируйте критический HTML: доставляйте HTML для верхней части страницы первым, чтобы браузер начал рендеринг. Фреймворки вроде Next.js или Astro с SSR/SSG рендерят HTML на сервере, улучшая First Contentful Paint.
• Удаляйте лишний код: уберите ненужные теги, комментарии и пробелы. Компактный HTML загружается быстрее, особенно в мобильных сетях.
• Включите сжатие: используйте GZIP или Brotli, чтобы уменьшить размер HTML. Большинство серверов и CDN это поддерживают.
• Оптимизируйте загрузку ресурсов: размещайте CSS в <head> для быстрого рендера, а скрипты — перед </body> или с атрибутами async/defer, чтобы не блокировать разбор HTML.
• Минимизируйте iframe: они загружают дополнительные страницы, замедляя сайт. Используйте loading="lazy" для iframe ниже линии сгиба или загружайте их по клику.

Совет: держите DOM компактным. Например, Astro разбивает страницы на «островки», минимизируя гидратацию JavaScript, что ускоряет рендеринг.

CSS

CSS может блокировать рендеринг, если не оптимизирован. Вот как сделать стили быстрее:

• Удаляйте неиспользуемый CSS: используйте PurgeCSS или Chrome DevTools, чтобы убрать мертвый код, особенно в проектах с Tailwind.
• Модуляризуйте стили: разделяйте CSS по страницам или функциям, загружая только необходимое. Критические стили встраивайте в <head>, остальное загружайте асинхронно.
• Избегайте @import: он создает дополнительные запросы и блокирует рендеринг. Используйте <link rel="stylesheet"> или объединяйте CSS при сборке.
• Используйте критический CSS: встраивайте стили для верхней части страницы в HTML, а остальное загружайте позже (например, через media="print"). Инструменты вроде Critical помогут это автоматизировать.
• Минимизируйте CSS: убирайте пробелы и комментарии с помощью Clean-CSS или cssnano.
• Предварительно загружайте ключевые стили: используйте <link rel="preload" as="style"> для важных CSS-файлов.
• Упрощайте селекторы: избегайте сложных вложенных цепочек, чтобы ускорить вычисления стилей. Например, .headline лучше, чем body div#main article h1.
• Применяйте современный CSS: используйте content-visibility: auto для отложенного рендера контента за пределами экрана. Это ускоряет начальную загрузку и снижает потребление памяти.

JavaScript

JavaScript часто замедляет страницы из-за объема и времени выполнения. Оптимизируйте его так:

• Заменяйте JS на HTML/CSS: используйте CSS-анимации, <details> или валидацию форм вместо JS, где возможно.

• Минимизируйте фреймворки: избегайте тяжелых библиотек для простых задач. Проверяйте сторонние скрипты (аналитика, реклама) и удаляйте ненужные.
• Разделяйте код: используйте динамический import() или возможности фреймворков для загрузки JS по необходимости.
• Предварительно загружайте важные скрипты: используйте <link rel="preload" as="script"> для ключевых JS-файлов.
• Применяйте async/defer: добавляйте эти атрибуты к <script>, чтобы не блокировать рендеринг. Defer сохраняет порядок выполнения, async подходит для независимых скриптов.
• Минимизируйте JS: используйте UglifyJS или tree shaking для удаления неиспользуемого кода. Настраивайте сборку для ES-модулей.
• Обновляйте зависимости: новые версии фреймворков (esbuild, SWC) часто быстрее. Используйте Renovate или Dependabot для автоматизации.
• Выбирайте подходящий фреймворк: Next.js с React Server Components или Astro с «островковой» архитектурой сокращают объем JS на клиенте, ускоряя загрузку.

Изображения

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

• Используйте правильный размер: не загружайте изображения больше, чем нужно для отображения. Инструменты вроде ImageMagick или Sharp помогут автоматизировать ресайз.
• Применяйте адаптивные изображения: используйте <img srcset> или <picture> для доставки изображений в зависимости от устройства.
• Сжимайте изображения: используйте ImageOptim, mozJPEG для JPEG, PNGQuant для PNG или SVGO для SVG.
• Предварительно загружайте ключевые изображения: используйте <link rel="preload" as="image"> или fetchpriority="high" для баннеров, влияющих на LCP.
• Откладывайте загрузку: добавляйте loading="lazy" для изображений ниже линии сгиба.
• Используйте WebP/AVIF: эти форматы обеспечивают лучшее сжатие, чем JPEG/PNG. CDN и фреймворки вроде Next.js автоматизируют конвертацию.
• Указывайте размеры: добавляйте width и height или CSS aspect-ratio, чтобы избежать сдвигов макета (CLS).
• Автоматизируйте оптимизацию: используйте Next.js <Image>, Astro или CDN (Cloudinary, Imgix) для автоматической обработки изображений.

Видео

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

• Сжимайте видео: используйте Handbrake для MP4/WebM, снижая битрейт или разрешение (например, 720p вместо 1080p).
• Используйте современные кодеки: WebM (VP9) или AV1 обеспечивают лучшее сжатие, чем MP4 (H.264).
• Настройте предварительную загрузку: используйте preload="metadata" или none для видео, чтобы не загружать лишние данные.
• Откладывайте загрузку: применяйте loading="lazy" для iframe или загружайте видео по клику/прокрутке.
• Удаляйте ненужное аудио: уберите звуковую дорожку из фоновых видео с помощью FFmpeg.
• Используйте потоковую передачу: для длинных видео применяйте HLS или DASH для адаптивной загрузки.
• Оптимизируйте сторонние видео: используйте облегченные встраивания (например, lite-youtube-embed) для YouTube/Vimeo.

Шрифты

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

• Ограничьте количество шрифтов: используйте минимум семейств и начертаний, чтобы сократить запросы.
• Применяйте WOFF2: этот формат компактнее TTF или WOFF и поддерживается всеми браузерами.
• Предварительно подключайтесь к источникам: используйте <link rel="preconnect"> для Google Fonts или других хостов.
• Используйте font-display: swap: это предотвращает FOIT (невидимый текст) и улучшает пользовательский опыт.
• Избегайте сдвигов макета: подбирайте резервные шрифты с похожими метриками или используйте font-size-adjust.
• Рассмотрите переменные шрифты: один файл заменяет несколько начертаний, снижая объем данных.
• Используйте системные шрифты: они не требуют загрузки и работают мгновенно.

Хостинг и сервер

Конфигурация сервера напрямую влияет на скорость загрузки:

• Используйте HTTPS: это не только безопасно, но и быстрее, благодаря HTTP/2+. Google учитывает HTTPS для SEO.
• Сократите HTTP-запросы: удаляйте ненужные ресурсы и минимизируйте сторонние скрипты.
• Перейдите на HTTP/2 или HTTP/3: HTTP/2 поддерживает мультиплексирование, HTTP/3 (QUIC) ускоряет соединение, особенно на мобильных сетях.
• Используйте CDN: кэшируйте ресурсы на серверах по всему миру для снижения задержек.
• Настройте кэширование: используйте Cache-Control для статических ресурсов и кэширование на уровне приложения.
• Оптимизируйте сервер: держите TTFB ниже 200 мс, оптимизируя запросы к базе данных и вычисления.
• Применяйте статическую генерацию: используйте SSG или ISR (Next.js) для доставки готовых HTML-страниц через CDN.

Быстрые улучшения

Эти небольшие оптимизации дают заметный эффект:

• Избегайте сдвигов макета: резервируйте место для изображений, iframe и динамического контента, чтобы минимизировать CLS.
• Используйте приоритеты: применяйте fetchpriority="high" для ключевых ресурсов и low для некритических.
• Сократите сторонние запросы: откладывайте загрузку аналитики или рекламы до взаимодействия пользователя.
• Используйте один протокол: избегайте смешанного контента (HTTP/HTTPS).
• Настройте кэширование: используйте длительный max-age для статических ресурсов с хэшами в именах файлов.
• Предварительно загружайте страницы: используйте <link rel="prefetch"> для вероятных переходов.
• Применяйте Service Workers: кэшируйте ресурсы для мгновенной загрузки и оффлайн-доступа.

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

Зачем распознавать паспорта СНГ

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

Сегодня в этом помогает искусственный интеллект – он берет на себя распознавание паспорта и позволяет получить в структурированном виде всю информацию о владельце документа без ошибок и задержек. Однако если решение умеет распознавать только российский паспорт, оно сразу теряет актуальность для Беларуси, Казахстана, Армении, Узбекистана и других стран. Это стратегический недочет – в особенности если бизнес имеет дело с иностранцами: например, связан со сферой туризма, банкингом, перевозками, или просто представлен в соседних с Россией государствах. Существенный спрос на технологии распознавание паспорта СНГ наблюдается со стороны HR-сферы – автоматизация ввода данных позволяет избавиться от бюрократических проволочек при массовом найме и работе с трудовыми мигрантами. Во всех этих случаях поддерживать распознавание документов стран СНГ просто необходимо.

Распознавание паспортов СНГ позволяет предложить единый, удобный и безопасный сценарий регистрации для пользователей из любых государств региона. В свою очередь, это повышает конверсию, сокращает клиентский путь и делает цифровые продукты доступнее для более широкой аудитории. Сегодня такие возможности искусственного интеллекта доступны не только для нативных приложений, но и для так называемых прогрессивных веб-приложений (PWA) и mini apps в мессенджерах.

Как в этом помогает WebAssembly

PWA, благодаря своей доступности и независимости от устройств и операционок, уже превратились в золотой стандарт для сферы цифровых услуг. «Прокачанные» сайты уже заменяют классические нативные приложения, поскольку не уступают по функциональности и быстродействию и при этом не требуют скачивания, обновления и поддержки в сторах. Кроме того, сейчас буквально на наших глазах происходит интеграция аналогичного формата в мессенджеры – MAX и Telegram. Туда уже интегрируют платежи и переводы, онлайн-покупки, регистрацию в сервисах и другие возможности, которые раньше оставались прерогативой нативных приложений.

Для переноса в веб хорошо знакомого пользователю функционала используется технология WebAssembly, или Wasm. Она позволяет выполнять ресурсоемкие вычисления – например, распознавание документов, анализ изображений, работу с графикой, – непосредственно в браузере. Это возможно без потери скорости и без постоянных запросов к серверу. Мы в Smart Engines разглядели перспективность Wasm задолго до того, как о технологии широко заговорили, и к моменту удаления банковских приложений из App Store и Google Play мы уже имели обширную экспертизу в этой области.

Мы разработали PWA, в котором реализовали распознавание QR-кодов, банковских карт, номеров телефонов, паспортов и других объектов. Это дало возможность ведущим российским банкам внедрить переводы по СБП и оплату квитанций прямо на интернет-странице. Таким образом, проблему блокировки приложений удалось решить – конечный пользователь получает максимально нативный опыт, оставаясь прямо в браузере. Веб-приложение хранит все необходимые ресурсы (включая Wasm-модули) в локальном кеше благодаря Service worker. В результате приложение получается максимально отзывчивым и может работать без интернета.

Как работает распознавание паспорта СНГ

Распознавание паспортов стран СНГ – задача нетривиальная: разные государства используют свои форматы документов, шрифты и уровни защиты. Мы разработали универсальную технологию, которая одинаково уверенно работает с паспортами России, Казахстана, Беларуси, Армении, Узбекистана, Таджикистана и других государств региона. В общей сложности система поддерживает более 100 языков, включая редкие письменности.

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

Как встроить распознавание паспорта СНГ в веб

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

Вы выбираете в вашем дизайне место для расположения canvas для вывода видео или делаете его скрытым для отрисовки PDF, например. Этот же подход используется, если вы пользователь айфона и хотите распознавать файл в формате HEIC.

Получаем ссылку на DOM-элемент:

Вот так мы извлекаем из него данные

Теперь же мы переключимся на воркер и заберем эти данные уже из него.

Воркер

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

Загружаем наш модуль для инициализации WASM.

Инициализируем Wasm-модуль

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

Сессия распознавания

Теперь мы подготовим сессию для распознавания. Создаем объект настроек

Указываем режим распознавания и маску документа. Можно указать маску звездочкой «*», а режим «anydoc», тогда поиск будет осуществляться по всем доступным документам.

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

Теперь мы инициализируем сессию.

Передача изображений. Видеопоток

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

Отметим, что объект canvas возвращает пиксели в формате RGBA, то есть с альфа каналом.

Создание объекта seImage класса se.common.image, необходимого для распознавания, возможно практически из любого набора пикселей, в том числе подходит и четырехканальное изображение.

Изображение создано. Теперь мы можем передать его на распознавание.

Результат

Объект result содержит в себе всю информацию о документе: текстовые поля, координаты шаблона и полей документа, изображения (подписи и фото держателя).

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

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

Если система больше не ожидает получить более качественное изображение на вход, она переводит флаг терминальности сессии в true и вы можете забрать результат.

Проверяйте результат каждый раз на терминальность:

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

А если вам интересно узнать больше про возможности искусственного интеллекта на WebAssembly, рекомендуем почитать наши прошлые статьи про распознавание банковских карт и паспорта РФ в браузере.

1. TabNine

Если вам важна скорость — TabNine стоит попробовать хотя бы ради этого. Расширение — лёгкий AI-ассистент, который работает как умный автодополнитель кода, непохожий на аналоги вроде Codeium или Copilot.

TabNine обучен на миллионах строк открытого кода и умеет предсказывать, что вы напишете дальше, с учётом контекста проекта и языка. Отлично справляется с рутинными вещами: автозавершает функции, переменные, конструкции — всё быстро и чаще всего в тему.

Кому подойдёт: тем, кто хочет ускорить набор кода, но не готов передавать весь проект в облако или открывать чат с Copilot. Поддерживает офлайн-режим и локальное обучение модели.

Плюсы:

• Работает из коробки, не требует тонкой настройки;
• Есть локальная версия — удобно для закрытых проектов;
• Поддерживает большинство языков и фреймворков.

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

2. GitLens

GitLens встраивает историю изменений прямо в VSCode — и делает это максимально удобно. Показывает, кто и когда изменил строку, коммит-месседж, хэш, ветку и другие детали. Можно не уходить в консоль или отдельный Git-клиент для поиска информации.

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

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

Плюсы:

• Информация о коммитах отображается прямо в редакторе под строкой;
• Есть таймлайн изменений файла;
• Удобный diff по коммитам, авторам, веткам и даже фрагментам кода.

Чем полезен: помогает быстрее разбираться в чужом коде, искать причины бага или откатывать ошибки. Особенно ценится за то, что делает Git прозрачным и доступным прямо в процессе разработки.

3. Error Lens

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

Можно настроить отображение: выделять ошибки цветом, добавлять иконки или даже показывать краткие подсказки с предложениями по исправлению. Поддерживает большинство языков и линтеров, включая ESLint, TypeScript и других.

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

Плюсы:

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

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

4. Path Intellisense

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

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

Кому подойдёт: всем, кто устал вручную прописывать длинные relative-пути или путаться в структуре проекта. Особенно выручает на фронтенде, где модулей десятки и легко ошибиться в названии.

Плюсы:

• Подсказки появляются автоматически при наборе пути;
• Поддерживает большинство языков и фреймворков;
• Учитывает jsconfig.json и tsconfig.json при работе с alias-ами.

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

5. TODO Highlight

TODO Highlight подсвечивает комментарии с задачами (например, TODO, FIXME, NOTE) прямо в коде, делая их заметными и удобными для отслеживания. Расширение помогает не терять важные заметки, которые вы оставляете в коде, и быстро находить места, требующие доработки.

Можно настроить ключевые слова, цвета подсветки и даже добавить свои собственные метки. Работает с любыми языками программирования и интегрируется с панелью задач VSCode для удобного обзора всех TODO в проекте.

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

Плюсы:

• Яркая подсветка TODO-комментариев прямо в редакторе;
• Гибкая настройка ключевых слов и стилей;
• Интеграция с панелью задач для быстрого обзора.

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

6. Prettier – Code formatter

Prettier — расширение, которое автоматически приводит ваш код к единому стилю, избавляет от ручной правки отступов, кавычек и переносов. Оно поддерживает множество языков (JavaScript, TypeScript, CSS, HTML и другие) и интегрируется с линтерами, чтобы ваш код был не только красивым, но и консистентным.

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

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

Плюсы:

• Автоматическое форматирование при сохранении или по хоткеям;
• Поддержка множества языков и кастомных настроек;
• Интеграция с ESLint и другими инструментами для проверки кода.

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

7. Live Server

Live Server запускает локальный сервер прямо из VSCode, позволяя просматривать изменения в HTML, CSS и JavaScript в браузере в реальном времени. После сохранения файла страница автоматически обновляется, что исключает необходимость ручного перезапуска или обновления браузера.

Поддерживает кастомные порты, HTTPS, и работает с любыми фронтенд-проектами, от простых HTML-страниц до сложных приложений на React или Vue. Можно настроить, чтобы сервер открывался автоматически при запуске проекта.

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

Плюсы:

• Автоматическое обновление страницы при изменении кода;
• Простая настройка и поддержка HTTPS для безопасного тестирования;
• Лёгкий запуск сервера прямо из редактора.

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

8. Project Manager

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

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

Кому подойдёт: разработчикам, которые ведут сразу несколько проектов, часто переключаются между ними и устали искать нужный путь через File > Open Folder.

Плюсы:

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

Чем полезен: избавляет от рутинных действий при переходе между проектами — особенно когда важно не терять фокус и не сбиваться с рабочего темпа.

9. Code Spell Checker

Code Spell Checker выявляет орфографические ошибки в комментариях, строках и именах переменных прямо в редакторе VSCode. Расширение подчёркивает опечатки волнистой линией и предлагает варианты исправления через Ctrl+. или Cmd+., что позволяет быстро исправить ошибки.

Поддерживает множество ЯП и словари для разных языков (английский, русский, немецкий — с дополнительными расширениями). Можно добавлять свои слова в пользовательский словарь или игнорировать определённые термины, чтобы адаптировать проверку под проект. Работает с camelCase и snake_case, не помечая их как ошибки.

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

Плюсы:

• Мгновенное обнаружение ошибок с подсказками для исправления;
• Гибкая настройка словарей и игнорируемых слов;
• Поддержка технических терминов и различных стилей написания кода.

Чем полезен: экономит время на поиск и исправление опечаток, особенно в документации или пользовательских сообщениях, которые могут повлиять на восприятие проекта.

10. REST Client

REST Client позволяет отправлять HTTP-запросы и просматривать ответы непосредственно в VSCode. Достаточно создать файл с расширением .http или .rest, написать запрос в простом текстовом формате, и вы увидите кнопку Send Request для моментального выполнения.

Поддерживает все типы запросов (GET, POST, PUT, DELETE и другие), авторизацию (Basic, OAuth, JWT), переменные окружения и даже генерацию кода на разных языках. Запросы можно сохранять в репозиторий, что удобно для командной работы. Расширение также позволяет использовать динамические переменные по типу {{$timestamp}} или {{$guid}}, всё для гибкой настройки запросов.

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

Плюсы:

• Простая отправка запросов через .http или .rest файлы с кнопкой Send Request;
• Поддержка переменных окружения и авторизации для сложных API;
• Возможность сохранять запросы в репозитории для совместной работы.

Чем полезен: ускоряет тестирование API, устраняет необходимость в сторонних приложениях. Запросы хранятся рядом с кодом, что упрощает документирование и повторное использование, особенно в проектах, где API-вызовы нужно часто проверять или делиться ими с командой.

А какими расширениями пользуетесь вы? Пишите в комментариях!

Главные отличия Web3 от Web2

Перед тем как углубиться в код и практику, полезно увидеть основные различия между привычной Web2-разработкой и новой логикой Web3.

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

В Web3 логика сильно меняется. Пользователь входит в систему с помощью криптокошелька, например, MetaMask. Каждая задача создаётся транзакцией и записывается в смарт‑контракт, а значит становится частью блокчейна. Удалить её уже нельзя — только отметить статус выполнения. Такой подход даёт прозрачность: любой участник сети может проверить, что задача действительно существует, и её статус изменён честно.

Стек Web3: что понадобится на практике

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

• Блокчейн: Ethereum, Layer‑2 (Arbitrum, Optimism, Base, Polygon), Solana.
• Языки: Solidity (EVM), Rust (Solana), Go (инфраструктура и сервисы).
• Библиотеки: ethers.js, wagmi.
• Фреймворки: Hardhat, Foundry, Truffle.
• Хранилища: IPFS/Arweave для файлов и метаданных.
• Кошельки/подключение: MetaMask, WalletConnect (v2/WalletConnect Network), Web3Auth.

Точка входа для новичка — Alchemy, а также ethers.js.

Пример. Быстрое подключение кошелька (ethers.js).

Архитектура DApp: из чего состоит современное Web3‑приложение

Любое Web3‑приложение строится из нескольких слоёв, каждый со своей ролью. Фронтенд остаётся привычным SPA, но работает не с сервером, а напрямую с кошельком и смарт-контрактами. Контракты содержат бизнес‑логику и хранят ссылки на данные в децентрализованных хранилищах. Оракулы обеспечивают связь с внешним миром, например, передают цены или сообщения между разными блокчейнами. Важную часть играет off‑chain слой — сервисы вне блокчейна (индексаторы, аналитика), которые помогают быстрее искать и обрабатывать данные, при этом не перегружать сеть.

Пример. Возьмём DeFi‑приложение. Пользователь открывает фронтенд и инициирует операцию swap(). В ответ фронтенд обращается к смарт‑контракту, который выполняет обмен токенов. Чтобы определить курс, контракт тянет актуальные данные через оракул. При этом тяжёлые артефакты, изображения или отчёты не хранятся в блокчейне напрямую — они лежат в IPFS. Сам контракт содержит только контент‑идентификаторы CID. Таким образом, получаем баланс: блокчейн отвечает за логику и безопасность, а децентрализованное хранилище — за данные.

Практика: ваш первый DApp за вечер

Давайте попробуем собрать простейшее приложение своими руками.

Шаг 0. Подготовка

Сначала убедитесь, что у вас стоит Node.js LTS и Git. Также нужен браузер с установленным MetaMask, где можно создать тестовый аккаунт. Чтобы оплачивать транзакции в тестовой сети, заранее возьмите немного тестовых монет через faucet — например, для Sepolia или Polygon Amoy.

Шаг 1. Проект

Создадим новый проект и установим Hardhat вместе с тулзами. Эта среда нужна для компиляции и деплоя контрактов.

Шаг 2. Контракт

В папке contracts/ создаём файл TaskTracker.sol и копируем туда код смарт-контракта из первого раздела. Это и будет бизнес-логика нашего приложения.

Шаг 3. Сценарий деплоя

Пишем скрипт, который разворачивает контракт в сети. Это простой скрипт на JavaScript, который вызывает методы Hardhat.

Шаг 4. Конфиг сети

В файле hardhat.config.js добавляем настройки для подключения к тестовой сети. Используем RPC-URL от Alchemy или Infura и приватный ключ от тестового аккаунта — его можно экспортировать из MetaMask, но использовать только для тестовой сети.

Шаг 5. Деплой в тестнет

Теперь запускаем скрипт деплоя. После выполнения увидите адрес контракта — он понадобится для фронтенда.

Шаг 6. Фронтенд (React + ethers.js + wagmi)

Собираем простое SPA: форма, чтобы добавить задачи, и кнопка «complete». Здесь мы используем ethers.js для обращения к контракту. Сделайте вызовы addTask и completeTask.

Подводные камни Web3-разработки и что с ними делать

Комиссии (gas): любая запись в блокчейн стоит денег и иногда комиссия выше ценности операции — например, $10 за простую задачу.

• Что делать: использовать Layer-2 (Arbitrum/Optimism/Base/Polygon), выбирать сети с низкими комиссиями (Solana, Avalanche), оптимизировать контракты и батчи транзакций.

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

• Что делать: показывать «оптимистичный UI», кешировать данные, переносить часть логики off-chain, использовать быстрые сети (Solana, Near, Aptos).

Безопасность: код контракта неизменяем, и одна ошибка может стоить миллионов.

• Что делать: проходить аудит (CertiK, Trail of Bits), использовать проверенные библиотеки (OpenZeppelin), писать тесты в тестовых сетях (Goerli, Sepolia), внедрять баг-баунти и ролевую модель доступа.
• Ресурс: ConsenSys Diligence — Smart Contract Security Best Practices.

UX: вход через кошелёк сложнее привычного логина/пароля. Нужно ставить расширение, пополнять баланс и подтверждать каждую транзакцию.

• Что делать: использовать аккаунт-абстракцию (ERC-4337), социальный логин, gasless транзакции через Paymaster, улучшать UI (подсказки, авто-фокус на MetaMask).

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

• Что делать: консультироваться с юристами, следить за изменениями. Например, MiCA в ЕС — “Markets in Crypto-Assets Regulation” — это единый регламент по криптоактивам в Евросоюзе.

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

Карьерные возможности и перспективы

Web3‑разработчиков уже активно ищут: зарплаты в среднем предлагают выше, чем у Web2‑коллег. Кроме программистов, востребованы смежные роли: аудиторы смарт‑контрактов, специалисты по безопасности, а также продакт‑менеджеры и аналитики, которые понимают специфику блокчейна.

Чтобы войти в профессию, начните с изучения Solidity и базовых паттернов смарт‑контрактов. Сделайте пару пет‑проектов и выложите код в GitHub. Отличный вариант прокачки — участвовать в хакатонах и грантовых программах от Ethereum Foundation или Solana Grants. Это даёт и опыт, и контакты, и иногда финансирование.

Пара пет‑проектов + понимание блокчейна — хороший старт в Web3‑команду.

Будущее Web3

Web3 не вытеснит Web2 полностью, но поменяет привычный подход к разработке. Разработчику это открывает новые вызовы: комиссии, безопасность и UX, но одновременно и новые возможности — прозрачные данные, токенизация, децентрализованные бизнес‑модели.

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

Web3 будет развиваться параллельно с Web2, усиливая те области, где важны децентрализация, доверие и контроль за данными. Попробуйте задеплоить первый контракт — и вы сами почувствуете, что это не просто мода, а новый уровень возможностей.

Если вы фронтенд-разработчик или только планируете им стать, эта публикация поможет вам сориентироваться в текущей ситуации:

• Узнаете, какие крупные изменения произошли в React, Vue и Angular за последние 5-10 лет.
• Поймёте, стоит ли учить новые фреймворки без виртуального DOM или лучше углубиться в проверенные решения.
• Разберётесь, почему компании продолжают требовать знание React, хотя Solid.js работает быстрее.

Тимлид и разработчики рассказали, как они видят будущее профессии. Объяснили, почему джуну недостаточно знать только JS, какие навыки помогут вам зарабатывать больше и оставаться востребованным специалистом.

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

Как изменились React, Vue и Angular за последние 5-10 лет?

React

До 2019 года разработчики писали объёмные классы с методами жизненного цикла. Они управляли состоянием через setState и передавали данные через пропсы. Потом появились хуки — с тех пор логику помещают в функции, состоянием управляют через useState и useReducer, побочные эффекты контролируют через useEffect.

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

Vue

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

Компилятор научился оптимизировать шаблоны на этапе сборки. Телепорты решили проблему с модальными окнами и всплывающими подсказками — компоненты отрисовываются в нужном месте DOM-дерева независимо от родителя.

В какую сторону развивается Vue и есть ли ему современные альтернативы

Angular

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

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

Фреймворки уходят от сложных решений к более простым. Тренд последних лет — делать приложения быстрее для пользователей и удобнее для разработчиков.

Пока большая троица занималась «работой над ошибками», появился запрос на что-то более лёгкое и быстрое.

Фронтенд-фреймворки кажутся избыточными — возвращаемся к ванильному JS?

Тот, кто попробовал фреймворки, никогда не вернется к чистому ванильному JS 🙂 Меняются и развиваются сами фреймворки, но тренда на отказ от них точно нет.

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

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

Фреймворки — это ещё и способ стандартизации разработки в командах.

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

Из-за критики традиционных фреймворков появился новый класс решений. Больше всего ругают VDOM и гидратацию, хотя они считались неотъемлемой частью современных SPA.

Стоит ли переходить на фреймворки без VDOM и гидратации?

Solid.js и Svelte уже несколько лет развивают концепцию тонкой реактивности. В 2021 году появился Qwik, который вообще отказался от гидратации.

SolidJS хорош для аналогов десктопных приложений в браузере — Figma, Miro. Здесь приложение загружается один раз, а потом работает долго и должно быть максимально отзывчивым. Qwik отлично подойдёт, если вы создаёте сайт, куда пользователь приходит за контентом, и важно показать ему этот контент мгновенно.

При этом массового перехода на новые фреймворки пока не происходит. Компании продолжают искать React и Vue разработчиков — проекты на Solid.js и Qwik остаются экспериментальными.

Сами по себе фреймворки мало значат для коммерческой разработки без сторонних библиотек вокруг них. Вот когда критическая масса разработчиков популярных библиотек мигрирует на Qwik, а вместе с ними и сообщество, что-то сдвигается.

Проблема новых фреймворков — это отсутствие экосистемы. React и Vue окружены тысячами готовых библиотек для любых задач. На Solid.js и Qwik большинство решений придётся писать самостоятельно.

Без поддержки сообщества пользователей ни один инструмент не сможет стать массовым. Даже если работаешь в заказной разработке и есть возможность расширить кругозор команды, сомнительно брать на тест инструмент, под который придётся писать до 30% базового функционала.

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

У новых фреймворков высокий порог входа: вас ждёт переобучение команды и сложности ручной оптимизации.

Технологии развиваются циклично. То, что сейчас кажется инновацией, переосмысливает старые подходы.

Во времена DDR/DDR2 было сложно выполнять клиентский рендеринг, а вот серверам ресурсов хватало. Разработчики как могли воплощали подход, который сейчас называется SSR, и возвращали на клиент готовую разметку для компонентов. И никакого тебе VDOM.

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

Как изменится роль фронтенд-разработчика в 2026 году?

В 2020 году джуниор находил работу, если знал HTML, CSS и основы JS. Сегодня работодатели требуют от новичков React или Vue, TypeScript, системы сборки — и это не конец списка. Ещё и вакансий на всех начинающих не хватает, компании сразу ищут мидлов.

Инструменты с искусственным интеллектом — Copilot, ChatGPT, Cursor — ускоряют работу. Они же повышают планку: если джун с помощью ИИ работает как мидл, то мидл должен демонстрировать более глубокие знания. Работодатели стали больше ценить тех, кто понимает принципы работы кода, а не просто копирует готовые решения.

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

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

Какие навыки развивать разработчику, чтобы оставаться востребованным?

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

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

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

Архитектурное мышление отличает «сильного» разработчика:

• Как организовать код, чтобы его легко поддерживать?
• Как спроектировать API, чтобы оно не ломалось при изменениях?
• Как построить систему, которая выдержит рост нагрузки?

Те, кто решают эти вопросы, получают офферы с космическими зарплатами.

Софт-скиллы тоже влияют на карьерный рост:

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

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

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

Как ChatGPT повлиял на ценность вашего труда? Успеваете подстраиваться под требования рынка, параллельно работать и пробовать новые технологии? Делитесь в комментариях.

Дмитрий Борцов — руководитель разработки клиентских интерфейсов в PREMIER.ONE. В его подчинении более 60 инженеров, распределённых между вебом, Android, iOS и SmartTV. В индустрии он уже 15 лет: прошёл путь от фриланса и собственной студии до руководства крупными командами. Такой опыт, как он сам говорит, позволяет видеть рынок «с двух сторон» — понимать, что нужно бизнесу и какие компетенции позволяют разработчику стоить дороже. Сегодня Дмитрий совмещает управленческую роль с менторством: вместе с техлидом PREMIER.ONE Андреем Автушенко он развивает платформу Frontend Alliance, где в формате парного наставничества помогает фронтендерам — от джунов до тимлидов — прокачивать хард и софт скиллы, готовиться к собеседованиям и строить карьеру с опорой на реальную практику.

Фронтенд под давлением: рынок стал жёстче, но не умер

Сегодня фронтенд-разработчикам всё чаще приходится отвечать на вопрос: «А рынок-то живой или всё?» Картинка действительно изменилась. Ещё несколько лет назад компании практиковали агрессивный найм: быстро расширяли команды, нанимали десятки разработчиков сразу, а через полгода без сожалений сокращали половину штата. Это было дорого, но при низкой ключевой ставке позволительно: деньги горели, но продукт успевал расти.

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

Тем не менее, говорить о «смерти» фронтенда было бы ошибкой. Спрос не исчез, он просто сузился до тех, кто способен приносить реальную ценность. И здесь проявляется давний раскол: 95% специалистов ограничиваются задачами уровня интерфейсной косметики, а оставшиеся 5% умеют проектировать системы, предлагать архитектурные решения и смотреть шире макета. Именно за этих людей компании будут бороться при любых условиях.

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

Что должен уметь фронтендер в 2025 году и как попасть в «5% из 95»

Уровень middle и senior во фронтенде больше не определяется знанием пары фреймворков. Базовый «джентльменский набор» очевиден: HTML, CSS, JavaScript и хотя бы один современный фреймворк — React, Vue, Angular или Svelte. Сегодня к нему де-факто добавился TypeScript: без него в резюме вы рискуете выглядеть устаревшими, даже если на проекте TS практически не используется. Работодатели хотят видеть уверенную работу с ним, потому что это напрямую ассоциируется со стабильностью и предсказуемостью кода.

Дальше идут надстройки, которые начинают выделять кандидата. Это метафреймворки вроде Next.js или альтернативы с упором на SSR и SSG, понимание разных паттернов рендера и умение применять их под конкретный продукт. Сюда же — юнит-тесты. Никто не будет устраивать экзамен на знание Jest, но сам факт владения тестированием сразу повышает ценность инженера.

Самый заметный маркер — архитектурные практики. Фронтендер, который мыслит архитектурно, понимает FSD, может объяснить, зачем нужны микрофронты (и когда они не нужны), сразу выделяется на фоне тех, кто «просто собирает фичи». Настроить приложение так, чтобы через два года его не пришлось переписывать, — это компетенция, которая превращает разработчика в дорогого специалиста.

При этом стек сам по себе не делает из мидла сеньора. Настоящее отличие — в мышлении. Сеньор умеет общаться с соседними командами, отстаивать нужные изменения в API или инфраструктуре, учитывать долгосрочные риски продукта. Это опыт, который не заменят ни курсы, ни туториалы. И именно он отличает того, кто «пишет код», от того, кто создаёт систему.

Найм и подготовка кандидата: где спотыкаются фронтендеры

Первое, что бросается в глаза при просмотре резюме фронтендеров, — это ошибки самопрезентации. Человек может написать «переписал приложение на новый фреймворк» и не уточнить, что это сократило время загрузки на 30% или сняло половину багов в проде. Для HR выглядит как рядовая строчка, хотя на деле это серьёзное достижение. Добавим сюда непонимание того, как работает HeadHunter: большинство кандидатов просто игнорируют логику поиска и фильтров, и их резюме тонет в выдаче. В итоге, 85% проблем — это не недостаток скиллов, а то, как они упакованы.

Работа ментора начинается именно с этого: помочь собрать рабочее резюме и научить играть по правилам площадок. Но это лишь малая часть. Основная работа — скорректировать харды и софты, довести знания до актуального уровня, натренировать коммуникацию. Ведь первое собеседование с HR часто решает, попадёте ли вы вообще на технический этап. Поэтому вместе с резюме разбирается поведение: как отвечать рекрутеру, какие вопросы задавать, как «продавить» интерес к себе.

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

Отдельный вызов — мотивация. Когда человек месяцами безуспешно ищет работу, у него закономерно опускаются руки. Но ментор — не коуч по вере в себя. Его задача — показать ошибки, дать направление, поддержать обратной связью. А вот сама мотивация должна рождаться внутри. Часто оказывается, что проблема банальна: кандидаты игнорируют рекомендации. Например, используют автокликеры, которые рассылают сотни откликов без сопроводительных писем. Конверсия такого «спама» очевидна: нулевая. Настоящая работа требует внимания к деталям, дисциплины и готовности честно исправлять свои ошибки.

Кейс «Кода найма»: как Ярослав Грачёв выбил оффер в 380К

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

Первое, что пришлось менять, — резюме. Вместо сухого «работал три года» появилось описание проектов и секция «Обо мне». Ярослав даже перефотографировался, чтобы профиль выглядел живым. Параллельно он учился работать с алгоритмами HeadHunter и GPT: HH поднимал резюме в выдаче, а бот имитировал собеседования. Через две недели у кандидата уже был первый оффер.

Ситуация была интересной: предложение на 300 тысяч выглядело заманчиво, но ментор настоял не торопиться. Аргументы были простыми: поток откликов и приглашений уже пошёл, значит, офферы будут и дальше. Они вместе придумали безопасную отговорку для HR и договорились ждать неделю. Ставка сыграла — скоро пришёл новый оффер на 360 тысяч.

И тут началась работа с переговорами. Дмитрий считал, что Ярослав стоит дороже, и предложил сыграть на личных обстоятельствах: «Переезд, ипотека, второй ребёнок — дайте больше». Обычно такой прямолинейный запрос не работает, но в этот раз HR пошёл навстречу и поднял ставку ещё на 20 тысяч. Сработало сочетание доверительной коммуникации и того, что за спиной у кандидата был запасной оффер.

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

А дальше начинается игра на рынке: один оффер на 250 можно держать как «аварийный», второй на 300 использовать для торга, третий — поднять до 350. Главное — не зажиматься на звонках с HR: «их мотивация — провести тебя дальше, деньги они получают за закрытых кандидатов», — напоминает Дмитрий. Поэтому правило простое: дружелюбие, открытость и готовность разговаривать.

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

Советы начинающим фронтендерам

Дмитрий выделяет несколько аспектов, которым стоит уделять внимание в вопросе оффера мечты:

Не рассчитывайте только на ментора

Ментор может сильно ускорить путь: кто-то готовит к собесам, кто-то учит реально работать. Но это не панацея. Без самостоятельного копания в YouTube, статьях и пет-проектах вы просто застрянете. При этом нужно быть готовым к тому, что половина выученного окажется невостребованной, а рынок попросит ещё десяток дополнительных технологий.

Начинайте с основы, а не с фреймворка

Ключевой навык фронтендера — JavaScript. «Все есть JavaScript», — как сказал Илья Климов. React, Vue, Angular, Svelte — это лишь надстройки. Если понимаете сам язык и то, как он работает под капотом, вы сможете писать на чем угодно, хоть в фронте, хоть на Node.js в бэке.

Не ведитесь на быстрые рецепты успеха

Онлайн-школы и ютуберы любят обещать: «выучишь React — и всё в шоколаде». Но без знания JS никакой React не спасёт. На собеседованиях почти всегда спрашивают именно JavaScript, а не то, как вы намагичили интерфейс на очередном фреймворке.

Думайте о том, зачем работает код

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

История Дмитрия Борцова и Ярослава Грачёва — это иллюстрация того, что даже в перегретом и избирательном рынке фронтенда можно найти своё место. Ключ к успеху — не только в технической базе, но и в умении правильно упаковать опыт, показать насмотренность и держать фокус на том, что важно работодателю. Для джунов это часто означает вложиться в JavaScript, а не в очередной модный фреймворк. Для мидлов и выше — развивать софты и стратегически подходить к собеседованиям. А для всех уровней — не замыкаться в одиночном обучении, а искать наставников и сообщество, которые помогают расти быстрее.

Фронтенд в 2025-м всё ещё щедр, но не прощает случайности. И чем раньше разработчик перестанет полагаться на удачу и начнёт работать над собой системно, тем выше шансы получить оффер, который изменит карьеру.

«Выбор React — это рефлекс»

Автор утверждает, что команды слишком часто выбирают React не потому, что он подходит под задачи, а потому, что «все его знают».

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

Технологии 2013 года в 2025-м

React до сих пор использует концепции, созданные более 10 лет назад: виртуальный DOM, эффект-хуки, ререндеринг через reconcile.

Хотя команда React продолжает развивать фреймворк (например, через Server Components и React Compiler), сам подход остается сложным и неэффективным — особенно в сравнении с конкурентами, которые перераспределяют нагрузку на этапе сборки и избегают избыточных вычислений в браузере.

Проблема — не в React, а в «React-по-умолчанию»

По мнению автора, React сам по себе не плох. Проблема — в «монокультуре», которая блокирует инновации.

Меньше внимания уделяется веб-стандартам, большинство вакансий требует именно React, а университеты ориентируются на рынок, а не на фундаментальные знания.

Что делать

Разработчик призывает руководителей и команды делать выбор не по инерции, а осознанно: оценивать реальные требования проекта, пробовать альтернативы, не бояться использовать Svelte, Solid или Qwik хотя бы в отдельных модулях.

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

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

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

Во время работы я наткнулся на подход, который мне очень понравился: ADR — Architectural Decision Record, или «протокол архитектурных решений».

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

Проще говоря, это как личный дневник — только для всей команды.

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

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

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

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

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Ценность ADR я впервые осознала в 2019 году. В команду, где работала, активно набирали новых ребят, и приблизительно раз в неделю кто-нибудь из новых разработчиков спрашивал "а почему это сделано так, а не иначе?" Приходилось постоянно давать ответы на одни и те же вопросы, и тогда-то я и поняла, насколько будет удобно записывать ответы где-нибудь в документацию в confluence и просто кидать ссылку новичкам.

В 2019 году я еще не знала сам термин ADR и говорила "документация". С термином я познакомилась совсем недавно — этим летом, на курсе по архитектуре монолитных приложений. Тогда я поняла, насколько эффективно можно использовать ADR для ускорения разработки и уменьшения TTM. Дело в том, что начиная разрабатывать новый проект, разработчик первое время (от месяца до полугода! всё зависит от размера проекта) погружается в проект — разбирается, как всё устроено, чтобы вносить изменения соответственно архитектуре. В этот период разработчик, по сути, составляет собственные adr — обычно в виде мыслеобразов в своей голове :) Если записать основные решения, разработчик сможет намного быстрее погрузиться в проект.

Как писать ADR?

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

Вдохновившее меня соглашение можно найти на GitHub . Вы также можете ознакомиться с процессом ADR на Amazon.

Вот пример шаблона, который вы можете использовать.

Такой тип документа может находиться прямо в репозитории проекта, в Confluence или, например, в JIRA.

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

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

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

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

Помимо низкого приоритета, ситуацию усугубляет распространенный миф:

«Доступность нужна лишь небольшой группе людей»

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

• Пожилых пользователей;
• Людей с временными травмами (например, со сломанной рукой);
• Тех, кто пользуется сайтом в неидеальных условиях (яркое солнце или плохая погода).

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

К тому же, руководство WCAG многим кажется сложным и объёмным документом, что заставляет откладывать изучение.

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

Как люди с ограничениями жизнедеятельности пользуются цифровыми сервисами?

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

Скринридеры (NVDA, VoiceOver, Orca)

Скринридер — это программа, которая с помощью синтеза речи или шрифта Брайля представляет пользователю содержимое экрана. Например, в случае шрифта Брайля — в форме рельефно-точечного шрифта.

Скринридер работает не с отрисованной страницей, а с деревом доступности, которое строится на основе семантической HTML-разметки. Чем семантичнее вёрстка, тем точнее скринридер представит контент пользователю.

Строго говоря, «скринридер» — это жаргонизм. В официальных русскоязычных документах (в частности, ГОСТ-Р 52872-2019) этот класс вспомогательного программного обеспечения называется «программа экранного доступа»

Клавиатура

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

В этом случае пользователи полагаются на логичный порядок перемещения фокуса (клавиша Tab — переместиться вперёд, Shift+Tab — вернуться назад) и возможность управлять сложными компонентами (меню, слайдерами) с помощью стрелок и других клавиш.

Пример хорошей поддержки прямого клавиатурного управления можно найти в Web-версиях Яндекс Музыки и на Кинопоиске: в плеере нажатие клавиши k приостанавливает и возобновляет воспроизведение, а курсорные стрелки отвечают за перемотку и изменение громкости

Увеличение экрана

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

• Масштабирование страницы в браузере;
• Программы увеличения экрана;
• Коррекция цветовой палитры;
• Изменение внешнего вида указателей;
• Озвучивание текстовой информации при помощи синтезатора речи;
• Пользовательские стили со своими шрифтами и цветами.

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

Теперь перейдём к инструментам, которые помогут автоматизировать ручные проверки.

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

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

Lighthouse (от Google)

Lighthouse — простой и популярный инструмент, встроенный прямо в Chrome.

Для запуска Lighthouse нужно:

• Открыть браузер;
• Открыть консоль разработчика (F12);
• Перейти во вкладку Lighthouse;
• Выбрать категорию Accessibility;
• Нажать «Analyze page load».

Схожий функционал можно найти во всех основных браузерах:

• Firefox — Accessibility Inspector
• Safari — Audit
• Microsoft Edge — Accessibility Checker

После запуска Lighthouse соберёт отчёт с оценкой от 0 до 100 баллов и списком проверенных критериев, разделенных на три группы:

• Passed audits: что работает правильно;
• Opportunities: рекомендации по улучшению;
• Diagnostics: дополнительные советы, не влияющие напрямую на оценку.

Затем Lighthouse рассортирует проблемы по категориям:

• Навигация: доступность с клавиатуры, логичный порядок фокуса;
• ARIA: правильное использование ARIA-атрибутов;
• Цвет и контраст: достаточность контраста для слабовидящих;
• Семантика и структура: правильность HTML-разметки;
• Имена и метки: наличие описательных текстов для элементов форм и ссылок;
• Прочее: рекомендации согласно лучшим практикам.

Accessibility Insights (от Мicrosoft)

Accessibility Insights — это open source-инструмент от Microsoft выпущенный в 2019 году, который предлагает комплексное решение для поиска и устранения проблем.

Accessibility Insights предоставляет два вида аудита:

• FastPass: быстрый аудит для ежедневного использования, который способен найти критические проблемы сайта за считанные минуты;
• Assessment: глубокий аудит на соответствие стандартам WCAG 2.1 Level AA предназначенный для тестировщика или разработчика.

Его ключевое преимущество — обучающие элементы. Он не просто находит ошибку, но и объясняет причину проблемы и как её исправить. Также он помогает удобно создавать тикеты в трекере (например, Jira), включая описание, рекомендации и стандарт WCAG.

Accessibility Insights — полноценная экосистема доступности. Отлично подходит для команд, которые хотят глубоко разобраться в теме и встроить a11y в процесс разработки.

WAVE

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

Инструмент доступен как веб-сервис и как браузерное расширение.

WAVE помечает элементы на странице цветными иконками:

• Красные (Errors): критические ошибки, которые с высокой вероятностью нарушают доступность.
• Желтые (Alerts): предупреждения о возможных проблемах, требующих ручной проверки.
• Зеленые (Features): подсвечивают элементы, которые реализованы правильно.
• Синие (Structural Elements): показывают структурные и семантические элементы HTML5.
• Иконки контрастности — показывают результаты проверки контраста текста и фона.

WAVE более простой инструмент по сравнению с Lighthouse, но он отлично подходит для быстрого визуального поиска и исправления ошибок прямо в процессе верстки.

IBM Accessibility (от IBM)

IBM Accessibility — это не просто инструмент, а целая экосистема. Она включает в себя принципы, практики и инструменты для всех этапов жизненного цикла продукта — от проектирования до разработки и тестирования.

Из конкретных инструментов для разработчиков IBM предлагает:

• Браузерные расширения для Chrome, Firefox, Edge;
• Пакеты для встраивания в CI/CD (Java, NPM и Cypress).

IBM Accessibility подойдёт крупным компаниям, желающим системно внедрить доступность на всех этапах работы — от проектирования и разработки до тестирования и поддержки.

Библиотеки компонентов

Готовые библиотеки с уже продуманной доступностью избавляют от необходимости реализовывать сложную логику управления фокусом и ARIA-атрибутами с нуля.

Обычно такие библиотеки содержат в себе:

• Набор headless-компонентов с правильным ролями и ARIA-атрибутами;
• Поддержку управления фокусом и навигацией через клавиатуру;
• Набор хуков для кастомной поддержки пользовательский действий.

Пример библиотек:

• Для React — Reakit, React Aria;
• Для Vue — Vuetify, Quasar, Vue Material;
• Для Angular — Angular Material.

A11y плагин для Storybook

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

A11y плагин для среды разработки

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

Вот основные из них:

• React: eslint-plugin-jsx-a11y для React;
• Vue: eslint-plugin-vuejs-accessibility;
• Angular: Codelyzer и angular-eslint.

Заключение

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

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

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

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

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

Под «логами» обычно понимают технические файлы, которые создаются автоматически и содержат технические сообщения.

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

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

Последний рубеж React и Vue

Согласны, что VDOM превратился в бюрократическую прослойку? Изменили состояние в одном месте — получите полный пересчёт дерева компонентов. Фреймворки заставляют загружать всё сразу, тащат багаж служебного кода. И пока этот код не загрузится, пользователь смотрит на белый экран.

SSR ускоряет загрузку страницы: сервер рендерит HTML, пользователь видит контент и пытается с ним взаимодействовать. Но пока JavaScript не загрузится, ничего не заработает.

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

Системные проблемы не исправить очередным хуком или новой версией фреймворка, поэтому появление SolidJS и Qwik — было вопросом времени.

Поиск новых решений — здоровый признак развития фронтенда. В конце концов, и Vue был создан потому, что Эвану Ю не хватало облегченной альтернативы AngularJS. Большая тройка фреймворков решает огромный спектр задач, имеет колоссальную поддержку сообщества, но их нельзя назвать идеальным инструментом на все случаи жизни.

Обзор SolidJS

SolidJS во многом похож на React. Самое интересное — его подход к обновлению интерфейса:

• Отсутствие виртуального DOM — Solid напрямую обновляет только те DOM-узлы, которые действительно изменились.
• Компоненты как функции инициализации — каждый компонент вызывается только один раз для настройки реактивности.
• Сигналы вместо хуков — состояние управляется через createSignal(), который возвращает геттер/сеттер пару.

Например, когда срабатывает счётчик, Solid не перерисовывает весь компонент. Он точечно обновляет только текст внутри <p>, где используется count():

Преимущества SolidJS

👍 Производительность и размер бандла

Благодаря отсутствию виртуального DOM и мелкозернистым обновлениям, приложения работают быстрее аналогов на React.

👍 Простота освоения

Синтаксис SolidJS похож на React. Функциональные компоненты, JSX, концепции вроде Suspense и Error Boundaries — всё это есть в Solid. Изучение основ займёт 1-2 дня, если есть опыт с MobX/effector/RxJS.

👍 Стабильность

Фреймворк находится на стабильной версии 1.x. Это означает отсутствие кардинальных изменений API, в отличие, например, от ситуации со Svelte, где сосуществуют версии 4 и 5 с разными подходами.

👍 Совместимость с React

SolidJS совместим с экосистемой React. Можно переиспользовать дизайн-системы и компоненты в legacy-приложениях.

👍 Удобное управление состоянием

Функционал сигналов и сторов покрывают 90% потребностей в управлении состоянием без необходимости подключать внешние библиотеки.

Минусы SolidJS

👎 Ограниченная экосистема

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

👎 Кривая обучения

Несмотря на знакомый синтаксис, модель реактивности SolidJS отличается от React. Разработчики должны усвоить следующие принципы:

• Избегать условных конструкций непосредственно в компонентах.
• Не деструктурировать пропсы и сторы, чтобы сохранить реактивность.
• Не использовать асинхронный код внутри createEffect.

👎 Проблемы с инструментарием

Возникают сложности с настройкой компилятора в нестандартных окружениях — монорепозиториях, при запуске тестов или интеграции с другими инструментами. DevTools не дотягивает до аналога у React.

👎 SolidStart всё ещё развивается

SSR-решение SolidStart пока не достигло зрелости Next.js или Nuxt. Разработчики сообщают о проблемах с гидратацией и других сложностях при работе с серверным рендерингом.

Обзор Qwik

Qwik — это проект Мишко Хевери (создателя Angular). Идея фреймворка заключается в возможности возобновить работу приложения на клиенте без повторного выполнения кода, который уже был выполнен на сервере.

В Qwik радикально решили проблему гидратации — полностью отказались от неё. Время до интерактивности (TTI) падает в разы. Пользователь может кликать на кнопки сразу после загрузки HTML, без ожидания разогрева всего приложения.

Qwik автоматически разбивает код на мелкие чанки и загружает их только при необходимости. Символ $ в коде указывает на границы ленивой загрузки.

Плюсы Qwik

👍 Мгновенная загрузка

Практически нулевой JavaScript при первоначальной загрузке, следовательно отличные показатели Core Web Vitals.

👍 Автоматическая оптимизация

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

👍 Знакомый синтаксис

👍 Спасибо за SEO

Быстрая загрузка улучшает ранжирование за счёт полноценного SSR из коробки.

Минусы Qwik

👎 Молодая экосистема

Ограниченное количество библиотек, мало готовых решений и компонентов. Небольшое сообщество разработчиков (если сравнивать с React/Vue).

👎 Кривая обучения

Придётся изучать новые концепции. Из-за ленивой загрузки усложняется отладка.

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

👎 Сложность интеграции

Трудно интегрировать существующие React/Vue компоненты и ограниченная поддержка сторонних библиотек. Скорее всего, придётся с нуля переписывать код существующего проекта.

Экосистема и готовность к продакшену

Если сравнивать с React, то экосистема — самое слабое место обоих фреймворков.

SolidJS имеет SolidStart — метафреймворк с роутингом, SSR и серверными функциями. Документация качественная, сообщество активное. Большинство React-библиотек можно адаптировать без особых проблем, для популярных UI-китов есть готовые порты.

Qwik развивается в связке с Qwik City, который покрывает типовые задачи веб-разработки. Builder.io активно инвестирует в экосистему, регулярно выходят обновления и новые интеграции.

Риски есть, но они управляемые. Меньший размер сообщества означает меньше готовых решений и ответов на Stack Overflow. Если не боитесь изучать новое, то выигрыш в производительности перевесит неудобства.

Сравнение SolidJS и Qwik

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

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

Медиа, блоги с жёсткими требованиями к TTFB/TTI/INP будут лучше работать на Qwik. Пользователи смогут читать и скроллить без задержки. Интерактив добавляется дозированно — это лучшая стартовая стоимость.

E-commerce, каталоги с SEO и карточками рекомендуется разрабатывать на Qwik. Особенно если на главной тяжёлые модули, а клиенты приходят с поисковиков. Вы выигрываете у конкурентов буквально на первом взаимодействии.

Сложный SPA или дашборд с живыми виджетами и апдейтами будет лучше работать на SolidJS. Точечная реактивность упростит жизнь и снизит цену апдейтов. Solid сияет в проектах, где происходят сотни мелких изменений в секунду.

Solid хорош для аналогов десктопных приложений в браузере — Figma, Miro. Здесь приложение загружается один раз, а потом работает долго и должно быть максимально отзывчивым. Также Solid будет хорош там, где важна плавность анимаций.

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

Оба фреймворка умеют SSR/SSG и стриминг. Solid снижает стоимость обновлений, Qwik — стоимость старта. Для LCP/TTI/INP в контентных сценариях выигрывает Qwik. Для интенсивных интерактивных сценариев Solid удерживает FPS и снижает CPU.

Оба дружат с серверными платформами. SolidStart имеет адаптеры для Vercel/Netlify, Qwik City — тоже.

Выбирайте Solid.js, если вы создаете сервис, куда пользователь заходит надолго, и ему важна отзывчивость после загрузки. Выбирайте Qwik, если вы создаете сайт, куда пользователь приходит за контентом, и важно показать ему этот контент мгновенно.

Немного выводов:

• Solidjs быстрее Qwik при рендеринге. Qwik быстрее Solidjs при загрузке страниц.
• У Solidjs документация лучше, чем у Qwik.
• С нуля код на Qwik писать проще и быстрее, чем на SolidJS.
• Typescript в SolidJS может быть головной болью, в Qwik об этом можно не беспокоиться.

Практические рекомендации по переходу на SolidJS и Qwik

1. Начните с аудита текущих проблем. Посмотрите метрики сайта: сколько времени занимает гидратация? Тормозят ли обновления интерфейса? Где именно проблема — на старте или в процессе работы?
2. Выберите изолированную часть проекта. Возьмите один виджет, одну страницу, один компонент и реализуйте его на новом фреймворке. Измерьте разницу в производительности и удобстве разработки.
3. Если проблема в медленной загрузке — попробуйте Qwik. Соберите прототип лендинга или каталога, включите SSG с resumability и протестируйте на медленном соединении.
4. Если проблема в тормозах интерфейса — попробуйте Solid. Перепишите самый страдальный компонент с частыми обновлениями, уберите мемоизации и посмотрите на результат.

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

Тенденция отказа от React/Vue

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

А вы что думаете? Готовы попробовать модные фреймворки SolidJS и Qwik в следующем проекте?