ReactJS *

Мы были двумя 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-пакетов и какие результаты получили.

В Додо и Дринкит работают несколько тысяч киосков самообслуживания на iOS, Android и Windows. Чтобы не писать нативный софт и интеграции под каждую систему, мы используем SPA-приложение на React и встраиваем его в хост-приложение на целевой платформе. А в основе интерфейсов всех киосков — фронтенд-приложение, запущенное в WebView внутри нативного приложения

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

С этой задачей столкнулся я — Андрей Боев, техлид команды XXX, отвечающей за опыт пользователей киосков. В этой статье я расскажу, как мы добавили сбор метрики FPS и начали использовать её для системного мониторинга производительности интерфейса, а также почему путь к очевидной метрике оказался не таким уж очевидным. Погнали!

Команда Socket Threat Research обнаружила компрометацию 84 npm-пакетов в пространстве @tanstack: в них внедрили вредоносный имплант Mini Shai-Hulud, нацеленный на кражу учётных данных и секретов из CI/CD-сред, включая GitHub Actions.

Атака особенно опасна тем, что вредонос автоматически запускается при установке зависимостей через lifecycle-хуки npm, а среди затронутых пакетов есть крайне популярные — например, @tanstack/react-router с более чем 12 млн загрузок в неделю, что делает инцидент серьёзной угрозой для безопасности цепочки поставок ПО.

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

Я соло-делаю Speakwithai — AI-репетитор английского для русскоязычной аудитории. Месяц назад выкатил публично, за этот месяц получил 50 регистраций, 3 платящих и набор технических граблей, которые честнее разобрать, пока они свежие, а не через год по сглаженной памяти.

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

Собеседования по TypeScript всё чаще проверяют не только знание синтаксиса, но и умение видеть «узкие места» в уже работающем коде. Задача кандидата - не просто сказать «тут ошибка», а предложить более безопасное, читаемое и поддерживаемое решение.

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

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

React дал нам невероятную свободу: фунĸциональные ĸомпоненты с хуĸами, состояние в Redux, Context, MobX, Zustand или useState, запросы где угодно и ĸаĸ угодно. Но эта свобода имеет обратную сторону — отсутствие стандартов.

Каждый разработчиĸ пишет «по‑своему». В одном проеĸте мирно сосуществуют устаревшие подходы с современными, запросы ĸ API разбросаны по всему ĸоду, а состояние приложения напоминает спагетти. Проходит полгода, и даже автор ĸода с трудом объясняет, почему все устроено именно таĸ.

Знакомо?

Существует архитеĸтура, ĸоторая решает эти проблемы. Она называется Bulletproof React. Это не очередной шаблон или стартовый boilerplate. Это философия и набор лучших праĸтиĸ для создания production‑ready приложений, ĸоторые не превращаются в хаос через месяц разработĸи. В этой статье я постараюсь разобрать эту архитеĸтуру детально: от струĸтуры директорий до тестирования и безопасности. Данный материал будет полезен и новичĸам, ĸоторые тольĸо начинают задумываться об архитеĸтуре, и опытным разработчиĸам, ищущим проверенные решения.

Мы живём в эпоху когда можно написать в чат «сделай мне CRUD» и получить рабочий код через десять секунд что в принципе удобно. И это, если честно, главная причина почему я периодически намеренно лезу в что-то сложное руками — чтобы не разучиться думать о том что происходит внутри.

ИИ я использую. Но в этом проекте он был исключительно быстрой документацией — особенно когда добрался до selection/range API, про которые до этого знал чуть меньше чем ничего. Реализация все равно была за мной.

Так вот — ReadGen. Блочный конструктор README-файлов. Месяц, 2-3 часа в день, React и TypeScript и небольшая пачка дополнительных библиотек для разумного облегчения жизни. Важно понимать что это не коммерческий продукт и не претендует на решение чьей-то боли. Просто техническая задача которую я давно хотел разобрать.

Открываете очередной React-проект в 2026 году и смотрите на белый экран package.json. Какой роутер? Vite или Next.js? shadcn/ui или Mantine? Zustand или всё-таки Redux Toolkit? React Hook Form или TanStack Form? И как вообще теперь делать таблицы — TanStack Table или AG Grid?

Каждая из этих категорий за последние 2-3 года прошла через смену лидера. То что было стандартом в 2022 (Redux, Material UI, Webpack, styled-components, Formik), в 2026 либо в legacy-режиме, либо проиграло свежим конкурентам. Те кто работают в одной экосистеме годами, могут не заметить как сместились веса в соседних слоях стека — пока не открывают новый проект и не сталкиваются с тем что “стандарт”, которым они пользовались, теперь редко выбирают.

Эта статья — карта актуального React-стека 2026 года, разбитая по 60+ категориям. По каждой — что выбрал бы я для нового проекта в 2026, какие есть альтернативы для специфических случаев, что считается legacy и почему. Плюс — типовые комбинации стека под разные виды проектов (SaaS dashboard, collaborative editor, real-time dashboard, streaming app, consumer landing).