ReactJS *

Хочу анонсировать свой фреймворк Point0. Это первый Bun FullStack фреймворк сопоставимый по функционалу с Next.js и TanStack Start. Однако, имеет кардинально другой DX, ради которого и был создан.

Мне всегда не нравились существующие фреймворки, особенно Next.js и Remix (React Router). Но я думал, что, видимо, по-другому фреймворки просто не получаются, поэтому и не делают. А громоздкость, чужие строгие соглашения, неповоротливость архитектуры, это просто необходимое зло, с которым я должен смириться.

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

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

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

Хочу рассказать про наш проект Exam AI — внутреннюю платформу для аттестации и тренировки сотрудников.
Это не “ещё один тестик на 20 вопросов”, а система, где:

За три месяца наш голосовой ИИ-агент успел соврать клиенту про несуществующего администратора, принять всех звонящих за одного человека и месяц выдавать обычный синтез за "клонированный голос". Разбираю, почему это лечится структурой кода, а не промптом — на полностью российском стеке.

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

PrimeTek, бывшая PrimeFaces, запустила PrimeUI — новую лицензионную модель для экосистемы PrimeNG, PrimeReact и PrimeVue. Это подаётся как унификация бренда, но по сути компания собирает свои ключевые продукты под одной коммерческой оболочкой. Раньше они существовали как набор отдельных библиотек, которые монетизировались через дополнительные продукты и сервисы. Теперь вся экосистема превращается в единый лицензируемый актив.

В статье разберёмся, что именно изменилось, что останется бесплатным, в чем сильные стороны новой схемы и какие риски она несёт для команд и компаний.

В этой статье разберу пять направлений, в которых мы получили измеримый эффект:

1. Type checking — TSCheck vs TSGO

2. Linting — ESLint vs Biome vs Oxlint

3. Bundling — Webpack → Vite → Rsbuild

4. API-контракты — Кодогенерация без AI

5. React-оптимизации — React Compiler в production

DatePicker казался нам небольшой задачей в разработке UI, пока мы не попробовали создать компонент, который будет корректно работать с keyboard navigation, screen reader’ом, управляемым состоянием и реальными проверками доступности.

Нам потребовался DatePicker производственного уровня на React и TypeScript, и сначала очевидный путь казался очень заманчивым: дать AI четкий запрос, получить 80% готового кода, а остальное доработать руками. Подробный разбор этого кейса есть в моей предыдущей статье «Попросили Claude создать WCAG-доступный DatePicker на React и потратили 3 дня на доработки».

Так вот.

Модель может сгенерировать структуру календаря, атрибуты ARIA, базовую keyboard navigation и логику работы с датами.

Затем начинается интеграция: поведение фокуса становится нестабильным; возникают конфликты между обработчиками событий; озвучивание screen reader’ами требует тщательного тестирования; небольшое изменение в логике работы с датами может неожиданно нарушить работу календаря; код выглядит нормально, но компонент пока не является надежным.

В этой статье я сравниваю два способа создания доступного DatePicker'а с помощью AI:

Первый — 80% кода с помощью AI, остальные 20% руками. Второй — системное проектирование с AI-агентом: PRD, декомпозиция задач, правила агента, внешняя верификация, Vitest, Playwright, сборка Vite, проверки типов и строгий цикл, в котором агент не может двигаться дальше, пока не будет пройден текущий шаг.

Дальше все по делу: в чем AI действительно нам помог; где он начал сбиваться с курса; почему одного большого promt'а оказалось недостаточно; как The Verifier изменил процесс и почему основная задача инженера в разработке с использованием AI больше не сводится только к написанию кода, а заключается в контроле над замыслом, архитектурой, контрактами и стоимостью изменений.

Выбор даты кажется небольшой задачей в UI, пока не попробуешь сделать его по-настоящему WCAG-доступным.

Нам понадобился настраиваемый DatePicker на React для процесса записи на прием к врачу, где пользователи, работающие с keyboard navigation, и люди, использующие screen reader’ы, должны были выбрать дату без лишних затруднений.

Claude сделал нам хорошую первую версию: структуру компонента, ARIA-атрибуты, базовую keyboard navigation и логику календаря. На первый взгляд результат выглядел почти готовым.

