ReactJS *

Данная статья может вызвать очень много баттхёрта в районе нижней точке у фанатов “прекрасной библиотеки” React.js просьба - уйти и не читать статью чтобы не повредить свою психику и сразу поставить дизлайк статье, негативные комментарии я удалять не буду мне без разницы, это крик души и мой личный баттхёрт после продолжительной работой с этим и инструментом. Расскажу непопулярное мнение про этот инструмент, расскажу про его реальные минусы про которые почему то все молчат.

Мы в стартапе ArcFront три недели двигались в совершенно неправильном направлении, пытаясь подружить современный React с 20-летним Redmine через сложный BFF-прокси. Рассказываем историю нашего провала, неожиданного архитектурного озарения и того, как мы выкинули две недели работы и заменили их 15 строками кода.

Привет, Хабр! Меня зовут Константин Шкурко, я ведущий разработчик мобильных приложений в РСХБ. Сегодня хочу рассказать историю о том, как всем известные обстоятельства заставили нас в сжатые сроки искать альтернат­ивные пути доставки нашего инвестиционного приложения «Свои инвестиции» пользователям iOS - и как это изменило наш технологический стек.

Когда Apple заблокировала российские банковские приложения в App Store, перед нами встала непростая задача. У нас были десятки тысяч активных пользователей на iOS, которые пользовались брокерским приложением для управления своими инвестициями. Торговля акциями, облигациями, аналитика портфеля, выставление заявок - всё это внезапно стало недоступно для значительной части клиентской базы.

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

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

Перед любой командой со стороны менеджмента и бизнеса стоит одна и та же задача «давайте быстрее — надо было еще вчера». Нас эта судьба также не миновала. Первое, с чего начинается оптимизация, своя дизайн‑система. У нас уже была своя дизайн‑система, она выручала нас во многих кейсах, но она была старая, подходы к разработке давно изменились, и UI Kit уже не отвечал требованиям. Поэтому было принято решение параллельно разрабатывать новую, с учетом всех последних требований и подходов.

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

Разработка имеет такую очередь: архитектурно наш UI Kit лежит в закрытом artifactory npm пакетом. Также есть шаблон со всеми необходимыми зависимостями и UI Kit«ом. Когда приходит время нового проекта, делается fork заготовки. Это дает быстрый старт.»

Начинаем

Давайте посмотрим, как бы начиналась разработка приложения. Возьмем для примера компонент Select. Не будем писать сами, возьмем Antd Select и через обертку emotion стилизуем его под корпоративные стили.

Структура получится такая:

В этой статье расскажу о свежем баге, который ронял один тип транзакций, пока остальные работали штатно. Если используете @formatjs/intl-durationformat для форматирования времени - этот кейс может сэкономить пару часов отладки.

Когда проект на 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-переменные и секреты, а также вернуть в интерфейс уже свой контракт, а не чужой.

У вас один SSG-лендинг, а платный трафик льётся из 12 кампаний под разные боли ЦА. Все ведут на дефолтный hero — конверсия в заявку проседает на 30–50%. Делать 12 лендингов дорого и убивает SEO, подменять hero на клиенте — FOUC и дефолт для поисковых ботов.

Рабочая схема, поставленная в продакшен за день: edge-функция Cloudflare Pages переписывает HTML на лету через HTMLRewriter, SSG остаётся источником истины, client-side React дублирует логику при гидратации. 200 строк кода, латенси без изменений (HTMLRewriter работает потоком), Lighthouse не страдает. Разбираю код, нюансы интеграции с vite-react-ssg и грабли из прода.

Мы были двумя 16-летними студентами колледжа, чья программа безнадёжно отставала от индустрии. Пока на парах проходили технологии пятилетней давности, реальный мир уже жил в экосистеме React, Next.js и WebAssembly. Пришлось учиться самим — по вечерам разбирая современный стек и споря об архитектуре. Эта тяга сподвигла нас создавать не абстрактные проекты для портфолио, а реально полезные инструменты, которыми хочется пользоваться каждый день.

