Вместе построим роутинг, который работает на ts. Не используя никаких сторонних библиотек, имея в руках только react-router-dom, соберем систему, при которой все параметры и урлы станут строго типизированными. Долой строки!

Многие фронтенд-разработчики сталкиваются с ощущением «карьерного потолка», достигнув уровня сеньора. Как выбраться из этого замкнутого круга и открыть для себя новые перспективы? В рамках доклада мы разберем, почему фронтендеры часто застревают на одном уровне, какие компетенции помогут вырасти в роли архитектора, Staff Engineer или даже Technical Fellow, и как сформировать собственную матрицу навыков для устойчивого профессионального роста.

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

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

Сложно найти того, кому ни разу не приходилось обвешивать страницу событиями веб-аналитики. Этот процесс, выполняемый по четко-выверенному ТЗ олицетворяет из себя рутину - 20+ пунктов, каждый описывает конкретное событие и payload.

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

Берем углубленные знания веб-технологий, добавляем щепотку react internals и заворачиваем в системный подход. И вот эта адская смесь уже готова отправлять все нужные события самостоятельно!

Методология DDD(Domain Driven Design) появилась достаточно давно, а в русскоязычном сегменте ИТ начала набирать популярность во второй половине 10х годов. Больше всего, конечно, эту методологию используют в бэкэнде, и даже считают, что в соответствии с этой методологией можно писать код.
Я хочу показать, что методология !== технология, и рассказать, как использовать DDD на фронтэнде, как сделать вашу жизнь в команде лучше, понятнее и дружнее с помощью небольшого изменения ментальных конструкций, которыми вы оперируете.

Как заставить команду писать красивый (поддерживаемый, понятный) код

1. Введение: зачем писать красивый код?
• Почему качество кода важно для команды и компании?
• Примеры проблем, которые возникают из-за разного кода.
• Краткий обзор инструментов и подходов.
• Почему стандартизация полезна для команды и компании?
2. Написание собственных правил для линтера
• Почему стандартных правил может быть недостаточно?
• Как писать собственные правила:
• - Примеры в rules для (ESLint).
• - Использование AST (Abstract Syntax Tree).
• Как внедрить собственные правила в проект.
3. SonarQube: мощный инструмент для анализа кода
• Что такое SonarQube?
• Какие метрики предоставляет SonarQube:
• - Code smells.
• - Уровень покрытия тестами (test coverage).
• - Технический долг.
• - Уязвимости и ошибки.
• Примеры пользы для бизнеса и разработчиков.
• Как подключить SonarQube к проекту:
• - Развертывание на сервере.
• - Интеграция с CI/CD.
• - Подключение к IDE.
4. Границы жесткости стандартов
• Можно ли запретить всё?
• Преимущества и недостатки жестких правил:
• - Упрощение онбординга новых разработчиков.
• Рекомендации: где стоит быть гибким, а где — строгим.
• Почему важно вовлекать команду в обсуждение стандартов.
5. Кейсы и примеры: демонстрация на практике
• Реальный пример линтера с кастомными правилами.
• Анализ реального проекта через SonarQube:
• - Выявление проблем.
• - Рекомендации по их устранению.
• Обсуждение: как это улучшило код и взаимодействие команды.
6. Заключение: путь к красивому коду
• Резюме: инструменты и подходы.
• Советы для внедрения:
• - Начните с небольших изменений.
• - Слушайте команду.
• - Делайте код-ревью частью культуры.

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

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

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

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

Обычно для реализации подобного поведения нам необходимо использовать JavaScript.

Однако теперь это необязательно благодаря новой фиче в CSS.

В докладе расскажу про CSS Anchor Positioning и как с его помощью упростить разработку связанных друг с другом элементов.

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

Хотите узнать, как искусственный интеллект может трансформировать работу фронтенд-разработчика? Этот доклад раскрывает, как ИИ помогает:

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

Я поделюсь реальными примерами использования инструментов вроде Cursor, Codeium и Windsurf, расскажу о внедрении ИИ в повседневные задачи и о том, как это уже меняет фронтенд. Также обсудим, зачем и как разворачивать модели on premise, их преимущества и недостатки.

Не справляетесь с безграничным потреблением ресурсов в NextJS при использовании картинок? Надежда на сообщество Open Source разработчиков фреймворка угасла? После этого доклада вы избавитесь от всех страданий!

Я расскажу, как мы столкнулись с утечками памяти в NextJS из-за модуля оптимизации изображений и первыми решили проблему, вызванную модулем оптимизации изображений. Мы прошли весь путь от локализации проблемы до разработки open source решения и разработали утилиту next-image-cache-cleaner, которую вы можете переиспользовать у себя. В ходе доклада вы научитесь:

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

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

Поговорим о подходе с использованием инструмента TRPC https://trpc.io/, почему данный подход удобен, что такое End-to-end typesafe API. И как сделать свой собственный провайдер который позволит шарить логику в рамках проекта.

Введение в проблему
1. Дублирование кода
2. Сложность типизации REST
3. Интеграция с разными провайдерами БД

Архитектура пакета
1. tRPC-роутеры
2. Абстракция над БД
3. Zod-валидация

Преимущества подхода
1. Единая кодовая база
2. Автоматическая типизация
3. Гибкость (БД провайдеры)
4. Меньше boilerplate-кода

Пример приложения
1. Приложение Express + React SPA
2. Прототипирование

Ограничения и подводные камни
1. Не подходит для публичных API
2. Привязка к TypeScript
3. Сложности с кэшированием

Заключение
1. Упрощаем жизнь разработчикам
2. tRPC — это не замена REST
3. Ссылка на GitHub

Поговорим о пути создания интерфейса от момента MVP до запуска полноценного проекта. О том, когда нужно использовать библиотеку стилей и компонентов из open-source, а когда пилить своё. Если делаете своё, то как настроить флоу так, чтобы разработка нового не ломала старое. А если проектов много, но они плюс-минус одинаковые? А если у заказчика строгий брендбук и жёсткие правила? Можно ли брать готовую библиотеку или надо пилить что-то своё?

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

В докладе я покажу, как готовить и подключать на сайт шрифты, что умеет CSS для работы с типографикой и почему для Core Web Vitals так важно работать со шрифтами правильно.

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

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

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

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

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