ReactJS *

Когда меня просят подсказать, как структурировать веб-сервис, я всегда начинаю с одного и того же: напишите сервер, который в ответ на HTTP-запросы выдаёт текст в формате HTML.

Это наиболее долговечный, финансово оправданный и понятный пользователю способ написать веб-сервис. Большинство веб-сервисов следует выстраивать именно так, если только у вас нет очень веской причины действовать иначе.

Выслушав меня, веб-разработчики часто отвечают: «о, так вам нравится рендеринг на стороне сервера», на что я обычно, поморщившись, парирую — «да, в какой-то мере». Не распыляйтесь по пустякам, если собеседника отделяет от вас десятилетие невежества. Хотя бы они понимают, о чём я. 

Но «рендеринг на стороне сервера» — ужасный термин. Он подразумевает, что сервер не просто больше работает, но и выполняет сложную работу — такую, которую лучше оставить экспертам. Ни то, ни другое не соответствует истине. На самом деле, «рендеринг» на стороне сервера можно организовать почти без труда, какой бы язык программирования вы ни предпочитали.

Стоит вам это понять — и Веб откроется вам таким, каким его вижу я: как самый простой, лёгкий и наиболее мощный интерфейс для вычислений, какой только есть на свете.

AI-копилот за 40 секунд сгенерировал мне форму на 180 строк с валидацией через zod и сэкономил полчаса. А потом потратил два моих часа на отладку хука с race condition, который я бы написал сам за 40 минут. После месяца плотной работы с Cursor, Copilot и ChatGPT на продакшн-проекте React/Next.js я вывел для себя систему: какие задачи отдавать AI, а к каким его подпускать нельзя.

Как вырваться из замкнутого круга навязываемых акулами BigTech сомнительных технологий на простор устойчивого развития? Как сделать так, чтобы код внедряемой сейчас Дизайн‑системы — через пару лет опять не превратился в очередную, никому не нужную и максимально не удобную, «тыкву‑легаси»? Как выйти из дурного холивара с модными фреймворками на фронтенде и сделать библиотеку переиспользуемых компонент подходящую сразу для всех технологий и «на века»?)))

Ваша команда работает с большим количеством различных недокументированных проектов, основанном на одном визуальном языке? У вашей корпорации есть строгий брендбук и огромное количество клиентских веб‑сервисов написанных на разных фреймворках, которые по факту выглядят немного по‑разному в «одних и тех же мелочах»? Ваши фронты «пишут каждый свой фреймворк для дизайна заново каждый раз на каждом проекте»? Знакомо? UUI спешит к вам на помощь!

Мода на технологии все стремительней меняется, а браузер и простой интерфейс в нем остается. Вышел новый модный фреймворк и заказчику хочется проект именно на нем? Да пожалуйста! Легко! Так мы становимся максимально независимы от капризной и накаченной лоббированием индустрии реализуя основную задачу. Поставляя единый гайдлайн повсюду.

Я ненавижу писать фронтовые тесты. Не потому что я против тестирования, а потому что в какой-то момент они превращаются в бессмысленный ритуал. Особенно когда от тебя требуют покрыть ими вообще всё.

Обратимся к статистике: по данным с https://httparchive.org/ за последние 6 лет средний размер веб-страницы значительно увеличился. Если в декабре 2019 года средний вес десктопной веб-страницы составлял 1,9 МБ, то сейчас он уже 2,9 МБ для десктопа и 2,6 МБ для мобильных устройств. Это рост на 50% за 6 лет, причём изображения составляют до 40% общего веса страницы.

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

Просматривая недавно пул-реквест, я заметил, что туда добавили новые изображения. Меня удивил выбор формата: для картинок без прозрачности использовали PNG. Это кажется избыточным, так как для многоцветных изображений лучше подходят форматы вроде JPEG, которые весят меньше.

Я решил провести эксперимент: оптимизировал и переконвертировал изображения в JPEG, WebP и AVIF, сохранив качество на глаз неотличимым от оригинала.

TL;DR перевода статьи Boris Tane: SDLC is dead.

SDLC больше нет. AI-агенты не ускорили привычный жизненный цикл разработки, они его схлопнули.

- Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого.

- Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом.

- Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability.

Новый жизненный цикл — это узкая петля: Intent (Намерение) → Build (Создание) → Observe (Наблюдение).

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