Так четыре года назад родился наш проект — 167 утилит и 8 интерактивных песочниц в одном сервисе. Форматтеры, конвертеры, генераторы паролей и UUID, DevOps-конфиги, шпаргалки и песочницы для Python, SQL и Bash. Всё сделали прямо в браузере, без сервера.

Рассказываем как это было.

Каждый раз, когда я хотел поправить отступ или цвет в процессе разработки, я делал одно и то же:

открыл DevTools → нашёл элемент → поменял значение → понравилось → скопировал → переключился в редактор → нашёл файл → вставил.

Это семь шагов ради однострочного изменения. Я сделал LiveStyleSync, чтобы это был один шаг.

История о том, как один странный git push оказался началом расследования, которое вывело меня не на один взломанный аккаунт, а на цепочку зараженных репозиториев и проектов.

Снаружи все выглядело почти нормально: знакомый автор, знакомый коммит, привычные файлы. Но внутри последнего коммита уже жил чужой обфусцированный JavaScript. Он прятался в конфиге, менял Git-историю и маскировался под обычную работу разработчика.

Первой версией был взлом моего GitHub, но смена ключей и паролей ничего не решила.

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

Это оказалась PolinRider-like supply chain атака, которая использует сам developer workflow как транспорт.

В статье я разбираю, какие мелкие странности помогли заметить проблему и почему им нельзя махать рукой.

Показываю реальные скриншоты, подозрительные изменения в .gitignore и payload внутри babel.config.js.

В конце оставил скрипты, которые могут помочь быстро проверить свои проекты и логи на PolinRider похожие признаки.

Началось всё банально. Зашёл коллега, говорит: «Где у нас хлебные крошки в шапке лежат?». Проект — около 150 компонентов, всё именуется по-своему, структура папок местами загадочная. Я начал тыкать в React DevTools, искать по тексту «Breadcrumb» в файлах… В общем, минут через пять нашёл. Это в очередной раз раздражало.

MAX позиционируется как серьёзная платформа с госинтеграциями, но при этом разработчикам не дают базовых инструментов отладки. Работать в таких условиях можно, но это постоянные костыли и лишние часы. Я обращаюсь к команде MAX: если вы хотите, чтобы под вашу платформу делали качественные решения, нужно давать разработчикам нормальные инструменты. Иначе мы вместо экосистемы получим ещё один обязательный, но неудобный продукт.

В России сейчас активно продвигают мессенджер MAX как официальную альтернативу Telegram. Для пользователей это значит еще один клиент на рабочем столе, а для разработчиков — ещё одна платформа для ботов и мини‑приложений.

На бумаге это звучит норм: единая платформа, интеграция с госсервисами, мини‑аппы для бизнеса (привет, WeChat). На практике возникает базовый вопрос: как это вообще разрабатывать и отлаживать, если в десктопном клиенте нет нормальных DevTools?

В этой статье я попробую рассказать, как выглядит попоболь отладка мини‑приложений в MAX сегодня, чем она отличается от привычного процесса в Telegram (да да, опять сравнение с вездесущей телегой), и почему отсутствие инструментов разработки — не мелкая придирка, а системная проблема.

Я аквариумист. Однажды мне надоело гуглить совместимость рыб в десяти вкладках и записывать параметры воды в блокнот. За два месяца это вылилось в платформу с маркетплейсом, аукционами, AI-диагностикой и 93 таблицами в PostgreSQL. Рассказываю, что получилось, на чём построено и

Как перестать копировать формы и построить масштабируемую архитектуру

В enterprise-приложениях формы множатся быстро: create, edit, import, create-from-lead, duplicate — и вот у вас уже шесть копий одной формы, а внутри условный ад из if (mode === …).

Почему mode prop и giant form component не масштабируются, как разделить форму на четыре слоя: presentation, orchestration, context, data source. Что такое capabilities и почему они лучше условной логики. Как адаптеры отвязывают форму от source entities. Куда прятать submit, валидацию и внешний store. Как тестировать такую архитектуру изолированно.

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

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