Затем мы запустили NVDA, VoiceOver и протестировали сценарий keyboard navigation.

Фокус выходил за пределы диалогового окна; некоторые даты озвучивались неверно; переключение между месяцами сопровождалось слишком тихим звуком; нажатие клавиши «Esc» закрывало календарь, но оставляло пользователя без контекста; режим высокой контрастности Windows нарушал отображение выбранного состояния.

Код выглядел нормально, но UX оставлял желать лучшего.

В этой статье мы рассмотрим реальную работу, стоящую за WCAG-доступным DatePicker'ом: где AI сэкономил нам время; где он не справился; как нам помог WAI-ARIA APG; какие детали нам пришлось исправлять вручную и почему доступность нельзя проверить, просто прочитав сгенерированный код.

Приготовьтесь к инсайтам, багам и победам!

Привет, Хабр! Меня зовут Борис, я инди‑хакер и разработчик. Обычно я пилю Telegram‑ботов и настраиваю автоматизации, но чуть менее года назад меня затянула идея создать собственный большой, удобный и, главное, полностью авторский веб‑проект в тематике ИИ — Нейро.PRO.

Я сразу решил, что не буду использовать никакие конструкторы, шаблоны из 2010х и унылые рерайтов. Всё пишем руками (с помощью ИИ‑шки конечно же), вылизываем UX и делаем упор на пользу для людей.

Cruzo — минималистичный UI-фреймворк без лишней сложности 

Знакомимся с Cruzo. Часть 1. RxBucket – контейнер состояний и конфигураций компонентов на фронте

Я продолжаю серию обзорных статей о js-фреймворке Cruzo. Я работаю над этим фреймворком последние 6 лет, много идей отпало, осталось только что реально нужно в работе.
Здесь я расскажу вам о сердце фреймворка – шаблонизаторе. Для его реализации была написана стековая виртуальная машина.
Какая еще виртуальная машина внутри js спросите вы? Это VM — но не «виртуальный процессор» вроде JVM или WebAssembly, а интерпретатор байткода, написанный на JavaScript.

В данной статье Вас ждет подробная история о том, как я создал игровой движок с нуля, совместимым с RenderWare (движком, на котором работает GTA San Andreas), запускающийся в браузере. Один, за три недели, с Claude Code.

За шесть предыдущих выпусков мы собрали собственный конвейер безопасной разработки: развернули виртуальные машины, подняли инфраструктуру из GitLab, Vault, Nexus, DefectDojo и Dependency-Track, написали CI/CD-пайплайн, подключили сканеры безопасности и настроили резервное копирование.

Остается главный вопрос: сможет ли наш конвейер находить реальные уязвимости, а не просто радовать разработчиков зелеными галочками в интерфейсе GitLab? 

Как говорили старые DevSecOps-бояре, «в нашем деле на слово не верят — безопасность нужно проверять».

Поэтому сегодня устроим нашему конвейеру проверку боем. Возьмем уязвимое приложение Reactvulna, загрузим его в GitLab и прогоним через собранный нами пайплайн. После этого разберем результаты сканирования и посмотрим, насколько хорошо собранная нами инфраструктура справляется с обнаружением проблем безопасности.

Привет, Хабр! Меня зовут Антон, я фронтенд‑разработчик в Домклик. Наша команда отвечает за библиотеку «Продуктовых сниппетов» — те самые карточки недвижимости, которые вы видите в нашей поисковой выдаче.

Проблема в том, что этих карточек у нас более 40 видов (сниппеты вторичной, первичной, загородной, краткосрочной недвижимости, каждый тип имеет несколько размеров под разные разрешения), и все они живут в одной монорепозиторной библиотеке на React 19. Любая правка в общих стилях или глобальных дизайн-токенах, или элементарное обновление компонентов дизайн-системы превращалось в игру «Сапёр»: поправил отступ в одном типе сниппета — поехала вёрстка или поплыл паддинг в другом, о чём мы узнавали уже при тестировании релиза или, что хуже, от пользователей после релиза.

