Senior Frontend Engineer
10 лет в вебе · Vue 3, Nuxt, TypeScript · full-stack — от данных до интерфейса
Помогаю командам строить интерфейсы, которые остаются понятными по мере роста сложности — и которые не страшно менять.
Понятно, масштабируемо, надёжно.
Делаю интерфейсы, которые выдерживают рост продукта. Главный принцип — меньше скрытой логики, понятные состояния, строгие типы, предсказуемое поведение. Такой код легко читать, безопасно менять и просто передать другому разработчику.
От фронтенда — к продукту.
Десять лет делаю веб-продукты, сейчас — на Vue 3, Nuxt и TypeScript. Умею собрать интерфейс с нуля и разобраться в большом чужом проекте. Когда нужно — закрываю и бэкенд, и деплой: от базы данных до работающего сайта.
- Продуктовые SPA с нуля — Vue 3, Nuxt, TypeScript
- Фронтенд-архитектура: feature-based / FSD, проектирование под рост
- Типизированные границы данных: Zod, схемы, адаптеры API
- Дизайн-системы и компонентные библиотеки на Storybook
- Сложный интерактив: canvas, карты (Cesium, Mapbox GL), графики
- Функциональный подход: Effect‑ts, Elm, Haskell
- Деплой и self-hosting: собственный managed-сервер, Docker, nginx
Htracker — трекер здоровья пациента
Личный кабинет здоровья: ежемесячные снимки показателей, обследования и анализы, связка пациент — доктор и небольшая админка. Бэкенд на FastAPI + PostgreSQL по DDD, фронт на Vue 3. Развёрнут на собственном сервере.
Booking widget — один виджет, три системы типов
Виджет бронирования отеля, написанный трижды. База — Vue 3 + TypeScript с 13 «дырами в корректности», затем тот же виджет на Effect-TS и Elm — и подсчёт, сколько дыр каждая система типов закрывает структурно.
De Prado — finance in ML as explorable knowledge
Интерактивный конспект книги по financial ML: вместо пассивного чтения — «островки», с которыми можно играть и проверять идеи. Astro с интерактивными виджетами на Elm.
Как я проектирую интерфейсы.
Цельной методологии у меня нет — есть устойчивый вектор. Начинаю не с экранов, а с того, из чего они собираются: какие у интерфейса единицы, в каких они состояниях и где проходит граница между фронтендом и бэкендом.
Компонент — единица смысла, а не разметки
Компонент существует не потому, что «тут нужен ещё один блок», а потому что отвечает за конкретный смысл: карточка, поле, состояние загрузки. Тогда экран собираешь из понятных кубиков — и интерфейс остаётся предсказуемым по мере роста.
Тонкий UI, умный бэкенд
В интерфейсе не должно быть много логики. Домен и бизнес-правила живут на бэкенде; задача фронтенда — честно отрисовать состояние и передать намерение пользователя.
Вектор, а не догма
Свои принципы я не считаю застывшими — они ещё формируются. Направление устойчивое: меньше неявного состояния, больше явных границ и типов, функциональный подход там, где он окупается.
О ремесле и о том, куда оно движется.
Короткие тексты о фронтенд-разработке: как я работаю с ИИ, что понял про дизайн-системы и каким вижу будущее профессии.
ИИ в разработке — год спустя
Почти год я пишу код вместе с ИИ. Главное, что я понял: он умножает того, кто понимает, что делает, — и так же быстро умножает того, кто не понимает.
Дизайн-система, которая доживает до второго проекта
Дизайн-систему легко начать и трудно сохранить. Я поднимал их несколько раз — и почти всё ценное узнал из того, что не получилось.
Фронтендер через десять лет
Я думаю, профессию ждёт трансформация: фронтенд-разработчик станет UX/UI-инженером, который держит интерфейс и продукт в одной голове. И мне такое будущее скорее по душе.
Открыт к интересным задачам.
Ищу место, где можно заниматься продуктом целиком — интерфейсами и тем, что за ними. Интересны сложные продуктовые задачи, где важны архитектура, типобезопасность и аккуратный UX. Пишите в Telegram или на почту — отвечаю быстро.