Frontender's notes [ru]

IT остается самым востребованным направлением для старта карьеры

Так показало исследование Changellenge. Best Company Award проводится уже в одиннадцатый раз на основе опроса 9 тысяч студентов и выпускников с высоким потенциалом. Главное:
— В IT-сфере самые популярные профессии — дата-аналитик, бизнес-аналитик и AI-разработчик.

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

— Помимо IT, молодых специалистов также привлекают менеджмент, маркетинг и финансы.

xCode Journal

Северокорейские хакеры из Lazarus Group вышли на новый уровень

Теперь они заражают разработчиков не через сомнительные ссылки, а через функции самого VS Code. Как работает схема:
— Вам пишет «рекрутер» с жирным оффером мечты в крипто-проект;
— Просят склонировать репозиторий с GitHub, чтобы «пофиксить баг» или «оценить код»;
— Вы открываете папку в VS Code, и редактор спрашивает: «Do you trust the authors?». Как только вы жмете «Yes» — маховик заражения запущен.

В папке .vscode лежит файл tasks.json с параметром runOn: folderOpen. В ту же секунду, как вы открыли проект, VS Code в фоне запускает вредоносный скрипт.

xCode Journal

Memory leaks в браузере: реальные примеры из жизни

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

Неудалённые event listeners

Классика жанра — добавили обработчик событий через addEventListener, но забыли удалить его через removeEventListener. Особенно больно это сказывается в SPA, где компоненты монтируются и анмонтируются постоянно. Узел DOM удалён, а вот ссылка на него всё ещё висит в памяти. Это приводит к её утечке, и рано или поздно начинаются проблемы с производительностью.

Таймеры и интервалы

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

Замыкания, которые не отпускают

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

Detached DOM nodes

Одна из самых неприятных утечек. Это когда DOM-нода вроде бы удалена со страницы, но из JS на неё всё ещё есть ссылка. В DevTools можно увидеть такие ноды как Detached HTMLDivElement. Это часто происходит, когда вы работаете с DOM напрямую или используете сторонние библиотеки. При этом браузер думает, что элемент ещё на странице, и не освобождает память.

Кэши без очистки

Сетку данных или просто в память — встраиваем кэш, чтобы «ускорить» работу приложения, но забываем о сроках жизни данных. Сет, мап, in-memory cache. Всё это растёт линейно со временем работы приложения, если нет стратегии очистки. Особенно часто это встречается в data-layer или при оптимизациях, где забывают про TTL (Time To Live) или лимиты на размер кэша.

Глобальный стейт как свалка

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

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

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

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

Frontender's notes

Когда useMemo и useCallback делают только хуже

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

Оптимизация, где её нет

Начнём с того, что если компонент и так рендерится быстро, то использовать useMemo не имеет смысла. Эти хуки добавляют ненужную работу: React всё равно должен хранить зависимости, сравнивать их и поддерживать ссылки в памяти. А для чего? Чтобы оптимизировать то, что и так работает нормально? Это самый популярный антипаттерн, с которым сталкиваются почти все фронтендеры.

Мелкие вычисления — не повод для мемоизации

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

«useCallback ради useCallback»

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

Нестабильные зависимости

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

Ломается читаемость

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

Иллюзия оптимизации

Самая опасная ошибка — это когда вы начинаете думать, что «всё оптимизировано», потому что начали использовать useMemo и useCallback везде. Но настоящие проблемы обычно кроются в лишних рендерах из-за стейта, тяжёлых эффектах, layout thrashing и, конечно же, неправильной архитектуре компонентов. Эти проблемы не решаются хуками.

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

Frontender's notes

Фронтендеры, забираем

Это огромный репозиторий с классными анимированными иконками, которые постоянно пополняются.

И да — всё опенсорс, так что смело можно использовать в своих проектах.

xCode Journal

Исследователи разослали 37 000 фейковых резюме выпускников и посмотрели, кого чаще зовут на интервью

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

— Учёба за границей ожидаемо также повышает шансы найти быстро свою первую работу.

— Программирование + анализ данных дает жирный плюс к коллбэкам. При этом по отдельности эти навыки эффекта не имеют.

xCode Journal

AIKit: библиотека интерфейсов для ИИ-ассистентов на базе Gravity UI

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

