JavaScript-библиотека для создания интерфейсов
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?
ChatGPT умирает на длинных разговорах. Не AI-часть — модель отлично держит тысячи сообщений. Умирает фронтенд. Таб зависает, скролл лагает, иногда браузер просто крашится.
Самое обидное — именно длинные разговоры самые ценные. Чем дольше обсуждаешь, тем больше контекста у модели, тем полезнее ответы. А продукт ломается ровно в тот момент, когда начинается максимальная отдача.
Мне это надоело и я полез разбираться.