ReactJS *

В 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).

Я попробовал собрать маркетинговый сайт через Claude Design - и быстро упёрся в лимиты токенов и непрозрачность облачного тула. Перешёл на Open Design - open-source альтернативу, которая цепляет твой Claude Code, держит дизайн-систему как DESIGN.md в репозитории и работает локально. Под катом - четыре практики, которые сработали на сайте конференции: design-as-code в git, симлинк дизайнера в код сайта, два markdown-файла под бренд и дизайн токены, и как мы учили автономных агентов делать сайт с помощью нашей дизайн системы

Открываешь иконочный React-компонент — и видишь стену <path> с координатами и viewBox-арифметикой. Что там нарисовано — непонятно, пока не скопируешь разметку в отдельный .svg, браузерные DevTools или Figma. Каждый такой маневр выбивает из потока.

Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья — продолжение предыдущей: Мой справочник по Feature-Sliced Design. На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD — архитектурной методологии для проектирования фронтенд-приложений.

В конце статьи есть ссылки на другие подходы к организации файловой структуры фронтенд-приложений.

Краткий обзор и представление фреймворка Shine для разработки десктоп приложений используя C++ и React.

В предыдущей статье был рассмотрен способ интеграции ИИ-ассистентов в процесс торговли на бирже. Чтобы углубиться в проектирование ИИ‑приложений, я решил доработать проект. В данной части опишу, как реализовал механизм GuardRails, а именно технику Human‑In‑The‑Loop.

Я делаю голосовой AI-репетитор английского. Продукт живёт в трёх местах:
веб-сайт speakwithai.pro, Telegram Mini App и Android-приложение в RuStore. У меня одна и та же база пользователей на NestJS + Postgres, и мне очень нужен ответ на вопрос: откуда вообще приходят люди?

Yandex.Metrika и Google Analytics показывают только сайт. Telegram Mini App для них — чёрный ящик. Android-приложение через WebView — тоже. Из 6000
просмотров статьи на Habr я не мог сказать, сколько оттуда пришло в продукт, и через какой канал (TG, веб, app).

Я не хотел тащить большую CDP вроде Mixpanel или Amplitude — для
соло-разработчика это overkill. Вечером сел и сделал simplest-thing-that-could-possibly-work: одна колонка в БД, парсится при первом визите, читается на регистрации. 100 строк кода. Делюсь.

Если интересно посмотреть на сам продукт — он живёт здесь:
🤖 Telegram-бот
🌐 Веб-версия
📱 Android в RuStore

Студенты попросили нормальный онлайн-доступ к оценкам и расписанию. В колледже уже была 1С:Колледж ПРОФ, но без удобного веб-интерфейса для студентов. Я сделал личный кабинет на Next.js, где браузер работает с моим сервером, а сервер — с 1С через HTTP-сервисы. Рассказываю, как устроил авторизацию, журнал, расписание, заказ справок и что оказалось самым сложным на стыке 1С и JSON.

За 25 дней нам удалось добиться довольно больших изменений в нашем проекте.

Мы провели:

Рефакторинг back-end сервисов

Убрали часть легаси кода на фронте

Переработали некоторый UI элементы и добавили плавности

Добавили новый функционал