Привет, Хабр!
Меня зовут Сергей Волков, я фронтенд-разработчик в компании VK. Мы используем MobX для работы с реактивными значениями в веб-приложениях, поэтому я хочу познакомить вас с этим инструментом и показать, почему на него стоит обратить внимание.
В этой статье я хочу поделиться своими мыслями о MobX - инструменте, который я искренне полюбил после многих лет разработки интерфейсов. Приятного чтения! :)
Данная статья может вызвать очень много баттхёрта в районе нижней точке у фанатов «прекрасной библиотеки» React.js просьба — уйти и не читать статью чтобы не повредить свою психику и сразу поставить дизлайк статье, комментарии ваши негативные я удалять не буду мне без разницы, это крик души и мой личный баттхёрт после продолжительной работой с этим и инструментом
Порядок выполнения реактивных реакций имеет свои особенности, которые часто оставляют на волю случая. Однако давайте рассмотрим все возможные варианты…
Работая с GitLab каждый день, повторяешь кучу одинаковых действий которые хотелось бы делать быстрее чем позволяет UI. Надоело, запилил Chrome-расширение.
В статье рассказываю как устроено внутри: авторизация через session cookies без токенов, цепочки действий в background worker, борьба с постоянно меняющимся DOM GitLab (Vue-миграция между версиями сломала все селекторы несколько раз).
Из фич: кнопки на MR странице (rebase, bump версии, auto-merge, ship), Jira-сайдбар прямо в GitLab, бейджи размера/конфликтов/тредов на списке MR, cherry-pick в несколько веток, command palette.
Когда шаблонных интерфейсов продукту становится недостаточно, его команда начинает задумываться о внедрении конструктора страниц. Пользователи получают свободу кастомизации, а количество запросов на доработки существенно сокращается.
Но за этими очевидными преимуществами скрывается ряд технических сложностей. Вместе с гибкостью приходят конвертации, конфликты конфигураций, рост стоимости поддержки и потеря контроля над пользовательским интерфейсом.
В этой статье я от лица разработчика платформы событий Saby Meet расскажу о том, как мы внедряли механизм конструирования страниц, с какими ограничениями столкнулись и почему главным вызовом для нашей команды стала не реализация решений на конструкторе, а борьба с хаосом, который неизбежно пришёл в наши лендинги вместе с гибкостью.
Мы в стартапе ArcFront три недели двигались в совершенно неправильном направлении, пытаясь подружить современный React с 20-летним Redmine через сложный BFF-прокси. Рассказываем историю нашего провала, неожиданного архитектурного озарения и того, как мы выкинули две недели работы и заменили их 15 строками кода.
Вы запустили продукт, вложили в него месяцы работы и деньги. А потом обнаружили, что конкурент выпустил почти точную копию — тот же интерфейс, та же логика, иногда даже те же баги. Что делать?
Эта статья — практический алгоритм. Разберём, как зафиксировать нарушение, какие способы защиты существуют, чем отличается путь через суд от пути через ФАС, сколько это стоит и сколько длится, какие дела уже прошли через суды и как не оказаться в роли нарушителя самому.
TL;DR. Две нейросетевые задачи — удаление фона (ONNX Runtime Web + модель silueta) и замазывание лиц (MediaPipe Tasks Vision + BlazeFace) — запущены полностью на клиенте: ни один пиксель не уходит на сервер. Ниже — почему «в браузере», какие модели выбраны и почему, как тянуть 43-мегабайтную модель с прогресс-баром, почему лица лучше пикселизировать, чем размывать, и подробный разбор бага, на который я убил вечер: Service Worker, кэширующий .mjs/.wasm, ломает dynamic import() с ошибкой «Failed to fetch dynamically imported module».
Как создавать веб-страницы без фреймворков, сборщиков и другого зоопарка. Технология Custom Elements появилась в браузерах в 2018-2020 годах, но долгое время незаслуженно обходилась стороной сообществом, в связи со сложностью разработки компонентов. Однако ничто не мешает использовать уже созданные компоненты с любым фреймворком. Об этом и пойдёт речь.
Это не разбор, не рекомендация, а скорее ценный опыт фронтовой команды с полей российского IT. Все что описано ниже — общий результат нашей работы.
Перед любой командой со стороны менеджмента и бизнеса стоит одна и та же задача «давайте быстрее — надо было еще вчера». Нас эта судьба также не миновала. Первое, с чего начинается оптимизация, своя дизайн‑система. У нас уже была своя дизайн‑система, она выручала нас во многих кейсах, но она была старая, подходы к разработке давно изменились, и UI Kit уже не отвечал требованиям. Поэтому было принято решение параллельно разрабатывать новую, с учетом всех последних требований и подходов.
Переезд не должен доставлять проблем и быть плавным. План такой: разрабатываем новый компонент, тестируем его, и как только результат радует, старый удаляем и внедряем новый. И так до тех пор, пока не останется ни одного старого компонента.
Разработка имеет такую очередь: архитектурно наш UI Kit лежит в закрытом artifactory npm пакетом. Также есть шаблон со всеми необходимыми зависимостями и UI Kit«ом. Когда приходит время нового проекта, делается fork заготовки. Это дает быстрый старт.»
Начинаем
Давайте посмотрим, как бы начиналась разработка приложения. Возьмем для примера компонент Select. Не будем писать сами, возьмем Antd Select и через обертку emotion стилизуем его под корпоративные стили.
Структура получится такая:
Я хотел просто повторить одну обложку в разных сервисах. Но быстро выяснилось, что сама PNG-картинка — только середина пути. Главное начинается дальше: как подставить новый заголовок, куда сохранить файл и кто в итоге пропишет правильный og:image в WordPress.
В версии tcl/tk-9.0 добавлена возможность создавать изображения image из SVG-файлов (а значит и сохранять их в png-формате). Всё было хорошо до тех пор пока мне для статьи на сайте Tcler's Wiki ни потребовался флаг США для кнопки переключения языка интерфейса:
Месяц назад я уволился из аутсорса и решил, что найду работу за 2–3 недели. Три года опыта, фуллстек, React + Node, пара нормальных проектов в портфолио. Казалось бы — садись и выбирай.
Через 4 недели у меня было 15 собеседований, 2 оффера, 6 молчаний без ответа и один рекрутер который прислал отказ на вакансию на которую я не откликался. Записывал всё в заметки потому что к 10-му собесу уже начал путать компании. Вот что получилось.
Когда маркетологи хотят всё: сырые данные в GA4, запись сессий в Метрике, хитмапы в Clarity и при этом «Lighthouse 100» в PageSpeed Insights — приходится изобретать. Расскажу, как мы это сделали на небольшом проекте и во что это обошлось по времени и нервам.
Проект — нишевый агрегатор российских хостинг-провайдеров. Более 120 страниц в sitemap, 31 статья, десятки категорий услуг, живые цены, сравнения. Стек: Astro 6 + Strapi 5 + Tailwind 4, плюс Partytown, PostgreSQL, Nginx и обычный VPS на Ubuntu. Сайт собирается в статику во время билда, никакого SSR в рантайме нет.
На desktop — Lighthouse 100 / 100 / 100 / 100. На mobile с жёстким throttling (4x slow CPU) — 99 / 100 / 100 / 100. В реальных условиях и по Chrome UX Report — 100 везде. LCP на desktop — 0,5 секунды, на mobile throttled — 1,7 секунды. CLS — ноль. TBT — 10 ms на мобильном и 0 ms на десктопе.
В этой статье расскажу о свежем баге, который ронял один тип транзакций, пока остальные работали штатно. Если используете @formatjs/intl-durationformat для форматирования времени - этот кейс может сэкономить пару часов отладки.
Я уже год пощу отдельные промпты в свой Telegram-канал. По просмотрам они стабильно обгоняют всё остальное — кейсы с цифрами, разборы инструментов, личные истории. Просто промпты в два раза популярнее.
Видимо, людям не очень интересно читать про нейросети. Им интересно взять что-то готовое и сразу проверить.
Поэтому собрал семь промптов, которые я использую в реальной работе. Не концепция «как ИИ меняет маркетинг». Конкретный набор инструментов под конкретные задачи: бриф, анализ аудитории, конкуренты, стратегия, аудит сайта, аудит рекламы, таблица гипотез.
Всё это проверено на реальных проектах агентства. Где-то экономит несколько часов, где-то — неделю. Один промпт (анализ конкурентов через Perplexity) однажды нашёл конкурента, которого я за два года не замечал. Немного стыдно, но факт.
Миграция большого legacy-проекта с Vue 2 на Vue 3 — это не только про код. Основная сложность начинается ещё до первого коммита: оценка объёма работ, поиск несовместимых API, планирование и организация процесса разработки.
Почему вообще это важно, и как донести эту мысль до бизнеса я уже описывала в другой своей статье «Ты всё ещё думаешь или уже мигрируешь на Vue 3». Рекомендую почитать.
А тут я поделюсь своим опытом, где мне пришлось лидировать миграцию: самостоятельно составлять план миграции, оценку времени, рисков и проводить саму миграцию.
Большой обзор, из которого вы узнаете, какие движки сайтов представлены на рынке миниатюрных CMS по состоянию на июнь 2026 года.
Когда проект на Next.js только начинается, прямой fetch во внешний API кажется самым коротким путём. Есть страница списка, есть поиск, есть внешний источник данных, значит можно сходить туда напрямую и сразу показать результат.
На маленьком экране это работает. Но дальше почти всегда начинаются одинаковые проблемы. Интерфейс начинает зависеть от чужой структуры ответа. Ошибки приходят в форме, которую неудобно показывать пользователю. Параметры запроса приходится валидировать в UI. Потом появляется базовый URL, который не хочется держать строкой в коде. Затем появляется ключ или другой секрет, который уже нельзя светить в браузере. В этот момент становится видно, что между UI и внешним API не хватает серверной границы.
В App Router такую роль часто закрывает Route Handlers. В официальной документации Next.js они описаны как пользовательские обработчики запросов внутри app directory на основе стандартных Web Request и Response API. Они доступны только в app, по смыслу заменяют старые API Routes из pages и поддерживают GET, POST, PUT, PATCH, DELETE, HEAD и OPTIONS. (Next.js)
Смысл Route Handlers в том, что они позволяют собрать внутренний серверный контур прямо внутри приложения. Через него можно проксировать внешний API, нормализовать ответ под нужды UI, спрятать env-переменные и секреты, а также вернуть в интерфейс уже свой контракт, а не чужой.
Принципы SOLID, DRY, KISS во фронтенде работают ровно так же, как в любой другой разработке. Но если открыть почти любой проект, всё равно натыкаешься на мешанину.
Причём дело обычно не в том, что код «грязный» — он как раз бывает типизирован и проходит linter. Дело в том, что эти принципы отвечают на вопрос «как написать», а не «зачем мы вообще это пишем». А без ответа на «зачем» чистый код превращается в красиво оформленную путаницу.
На примере такой вещи, как store попробуем ответить на вопрос: что вообще такое контракт, зачем же нужна типизация и действительно ли это помогает в разработке.