В Wasp мы создаём фулстек-фреймворк — наподобие Rails или Laravel для JS, только ещё и расширенный на фронтенд. Мы с моим братом-близнецом начали этот проект в 2021 году, когда успешно прошли программу Y Combinator. За всё это время в общей сложности нам удалось привлечь $5 миллионов инвестиций.

Изначально мы хотели создать язык программирования, который бы абстрагировал типичные паттерны веб-приложений и в то же время позволял углубиться в любой стек (мы начали с React, Node.js и Prisma). Что-то вроде Terraform, но для стека веб-приложения, а не облачной инфраструктуры.

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

В этой статье я расскажу, почему нам эта идея казалась перспективной, какие уроки мы вынесли и почему заменяем свой язык на TypeScript при том, что сам Wasp внутренне остаётся всё тем же.

В прошлой статье я рассказывал, каково в одиночку тащить фуллстек-проект, который разросся до кино-соцсети. В комментариях несколько раз спросили про конкретику — «покажи код», «как сделал, что не выглядит как очередной пет-проект». Логично: дизайн — это то, по чему встречают. Поэтому держите вторую часть, уже техническую и с кодом. Без маркетинга, только решения, которые реально сделали интерфейс «дорогим», и пара бэкенд-хитростей в довесок.

Сразу дисклеймер: я не дизайнер. Всё нажито методом «смотрю на референсы (Letterboxd, Mubi, KinoPoisk HD) и пытаюсь повторить ощущение». Оказалось, премиальность — это не про дорогие шрифты, а про несколько повторяющихся приёмов. Разберём пять.

1. Акцентный цвет из постера фильма — фича, которая дороже всего «продаёт»

Самое заметное решение. Раньше у меня на всех страницах был один статичный фиолетовый акцент — и это выглядело дёшево и одинаково. Идея: пусть каждая страница фильма подсвечивается доминантным цветом его постера. Заходишь на мрачный нуар — интерфейс уходит в холодный синий, открываешь комедию — тёплый янтарь. Страница будто «сделана под этот фильм».

Делается без всяких ML, прямо в браузере через canvas: рисуем постер в крошечный буфер 32×48, усредняем цвета (выкидывая чёрные рамки и серость), переводим в HSL и принудительно «насыщаем», потому что постеры часто тусклые. Результат кладём в CSS-переменную — и весь интерфейс подхватывает её.

Когда локальный стейт в React-модуле начинает расти - разработчик инстинктивно тянется к useReducer+Context. Это работает, пока не перестаёт: ререндеры везде, провайдеры в елочку, логика размазана. В статье разбираю как этот путь выглядит в реальном продакшне на примере редактора субтитров, и почему паттерн Scoped Store на базе Context+Zustand+useRef решает эту проблему чище и проще.

Перевёл 16 курсов Anthropic Academy на русский за неделю. 448 уроков, субтитры, Telegram-авторизация, пейволл и т.п. на shared-хостинге за $2/мес. Рассказываю, как устроен пайплайн и что пошло не так.

Привет, меня зовут Александр Богданов, я ведущий фронтенд-разработчик стрима «Программы лояльности» в MWS. Наша команда отвечает за развитие и поддержку продуктов МТС Premium и МТС Cashback. 

На 2025 год у нас было три активных пользовательских витрины, которые использовали разный стек, разные дизайн-системы, по-разному взаимодействовали с бэкенд-сервисами и имели еще целый набор мелких отличий. Из-за этого разработке приходилось поддерживать зоопарк решений и технологий, а также многократно повторять одни и те же действия на разных стеках. Высокие time-to-market и стоимость разработки одной фичи закономерно не устраивали бизнес, поэтому перед нами поставили задачу — перейти на архитектуру микрофронтендов.

В посте расскажу, как мы это сделали с помощью npm-пакетов и какие результаты получили.