Я расскажу, как мы внедрили полноценное визуальное регрессионное тестирование (Visual Regression Testing) на основе Storybook, Playwright и Jest, с какими трудностями столкнулись при стабилизации скриншотов и как заставили тесты работать стабильно.

Astro — фреймворк для сайтов, который минимизирует поставку JavaScript на клиент, обеспечивая высокую производительность. 22 июня вышла седьмая версия, в которой разработчики серьёзно прокачали скорость. Компилятор .astro переписали на Rust, туда же перенесли обработку Markdown и MDX, а движок рендеринга заменили на систему с очередями. Вкупе с Vite 8 и новым бандлером Rolldown сборки ускорились на 15–61% по внутренним бенчмаркам. А поскольку самая быстрая сборка — та, которую не нужно запускать вовсе, в Astro 7 также стабилизировали кэширование маршрутов и добавили экспериментальных CDN-провайдеров кэша для Netlify, Vercel и Cloudflare.

В Astro 7 добавили продвинутый роутинг: появляется точка входа src/fetch.ts, дающая полный контроль над конвейером обработки запросов в Astro. Для разработки с участием ИИ Astro теперь умеет определять coding agents, запускать dev-сервер в фоне и выводить структурированные JSON-логи, когда агентам нужен машиночитаемый ответ.

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

Недавно под постом в канале MoscowJS разгорелся спор — со мной и организатором насчёт смола. Даже не столько насчёт смола, сколько в целом: стоит ли выбирать новые технологии или нет. Думаю, это касается не только смола, а любых новых фреймворков и библиотек.

Претензии вроде бы логичные, чтож, давайте разберем их

После моей первой статьи про Pulse я не ожидал, честно говоря, примерно ничего. Но к моему удивлению увидел реакцию: немного поддержки, немного критики, несколько советов по UX.

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

Не так давно, я наконец выложил на github свой фреймворк cruzo – https://github.com/MaratBektemirov/cruzo. Сам фреймворк писался где-то с 2020г, в свободное от работы время. Причем большую часть времени я потратил на шаблонизатор с реактивными значениями.

Я хотел сделать минималистичный, но в то же время мощный инструмент для создания простых и сложных веб-приложений. Попытался взять хорошие идеи от разных фреймворков и собрать их в одном месте. Одна из таких идей - это RxBucket - контейнер состояний

Я обычный инженер-программист в банке. Вечерами, после работы и семьи, я начал эксперимент: смогу ли я один, с помощью нейросетей, сделать мессенджер таким, каким, как мне кажется, он должен быть? Не «убийцу Telegram» или кого-либо другого, а просто альтернативу - спокойное место для общения. Без шума, без бесконечных кружков, без ощущения, что ты должен читать каналы, на которые никогда не подписывался.

Знаете это чувство, когда подписки и личные чаты свалены в одну кучу? Да, папки есть, но эти вездесущие счётчики непрочитанного… они просто сводят с ума. Ты выходишь из канала, а тебя кто-то туда возвращает — и ты даже не понимаешь, как и кто это сделал.

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

В общем то немного покумекав, я подумал - если тебе что-то не нравится - сделай сам! И я начал делать.

Так родился Pulse.

Мы делаем чат-агрегатор, где в одном окне доступны GPT, Claude, Kimi и DeepSeek. Фронтенду нужно отдавать ответ в реальном времени — токен за токеном, как в ChatGPT. Бэкенд при этом ходит к четырём разным API, и стриминг у них устроен по-разному. Расскажу, как мы свели это к единому SSE-потоку наружу, и про две грабли, на которые наступили: рваные UTF-8 символы и парсинг чужих SSE.

Статья будет полезна всем, кто проксирует LLM через свой сервер.

Зачем вообще свой прокси

Фронтенд не должен знать ключи провайдеров и не должен ходить к ним напрямую. Все запросы идут через наш Node.js-бэкенд: он подставляет ключ, дёргает нужный API с stream: true, парсит входящий поток и отдаёт фронту унифицированные события. Плюс на бэкенде живут лимиты, учёт токенов и подмена провайдера.

Задача: «получить поток от провайдера X → распарсить → отдать фронту в едином формате».

Два разных формата стриминга

Провайдеры делятся на два лагеря.