Что такое AIKit:
AIKit — это набор React-компонентов, хука и утилит, который позволяет собрать интерфейс чат-ассистента за пару дней.
Он не зависит от конкретного провайдера ИИ (OpenAI, YandexGPT и др.) и подходит для любых сценариев общения с моделью.

Основные принципы архитектуры:
• Atomic Design — компоненты собраны по уровням (атомы, молекулы, страницы), легко переиспользуются.
• SDK-agnostic — логика UI не привязана к конкретному API.
• Типизированные сообщения — user, assistant, tool, thinking и свои кастомные типы.
• Темизация и локализация встроены из коробки.
• Доступность — поддержка ARIA, навигация с клавиатуры, визуальные тесты через Playwright.

Как работает AIKit

UI принимает данные извне, поэтому состояние можно хранить в React State, Redux или MobX. Для типовых задач есть готовые хуки:

useSmartScroll() // умная прокрутка истории
useDateFormatter() // форматирование дат сообщений
useToolMessage() // обработка сообщений-инструментов

AIKit делает разработку ассистентов не просто быстрой, а единообразной.
Теперь у ИИ-чатов Яндекса — один язык интерфейса и одна база компонентов.

Frontender's notes

Feature-based vs Layered архитектура: что выбрать для фронтенда?

Когда вы начинаете проект, всё кажется довольно простым. Но потом начинаются проблемы. Архитектура фронтенда может быть выбрана так, что она сначала удобна, а потом превращается в настоящую головную боль. Сегодня давайте разберёмся, чем отличается feature-based подход от layered архитектуры и где каждый из них действительно работает.

Layered архитектура

Layered архитектура — это та самая классика, с которой все когда-то начинали. Всё в проекте делится на слои: компоненты, сервисы, store, api и утилиты.

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

• Пример, который я часто встречаю: добавление функционала «избранного». UI живёт в папке components, запросы — в api/favorites, а состояние в store. Функция вроде как есть, но она размазана по всему проекту, и найти все её части в одном месте просто невозможно.

Feature-based архитектура

В feature-based архитектуре всё куда проще: каждый функционал — в своей папке. Структура выглядит примерно так:

/features
/favorites
ui/
api/
model/
lib/

• Здесь вся фича собрана в одном месте: UI, API и модель. Это даёт отличный контроль за кодом, упрощает рефакторинг и удаление функций, и делает работу с фичами понятной и изолированной. Всё, что связано с конкретной фичей, будет в её папке, и даже если вам нужно её удалить — вы просто стираете папку. Меньше глобального шума и больше порядка.

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

Как это выглядит на практике?

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

• Такой подход позволяет сбалансировать бизнес-логику и не превращать папку shared в помойку, сохраняя возможность масштабирования.

• Когда стоит выбрать какой подход? Если проект маленький, срок жизни короткий и работает 1-2 человека, то layered будет вполне хорош. Но если продукт живёт долго, несколько команд работает над ним, а фичи часто меняются — feature-based будет предпочтительнее.

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

Frontender's notes

Иногда кажется, что свободного времени просто нет: одни встречи, задачи и бесконечные «срочно».

Но свободный слот всё-таки существует. Главное — провести его с пользой

«Свободный слот» — подкаст команды AvitoTech для IT-специалистов, которые уже работают в роли лидов или присматриваются к управленческому треку.

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

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

Если вы работаете в IT, управляете процессами и людьми (или только примеряете эту роль) — возможно, вам сюда.

«Свободный слот» от AvitoTech

Краткий словарь программистов подъехал

Срочно запоминаем определения микросервисной архитектуры и функций HR BP.

xCode Journal

Анализ производительности в Chrome DevTools: три ключевых инструмента для улучшения сайта

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

Coverage — что реально используется, а что зря грузится

Coverage поможет ответить на болезненный вопрос: какой код мы реально используем, а какой зря грузим. Этот инструмент покажет, сколько неиспользуемого JS и CSS находится в вашем проекте, а также какие файлы можно срезать без потери функциональности. Вы сразу увидите эффекты от code splitting и lazy-loading.

Типичные находки здесь:

• CSS, который давно не используется
• JS-бандлы, которые загружаются «на всякий случай»
• UI-киты, от которых используется лишь 10%