Первое случилось в самолёте. Мне было нечем заняться, и я решил посмотреть фантастический фильм «Она» (Her, 2013). Я человек впечатлительный, и если в истории есть драма, то легко начинаю сопереживать героям. Фильм рассказывает об одиноком мужчине, который устанавливает ИИ‑операционную систему, начинает с ней общаться и постепенно влюбляется в неё. Спойлерить не буду - фильм действительно стоит посмотреть.

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

Меня это действительно впечатлило. Ощущение было почти как в фильме про Железного человека: ты запускаешь ИИ, и он, как Джарвис, выполняет задачи и отвечает тебе почти как живой собеседник. Но довольно быстро стало понятно, что у такого подхода есть две серьёзные сложности.

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

Вторая - всё настраивается через пошаговый текстовый визард в терминале. Такой подход скорее рассчитан на технически подготовленного пользователя или ИИ‑специалиста, а не на обычного человека.

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

Знаете это чувство, когда сидишь на очередном спринт-планировании, команда пытается оценить таски, а планинг покер тормозит так, что успеваешь кофе сварить, пока карточка загрузится?

Вот у меня в AGG TEAM такая же история была. Мы пробовали:

Привет, Хабр!

Полгода назад я писал здесь, как за 5 дней с помощью Claude создал приложение для мониторинга диабета у своей кошки Манишки. Ей было 13 лет, она весила 3 кг, и каждый день я мерял ей сахар глюкометром и колол инсулин. Из блокнота на холодильнике данные перекочевали в Excel, потом в Python-скрипт с графиками, а потом — в полноценное веб-приложение Diabnostic.

С тех пор кое-что изменилось: Манишка вышла в ремиссию в декабре 2025 — глюкоза пришла в норму, инсулин больше не нужен. Но приложение жило своей жизнью: за 5 месяцев работы на платформе зарегистрировались 346 владельцев, и вместе с их питомцами накопился уникальный датасет — 6 783 записи глюкозы от 121 питомца.

В этой статье — о том, какие неожиданные медицинские инсайты я нашёл в обычном дневнике глюкозы.

Я не OpenSource разработчик, но за пару десятков лет написал под сотню enterprise-level библиотек, которые остаются в рабочем контуре, дорабатываются под каждый проект и адаптируются к новым технологиям. Большого смысла выходить в OSS не было, кроме как для упрощения обучения коллег и единого места хранения документации.

Но и желание помогать другим и делиться выстраданными подходами, экспертизой и конкретным кодом мне не чуждо - сегодня поможешь ты, завтра - тебе. Через полгода подготовки и адаптации к OpenSource (сам использую и дорабатываю около 8 лет) в свет выходит одна из библиотек моего рабочего контура - Reactive Route.

Так как я работаю с проектами на разных стеках, стараюсь писать код максимально framework-agnostic - независимыми слоями, которые можно заменить или переписать, не трогая остальной код проекта. А к фреймворкам и библиотекам для работы с состоянием они подключаются с помощью легковесных адаптеров, сохраняя синтаксис работы. Конкретно для Reactive Route выложил набор готовых адаптеров в комбинациях, которые сейчас чаще всего использую:

• React + MobX / Observable

• Preact (no compat) + MobX / Observable

• Solid.js + нативная реактивность / MobX / Observable

• Vue + нативная реактивность

В одном npm-пакете - строгая TS-типизация, SSR / MPA / no-JS / Widget режимы и тщательно протестированная отказоустойчивость. В статье не буду пересказывать документацию на русском и английском, а поговорю скорее про общие принципы качества, использование ИИ в разработке и почему многие библиотеки раздуваются, не успев даже стабилизировать ядро.

Почти каждый фронтенд-разработчик однажды задаётся вопросом: что на самом деле происходит внутри современных фреймворков. Почему изменение переменной автоматически обновляет интерфейс? Как библиотека понимает, что именно нужно перерисовать?

Всем привет! Сегодня я хочу поделиться опытом создания веб-приложения на основе GigaChat API от Сбера. В проекте я использовал не только текстовый диалог с нейросетью, но и добавил голосовой ввод (распознавание речи) и озвучку ответов с помощью SaluteSpeech. Получился полноценный голосовой AI-ассистент. В этой статье я расскажу о технических деталях: как получить доступ к API, как организовать обмен сообщениями, кэшировать токены, обрабатывать ошибки и сделать удобный интерфейс.

