ReactJS *

Обратимся к статистике: по данным с 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?

ChatGPT умирает на длинных разговорах. Не AI-часть — модель отлично держит тысячи сообщений. Умирает фронтенд. Таб зависает, скролл лагает, иногда браузер просто крашится.

Самое обидное — именно длинные разговоры самые ценные. Чем дольше обсуждаешь, тем больше контекста у модели, тем полезнее ответы. А продукт ломается ровно в тот момент, когда начинается максимальная отдача.

Мне это надоело и я полез разбираться.

Синхронизация атрибутов элемента с DOM-свойствами

Очевидно, что нашему компоненту потребуются атрибуты, через которые пользователь сможет контролировать его поведение. Наш компонент должен вести себя как стандартный элемент ввода типа «input», поэтому обязательно должен поддерживать такие атрибуты как disabled и required – и это самый минимум. Поэтому важно разобраться (ну или вспомнить) что такое «content vs IDL attributes», и как с этим работать.

Документация по веб-компонентам мало говорит об атрибутах, разве что рекомендует использовать attributeChangedCallback() для наблюдения за ними, но этого недостаточно. Хотя это полезное API, нам оно не подходит, потому что оно уведомляет нас о уже совершенном действии (изменении атрибута), а нам нужно контролировать этот процесс, то есть – синхронизировать атрибуты и свойства с нормализацией значений.

Так как наш компонент наследует базовый класс HTMLElement, а в нем уже реализовано большое количество разных методов, то мы можем переопределить некоторые из них чтобы получить нужный нам результат. Для начала определим наши свойства в виде пар get/set и значения в приватном поле:

Когда речь идет о веб-разработке, а именно — о разработке форм, можно встретить множество мнений о том, «на чем» лучше делать проект. Очень часто React и Angular Framework рассматриваются как альтернативы друг другу. При этом выбор фреймворка — критически важный этап, который определяет дальнейшую разработку и особенности развития технологического стека компании.  

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

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

Меня зовут Виктор, и я хочу рассказать, как бытовая рабочая задача привела меня к тому, что я написал полноценный аудиоредактор, который работает целиком в браузере - без единого запроса на сервер. Под капотом - Web Audio API, OfflineAudioContext, порт LAME-энкодера на JavaScript и немного стыдных архитектурных решений, о которых тоже расскажу.