Performance Insights — почему страница ощущается медленно

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

Он выявляет:

• Длинные задачи на основном потоке
• Тяжелые обработчики событий
• Рендеры, которые можно было бы отложить

Lighthouse — взгляд с точки зрения пользователя и поисковиков

Lighthouse помогает понять, как ваш сайт воспринимается браузерами и Google. Он оценит Core Web Vitals, укажет на проблемы с доступностью и SEO, а также предложит рекомендации по улучшению.

Важно помнить:

• Результаты могут быть нестабильны, поэтому лучше запускать тесты несколько раз
• Lighthouse лучше использовать как ориентир, а не как точный KPI

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

Frontender's notes

Сложности организации новогоднего корпоратива:

xCode Journal

Новые относительные единицы CSS: Container Units для адаптивных интерфейсов

Адаптивность в CSS традиционно используют vw и vh для настройки интерфейса. Однако они неэффективны в сложных layout. Медиазапросы, хаки и проценты частично решают проблему. С появлением Container Queries и Container Units все эти сложности уходят в прошлое.

Что такое Container Units?

Container Units — это единицы измерения, которые рассчитываются на основе размеров контейнера, заданного с помощью container-type. Это позволяет нам работать с адаптивностью гораздо точнее и удобнее, учитывая реальные размеры компонента внутри его контейнера.

Вот основные из них:

• cqw — 1% от ширины контейнера
• cqh — 1% от высоты контейнера
• cqi — 1% от inline-размера контейнера (влияет на writing-mode)
• cqb — 1% от block-размера контейнера
• cqmin и cqmax — минимальные и максимальные размеры сторон контейнера

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

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

• Меньше медиазапросов
Вместо того, чтобы писать кучу медиазапросов, можно просто использовать @container + cqw — это позволяет сократить код и сделать его более читаемым.

• Меньше JS-хака
Не нужно больше считать размеры с помощью ResizeObserver, чтобы подстроить типографику или spacing. Всё это теперь можно делать прямо через CSS.

Важные нюансы

— Контейнер нужно обязательно объявить: container-type: inline-size.
— Эти единицы работают только внутри контейнера, так что не забудьте установить правильный тип.
— cqi и cqb особенно полезны, если вам нужно поддерживать вертикальный writing-mode или международные интерфейсы.

Когда стоит использовать Container Units?

— Дизайн-систем и reusable компонентов.
— Сложных layout’ов, таких как дашборды или редакторы.
— Микрофронтендов, где компоненты независимы друг от друга.

Примеры:

/* В этом примере размер шрифта для .card__title теперь будет зависеть от ширины контейнера .card, а не от ширины экрана. */
.card {
container-type: inline-size;
}

.card__title {
font-size: 4cqw;
}

/* Типографика */
.title {
font-size: clamp(16px, 3cqw, 24px);
}

/* Spacing */
.card {
padding: 4cqi;
}

.card {
padding: 4cqi;
}

Адаптивность на основе viewport — это вчерашний день. Container Units — это новый шаг в сторону компонентного мышления в CSS. Теперь ваш компонент не зависит от страницы и ведет себя предсказуемо. Это как если бы CSS стал умнее, а не сложнее.

Frontender's notes

OffscreenCanvas: как перенос рендера в Worker улучшает производительность

Когда речь идет о производительности фронтенда, проблемы часто не в медленном JS, а в главном потоке, который одновременно обрабатывает события, считает layout, рисует UI и рендерит canvas. OffscreenCanvas — это решение, которое позволяет вынести рендер в отдельный поток, освобождая основной поток и улучшая производительность приложения.

Что такое OffscreenCanvas?

OffscreenCanvas — это canvas, который не привязан к DOM. Его можно создать в основном потоке, передать в Web Worker и рисовать в нем без блокировки UI. Это позволяет главному потоку оставаться свободным для обработки событий, анимаций и рендеринга layout и paint, не тратя ресурсы на работу с графикой.

Когда стоит использовать OffscreenCanvas?

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

Почему это быстрее?

Главное преимущество использования OffscreenCanvas — это отсутствие блокировки главного потока. Canvas не будет блокировать reflow и repaint, что часто приводит к задержкам и просадкам FPS. Перенос рендеринга в отдельный поток позволяет добиться параллельного рендера и стабильного FPS, что особенно заметно на слабых устройствах.

