Yandex for Frontend
Канал для фронтендеров от Яндекса. Рассказываем о мероприятиях для фронтендеров и любителей красивых и функциональных интерфейсов, делимся экспертизой. Чат: https://t.me/yalovefrontend Каналы Яндекса про разработку: https://t.me/addlist/Hrq31w2p1vUyOGZi
Show more📈 Analytical overview of Telegram channel Yandex for Frontend
Channel Yandex for Frontend (@yandex4frontend) in the Russian language segment is an active participant. Currently, the community unites 10 886 subscribers, ranking 10 977 in the Technologies & Applications category and 58 697 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 10 886 subscribers.
According to the latest data from 09 September, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -32 over the last 30 days and by -1 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 29.95%. Within the first 24 hours after publication, content typically collects 13.83% reactions from the total number of subscribers.
- Post reach: On average, each post receives 3 260 views. Within the first day, a publication typically gains 1 505 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 11.
- Thematic interests: Content is focused on key topics such as интерфейс, yandex, typescript, css, фронтендеров.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Канал для фронтендеров от Яндекса. Рассказываем о мероприятиях для фронтендеров и любителей красивых и функциональных интерфейсов, делимся экспертизой.
Чат: https://t.me/yalovefrontend
Каналы Яндекса про разработку: https://t.me/addlist/Hrq31w2p1vU...”
Thanks to the high frequency of updates (latest data received on 10 September, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
Потом я создал три новых навыка AI-агента. И выложил их на GitHub: 🟡 compile — обрабатывает заметки из inbox по моим правилам ведения базы и обновляет AI Wiki 🟡 vault-health-check — быстрая проверка. Чинит сломанные ссылки, заметки без ссылок, устаревшие заметки, незакоммиченные изменения. Полезно запускать после ручных правок 🟡 deep-audit — глубокий аудит заметок: структура, связи, валидность утверждений и ссылок на источники🔜 Как с этим работать? Я прошу агента искать ответы в первую очередь в базе. И при необходимости собирать ответ в новую заметку. Например, спрашиваю: «Какие есть лучшие практики использования AI при разработке ПО?» Получаю суммаризацию статей и собранные вместе мысли из evergreen notes. Такой конспект можно быстро прочитать и провалиться глубже по ссылкам. Если информации в базе не хватило, прошу собрать дополнительные материалы и ссылки из моих источников. Сохраняю, компилирую, уточняю. И так по кругу 🙂 🔜 Что получилось в результате? 🟡 Я обработал весь накопившийся за годы текстовый бэклог, свыше 250 источников 🟡 Разобрался в темах, до которых не доходили руки: geospatial AI, тренды по AI в разработке, паттерны агентных систем 🟡 База стала не просто архивом ссылок, а рабочим инструментом. Теперь не нужно вспоминать, где именно видел нужную мысль. Достаточно задать вопрос агенту и провалиться в источники В итоге мне зашло. Я наконец-то разгрёб старые запасы ссылок, оставленных на потом, и создал процесс, в котором база знаний не просто копится, а сама помогает думать. Промпты, формат заметок и audit-сценарии я ещё дорабатываю. Но направление выглядит очень перспективным. Подписывайтесь: 💬 @Yandex4Frontend
Меня зовут Женя Успенский, я руковожу разработкой фронтенда в Яндекс Трекере и отвечаю за архитектуру платформы плагинов. Это отдельный механизм, который позволяет без навыков кодинга расширять Трекер собственными модулями без модификации его ядра.Хочу рассказать, как построить безопасную экосистему плагинов: изолировать сторонний JavaScript, организовать взаимодействие с API и при этом сохранить удобный Developer Experience. 🤯 Когда мы задумали дать пользователям возможность писать свой код прямо внутри Трекера, первая реакция команды безопасности была: «Вы что, с ума сошли?» И ребят можно понять. Пустить сторонний JavaScript в B2B-продукт с чувствительными данными — это прямой путь к XSS, вытаскиванию токенов и утечкам. Поэтому нам нужна была архитектура, которая позволит создавать сложные интерактивные плагины с динамическим UI, но при этом упакует их в железную изоляцию. 🈶 Как мы изолировали код Взвесив все за и против, остановились на классической изоляции через
iframe. Это решение выглядит не так концептуально, зато даёт гарантии безопасности и позволяет быстро выйти в продакшен.
Как это устроено:
🟡 Каждый плагин отдаётся с отдельного изолированного хоста, у которого нет доступа к cookie и хранилищу основного приложения
🟡 В параметрах iframe мы явно разрешаем только выполнение скриптов (allow-scripts) и жёстко ограничиваем все остальные возможности
🟡 Политика безопасности запрещает практически всё, в том числе сетевые запросы на любые внешние адреса, которые отличаются от собственного домена iframe
Все ключевые модули получившейся системы мы оформили как самостоятельные, независимые пакеты. Это позволяет подключать к платформе плагинов любые другие сервисы и не переписывать архитектуру изоляции с нуля. А общение плагина с сервисом и внешним миром происходит через специальный объект Bridge, который для транспорта использует postMessage.
✨ Мы хотели дать авторам плагинов хороший Developer Experience: строгую типизацию, автокомплит параметров в IDE и подсказки, но стандартные пути нас не устраивали. Поэтому мы нашли решение на стыке возможностей TypeScript-типов и объекта Proxy.
🈶 Что мы сделали
Мы отказались от генерации JS-кода в пользу генерации исключительно TypeScript-типов (.d.ts) напрямую из нашей OpenAPI-схемы. А вместо абстрактных имён методов мы стали использовать нативные REST-пути в виде строковых литералов. Синтаксис вызова API в нашем SDK выглядит так:
const issue = await sdk.api.v3.get['/issues/{id}']({
path: { id: 'QUEUE-123' },
query: { expand: 'comments' }
});
Когда разработчик пишет sdk.api.v3.get[ и ставит открывающую кавычку, TypeScript воспринимает это как обращение к свойству огромного интерфейса. Благодаря этому движки автокомплита и в VS Code, и в WebStorm моментально выводят список всех доступных эндпойнтов. И самое главное: IDE показывает полную JSDoc-документацию прямо во время набора строки.
Весь рантайм-роутер умещается буквально в 10 строк благодаря ES6 Proxy. Так что в исполняемом JS-файле нашего SDK нет ни одного упоминания эндпойнтов.
➡️ Читайте все подробности в статье на Хабре. Там я рассказал, как работает платформа плагинов и как мы тестировали её внутри Яндекса. А также поделился тем, что ещё есть под капотом нашего механизма.
Подписывайтесь:
💬 @Yandex4Frontend{flag_something}, где something — искомый флаг. Для решения большинства наших задач игрокам нужны знания фронтенда, сетей и инструментов разработки.
🈶 С чего всё начиналось
Нам хотелось делать классный онлайн: что-нибудь запоминающееся и выделяющееся. Так в 2021 году небольшая команда из трёх человек за две недели собрала полноценную CTF-игру с различными по сложности заданиями. В итоге у нас получилось 17 флагов, 8 уровней, 384 прохождения игры и один уютный чатик.
В 2022 году мы переписали движок и добавили номинации, в 2023-м — обзавелись собственной игровой вселенной и определились с визуальным стилем, в 2024-м — отправили героев в космос. А в этом году мы снова обновили сценарий и движок, чтобы ещё сильнее мотивировать участников исследовать мир.
🈶 Как придумываем задания
Мы собираем идеи заранее: в течение года находим странное и интересное, например особенности браузера, новые фичи CSS, необычные демки с CodePen и так далее. Потом для каждого задания пишем пояснение, как с ним работать.
До игры мы прорешиваем задачи самостоятельно и силами сторонних участников. В итоге у нас получается список заданий, которые отранжированы по сложности. Дальше остаётся только встроить их в игру без конфликтов с основным сюжетом.
➡️ В статье на Хабре я рассказал больше подробностей о том, как мы развиваем игру (и при чём тут Мона Лиза). А ещё поделился примерами заданий прошлых CTF.
Подписывайтесь:
💬 @Yandex4Frontendintl-push:
title: Intl Push
triggers:
- on: commit
into: trunk
max-active: 1
flow: intl-push
Скрипт проходит по изменениям в PR, находит добавленные ключи и формирует из них список. Затем для каждого воркспейса запускает команду, которая отправляет все ключи из кода в TMS, и туда же попадают новые. Свежие ключи улетают через API в систему управления переводами.
Но отправка ключей — полдела, нужно ещё забирать готовые переводы обратно в код. Поэтому ровно в 05:00 по Москве запускается cron-job:
intl-pull:
title: Intl Pull
flow: intl-pull
max-active: 1
schedule:
timezone: MSK
cron: 0 5 * * *
Скрипт выкачивает переводы для всех 27 языков, раскладывает данные по файлам локализации в репозитории и сам создаёт Pull Request с изменениями. И, если тесты проходят, отправляет его на автоапрув.
🧽 А ещё мы добавили в CI дополнительную проверку на дубликаты, чтобы нельзя было случайно слить два PR с одинаковыми ключами.
⏮ В рамках проекта мы сделали дашборд, который помогает нам узнавать статус перевода на конкретный язык. В нём видно всё: синие столбцы означают ключи, у которых задача есть, а красные, что её нет. Если графа какого-то языка внезапно покраснела на 30%, мы сразу понимаем, что кто-то влил крупную фичу, а переводы застряли. Поэтому можем среагировать до того, как это заметит пользователь.
❗️ У нас есть правило: фичу открываем на конкретную страну только после появления переводов на нужный язык.
Английский и русский обязательны всегда. Если фича нужна только в России, она открывается только для российских парков. Если нужна на зарубежные рынки, то ждём, пока переводы доедут. Дашборд позволяет отслеживать этот момент в реальном времени.
🈶 Какую проблему подсветила автоматизация
Когда вы удаляете React-компонент — вы устраняете вызов <Message>. ID исчезает из кодовой базы, но в TMS он остаётся.
Мы тратили ресурсы на хранение того, что пользователь никогда не увидит. И на момент аудита в TMS накопилось около 4–5 тысяч таких ключей-призраков. Но у нас уже давно есть скрипт, который сравнивает слепок ключей в коде со слепком в TMS, поэтому их можно постепенно удалять.
🈶 Как мы сэкономили рабочее время
В среднем разработчики раньше заводили 2,5 задачи на перевод в день, тратили около 2 минут на каждую и 15 минут на обновление файлов. Это 20 минут ручной работы на команду ежедневно — достаточно, чтобы выбить из рабочего потока. Теперь всё это делает CI.
💡 И мы можем гарантировать: если код в мастере сегодня, перевод будет на проде через N дней. Менеджеры планируют маркетинговые запуски и релизы в новых странах с точностью до дня.
➡️ Читайте все подробности в моей статье на Хабре. Там я рассказала, как мы жили до появления автоматизации и как устраняли накопившийся лингвистический долг, чтобы насладиться её результатами. А также поделилась метриками и задачами на будущее.
Подписывайтесь:
💬 @Yandex4Frontend@media. Она позволяет интерфейсу адаптироваться под предпочтения конкретного пользователя: настроить тёмную тему, прозрачность, контрастность, включить или отключить анимации.
✨ Больше о @media в Доке
А на конференции «Я 💛 Фронтенд» Роман поделился и другими фичами, с которыми можно строить по-настоящему адаптивные интерфейсы. Этот подход отходит от классических вьюпортов и брейк-пойнтов: ключевую роль в нём играет контекст и окружение компонента.
➡️ Смотрите полный доклад на ютубе и в VK Видео.
Подписывайтесь:
💬 @Yandex4Frontend