13 марта 2026 года вышла новая мажорная версия инструмента для сборки фронтенд‑приложений — Vite 8. Главным изменением стал переход на новый бандлер Rolldown, написанный на Rust. Теперь Vite использует единый инструмент вместо связки esbuild и Rollup, что позволяет значительно ускорить сборку — по заявлениям разработчиков, в некоторых проектах прирост достигает 10–30 раз. Это самое значительное изменение архитектуры Vite со времени выхода Vite 2.

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

Большинство туториалов по бесконечному скроллу покрывают только одно направление: вниз. Ловим конец списка, подгружаем, готово. Но в реальных приложениях нужен скролл в обе стороны: история чата, лог-вьюеры, таймлайны. А скролл вверх создаёт проблему, которой при скролле вниз просто нет.

В этом гайде я покажу, как собрать двунаправленный бесконечный скролл с нуля. Здесь React и @tanstack/react-virtual, но сама техника — просто математика над scroll offset. Работает так же в Vue, Svelte или на ванильном JS.

Демо | Исходный код

Когда у меня появилась теплица, первым желанием было автоматизировать всё, что можно: контроль температуры, управление вентиляцией, полив, освещение. Готовые решения либо стоят дорого, либо замкнуты в экосистеме одного производителя, либо не дают нужной гибкости. Поэтому я решил создать собственную систему по автоматизации управления процессами в теплице. Также у меня было много бесхозных контроллеров ESP8266/ESP32, которые нужно было куда‑то «пристроить».

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

На днях я стряхнул пыль с небольшого пет-проекта. Это простой блог, наверняка каждый из вас хотя бы думал о таком для себя.
В 2015 году я бы просто закинул файлы по FTP на хостинг за 100 рублей. Время деплоя: 30 секунд.
В 2026 году я потратил 4 часа. Я настраивал Edge Middleware, дебажил рассинхрон HTML между клиентом и сервером (hydration mismatch) и разбирался, почему облако не хочет дружить с моей базой данных из-за долгого пробуждения функций (холодного старта).

Где мы свернули не туда?
Это колесо Сансары, которое дало новый оборот.

Собрал production‑ready Next.js boilerplate для self‑hosted проектов: один репозиторий, один VPS, Docker + nginx + Let’s Encrypt, GitHub Actions, опциональный MongoDB, авторизация и небольшой UI‑кит. Это кейс про инфраструктуру вокруг Next.js без Vercel и прочих managed‑платформ для большего контроля и экономичного старта.

Связка React+MobX хорошо себя зарекомендовала при работе с формами, в то время как за реактивность модели данных в Angular обычно отвечает библиотека RxJS. Но что делать, если вы хотите воспользоваться преимуществами Angular в React или Node.js? В этой статье речь пойдет о новой библиотеке от Cloud X, которую мы разработали для того, чтобы проложить “мостик” из мира Angular, где всё богато, но дорого в мир React, где все дешево, но скудно. В этой статье я описываю применение ядра @cloudx/react-ui-kit-forms, которое отвечает за структуру модели данных, реактивность модели данных и контроль состава данных (валидацию), позволяя “скрестить” плюсы React и Angular на одном проекте. 

Перед тем как писать наш будущий мессенджер нужно определиться с технологией на которой будем его разрабатывать. Явными фаворитами среди инструментов web разработки для SPA являются Angular и React. Я не буду акцентировать преимущества каждого из этих инструментов, а остановлюсь сразу на Angular, т.к. ранее проводил ресёрч по не классическим виртуализированным спискам и выявил, что для данной задачи он справится эффективнее, чем React.

Всем привет, уважаемые читатели! В архитектуре проектов мы можем наблюдать применение паттерна BFF (Backend for frontend). При этом BFF может быть в архитектуре, где есть взаимодействие с клиентскими приложениями: веб, мобильное, смарт-устройства и т.д, но может быть всего-навсего один служебный фронтенд, доступ к которому возможен во внутрикорпоративном сегменте, например, банковская система, hr, логистика. Кажется, что при наличии одного фронтенда введение BFF избыточно.

И возникает закономерный вопрос: если клиент всего один, да еще и работает внутри защищенного контура, зачем нам плодить отдельные компоненты системы? Не превращается ли BFF в лишний прокси-сервис, который только пробрасывает запрос и добавляет сетевую задержку?

Но что, если фронтенд один и вдруг нуждается в данных из разных API системы, чтобы нормально функционировать? При этом запросы могут быть сложными: каждый требует особых параметров и возвращает много лишней информации. А если у вас несколько клиентских приложений и так же нужно подтягивать данные из разных API?