Ограничения OffscreenCanvas

Стоит учитывать несколько ограничений. Во-первых, поддержка OffscreenCanvas ограничена браузерами: доступен в Chromium и Firefox, в Safari поддержка частичная с нюансами. Поэтому всегда стоит делать fallback на обычный canvas для несовместимых браузеров.

Во-вторых, работая с Worker, нельзя взаимодействовать с DOM напрямую — все данные нужно передавать через сообщения. Это требует изменения архитектуры приложения. Также стоит помнить, что отладка таких решений сложнее, так как логика рендера разбивается между потоками и не поддерживается в стандартных DevTools Canvas tab.

Когда не использовать OffscreenCanvas?

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

Как использовать OffscreenCanvas?

// Весь рендеринг происходит в отдельном потоке, и главный поток остается свободным для обработки UI и взаимодействия с пользователем.
// В основном потоке создаем обычный canvas и передаем его в worker:
const canvas = document.querySelector('canvas')
const offscreen = canvas.transferControlToOffscreen()
worker.postMessage({ canvas: offscreen }, [offscreen])

// В worker получаем canvas и начинаем рисовать:
self.onmessage = ({ data }) => {
const ctx = data.canvas.getContext('2d')
ctx.fillRect(0, 0, 100, 100)
}

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

Frontender's notes

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

xCode Journal

Intl API: Форматирование данных без лишних зависимостей

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

Как работать с Intl API

• Intl.DateTimeFormat — форматирование дат
С помощью метода Intl.DateTimeFormat можно легко форматировать даты в зависимости от локали и требований, однако важно помнить о нескольких моментах: указывайте формат явно, задавайте локаль первой строкой и учитывайте таймзоны, используя параметр timeZone: "Europe/Moscow".

• Intl.NumberFormat — числа, проценты, дроби
Intl.NumberFormat предоставляет удобные инструменты для форматирования чисел, процентов и дробей. Среди полезных опций можно выделить: стиль представления чисел в виде процентов (style: "percent"), компактное представление больших чисел (notation: "compact" → "12K"), всегда отображаемый знак числа (signDisplay: "always" → "+120"), а также возможность отключения группировки разрядов (useGrouping: false → убрать пробелы).

• Intl.NumberFormat для валют
Для корректного форматирования валюты используйте Intl.NumberFormat, применяя ISO-коды валют, такие как «USD», «EUR», «KZT». Это позволит избежать ручного форматирования и обеспечит единообразие представления денежных сумм. Для криптовалют можно использовать параметр currencyDisplay: «code», например, для «BTC».

• Intl.RelativeTimeFormat — «5 минут назад»
Для корректного отображения времени в пользовательском интерфейсе используйте Intl.RelativeTimeFormat. Удобно для таких целей, как время доставки, статус онлайн/офлайн или лента активности.

• Intl.ListFormat, Intl.DisplayNames, Intl.PluralRules
Intl.ListFormat — форматирует списки на разных языках. Intl.DisplayNames — позволяет локализовать языки, регионы и валюты. Intl.PluralRules — для правильных склонений в разных языках.

Примеры Intl API

// Intl.DateTimeFormat
const date = new Date();

const formatted = new Intl.DateTimeFormat('ru-RU', {
day: "2-digit",
month: "long",
year: "numeric"
}).format(date);

// "24 ноября 2025 г."

// Intl.NumberFormat
new Intl.NumberFormat('ru-RU', {
minimumFractionDigits: 2,
maximumFractionDigits: 2,
}).format(12345.678);

// "12 345,68"

// Intl.NumberFormat
new Intl.NumberFormat("ru-RU", {
style: "currency",
currency: "RUB",
currencyDisplay: "narrowSymbol"
}).format(1999);

// "1 999 ₽"

// Intl.RelativeTimeFormat
const rtf = new Intl.RelativeTimeFormat("ru", { numeric: "auto" });

rtf.format(-5, "minute"); // "5 минут назад"
rtf.format(1, "day"); // "завтра"

// Intl.ListFormat
new Intl.ListFormat("ru", {
type: "conjunction"
}).format(["HTML", "CSS", "JS"]);

// "HTML, CSS и JS"

