ReactJS *

В Додо и Дринкит работают несколько тысяч киосков самообслуживания на 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 элементы и добавили плавности

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

С кэшированием в Next.js обычно случается одна и та же история. API уже отдаёт новые данные, страница открывается заново, а на экране всё ещё старая версия. После этого в код быстро добавляют cache: "no-store", данные начинают запрашиваться на каждый заход, и через пару минут появляется уже другой вопрос - зачем тогда вообще нужен встроенный механизм кэширования.

Проблема в том, что кэширование обычно звучит как одно явление, а на практике в App Router похожие ощущения могут давать разные уровни поведения. Навигация назад и вперёд может переиспользовать клиентский кэш маршрута, сам маршрут может рендериться по-разному, а серверный fetch в Next.js имеет собственные стратегии кэширования и перевалидации. В актуальной документации это уже разделено на новый режим с Cache Components и на прежнюю модель без них. В этой статье речь именно о привычной модели App Router без Cache Components, где поведение обычно задаётся через fetch, cache, next.revalidate и route segment config. (Next.js)

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

Для примеров ниже используется проект Goods Finder и внешний API DummyJSON. Идея - сначала добавить на страницу штамп серверного рендера, потом отдельно показать момент получения данных, а уже после этого сравнить force-cache, no-store и revalidate.

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

Сегодня я хочу рассказать про то, как гетеросексуальный бэкендер (до этого момента коим я себя в той или иной степени считал) переживает болезненный опыт построения клиентской части платформы. Ради интереса недавно я посмотрел, сколько примерно строк на данный момент насчитывает репозиторий фронтенда Kroncl (название платформы), и приятно удивился числу 70.

Сделаю поправку на то, что очевидно: объём кода не свидетельствует о его чистоте и виртуозном ведении (опытные читатели скорее установят обратную зависимость).

В логистике всё редко выглядит как аккуратная CRM из презентации.

Заявки (аукционы/тендеры/грузы приходят из разных источников. Часть данных живёт в 1С/Битрикс/Excel/Амбарная книга, часть — в SQL, часть — в интерфейсах сайтов, часть — в голове менеджера. Перевозчики отвечают неравномерно, менеджеры работают через звонки и таблицы, а руководителю нужно быстро понимать: какие заявки есть сегодня, где рента, какие маршруты повторяются, кто из менеджеров проседает, где найти транспорт.

Я делаю внутреннюю систему автоматизации для логистической компании. Один из её модулей — веб‑панель поиска заявок. Сначала это была обычная таблица с фильтрами: маршрут, дата, тип кузова, источник, цена, рубли за километр.

Но довольно быстро стало понятно: сама таблица не закрывает главный сценарий.

Человеку всё равно нужно руками формулировать фильтр, помнить названия полей, переключаться между поиском, аналитикой и рекомендациями. Плюс в логистике своя внутренняя бизнес кухня, прибыль идет от типа ТС (реф/тент/изотерм/прочие) + сезонность, А если надо спросить что‑то вроде «какая ставка/руб‑км Краснодар — Москва тент?» или «сравни двух менеджеров за неделю», таблица превращается в набор ручных действий.

Так внутри поиск‑панели появился нейробот.

"Эта статья о том, как я n0x из просто болталки сделал агента который научился открывать браузер, делать скриншоты и выполнять команды

Вы когда-нибудь разговаривали с AI, и он в ответ на просьбу «открой Яндекс» писал вам: «Вот ссылка: https://yandex.ru»?

Я — да. И каждый раз мне хотелось сказать: «Спасибо, капитан Очевидность, я и сам это знаю».

Проблема в том, что большинство LLM-приложений — это просто болталки. Они генерируют текст, но не могут сделать что то полезное. А что, если бы AI мог управлять браузером? Открывать страницы, делать скриншоты, выполнять JavaScript?

В этой статье я расскажу, как добавил в проект n0x поддержку MCP (Model Context Protocol) — и научил AI-агента открывать сайты по команде «открой …».