// Intl.DisplayNames
new Intl.DisplayNames(["ru"], { type: "language" })
.of("fr"); // "Французский"

// Intl.PluralRules
const pr = new Intl.PluralRules("ru");

const map = {
one: "лайк",
few: "лайка",
many: "лайков"
};

map[pr.select(5)]; // "лайков"

При использовании Intl API в продакшне важно не смешивать форматирование в компонентах, а выносить всё в отдельный модуль, например, formatters.ts. Задавайте локаль заранее — из браузера, настроек или профиля. Для SSR передавайте локаль и временную зону с сервера. Кроме того, необходимо кэшировать Intl-объекты, создавая их один раз, а не в каждом рендере, чтобы оптимизировать производительность.

Frontender's notes

Хотите создать мини-соцсеть с нуля за один вечер?

На открытом вебинаре мы за 1,5 часа пройдём путь от пустой папки до приложения: старт через create-vue, сразу подключим роутинг, разберём компоненты, props, директивы и события. Добавим computed и хуки жизненного цикла, сделаем запрос к FakeAPI и выведем карточки пользователей.

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

Встречаемся 23 декабря в 20:00 МСК в преддверие старта курса «Vue.js-разработчик»: https://otus.pw/mGtR/

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, erid: 2VtzquyiDSS

Signals — будущее реактивности в фронтенде

Мы все давно привыкли к идее реактивности в UI, но в 2025 году я пришёл к выводу, что мы наконец-то пришли к нормальной, предсказуемой модели. Не к магии хуков и сложным эффектам, а к Signals.

Что такое Signals?

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

Почему это будущее?

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

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

Преимущества Signals:

• Работают без привязки к конкретным фреймворкам
• Подходят для использования в виджетах, Canvas/WebGL, Web Components, сервисах и сторах
• Могут применяться в Node.js

Где это уже используется?

Например, Angular 17+ предлагает полноценный «signal mode», SolidJS построен вокруг сигналов, Qwik использует fine-grained реактивность по умолчанию, React Canary работает над useSignal и «compiler-driven reactivity», а Vue 3 применяет концептуально похожие подходы с функциями reactive() и ref(). Это уже не эксперимент, а работающие решения в реальных продакшн-системах.

Когда стоит переходить на Signals?

Signals особенно полезны в больших приложениях с множеством локальных состояний, в формах, таблицах и фильтрах, а также в реальном времени и высокоинтерактивном UI (например, в Canvas, WebGL, играх). Стоит переходить на Signals, когда вы замечаете, что эффекты становятся громоздкими, стей-тлогика расползается и приложение ререндерится чаще, чем нужно — это поможет упростить код и повысить его производительность.

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

Frontender's notes

Anime.js

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

Она работает с CSS-свойствами, SVG, атрибутами DOM и JavaScript-объектами, что делает её универсальной для различных типов проектов. Репозиторий Anime.js полностью на английском, так что вам потребуется базовое знание языка или инструменты перевода. Но для современного разработчика это не должно стать препятствием — документация ясная и понятная, а сообщество активно поддерживает библиотеку. Anime.js позволяет анимировать различные элементы страницы с помощью простых команд.

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

Frontender's notes

 Новогодние стримы от SourceCraft!

Первый эфир пройдёт 18 декабря, второй — 23 декабря.

Эксперты Яндекса SourceCraft — Дмитрий Иванов, Сергей Бережной и Роман Елизаров разберут практические задачи и инструменты, которые можно применять в учёбе и реальных проектах.

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

Также эксперты раскроют все секреты по работе с кодом в SourceCraft — AI-native платформы для разработки любого масштаба — от сайтов, ботов и лабораторных работ до проектов с большой кодовой базой и командой специалистов!

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

Давайте готовиться к 2026 вместе!

Регистрация на эфир 18 декабря

 Регистрация на эфир 23 декабря

Лучшая страница 500 ошибки

xCode Journal

HTML в 2025: почему он снова в центре внимания

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

HTML становится умнее без JS
Ранее практически все действия на странице требовали подключения JavaScript. Сегодня же многое стало возможным непосредственно в HTML. Например, модальные окна можно создавать с помощью тега

, а аккордеоны — с помощью

. Для создания компонентов теперь можно использовать сочетание