ReactJS *

В данной статье Вас ждет подробная история о том, как я создал игровой движок с нуля, совместимым с 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 → распарсить → отдать фронту в едином формате».

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

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

Многие смотрят на это спустя рукава, но Google создавал AIStudio не для того, чтобы вы ежедневного пользовались им в качестве основного интерфейса для общения с LLM. Студия была создана с целью дать возможность разработчикам настраивать параметры инференса, тестировать, баловаться. И не нужно быть главным‑по‑aistudio, чтоб это понять — там есть тулинг, граундинг поиска, можно изменить системный промпт. Диалоги сохраняются в виде файлов на гугл диске, чтоб было можно их клонировать, бекапить, итд. Есть отдельная страница с рейт лимитами, с выпуском API токенов. Это — ворота к программному интерфейсу для разработчиков, а не удобный chatgpt‑like веб‑интерфейс.

AnkiAI-Cards - мобильное Android приложение с помощью ИИ генерирует карточки по шаблону и отправляет их напрямую в AnkiDroid внутри смартфона. Помогает изучать иностранные слова ассоциируя с контекстом фраз и предложений.

Фронтенд-разработка давно перестала быть просто «вёрсткой сайтов». Сегодня это сложная экосистема: фреймворки, state-менеджмент, TypeScript, оптимизация производительности, работа с API и постоянный поток новых инструментов. Но за всей этой технологической гонкой часто теряется главное: что на самом деле нужно знать начинающему разработчику, где проходит грань между джуном и сеньором, и почему умение проходить собеседования — такой же навык, как и писать код.

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Ламковым — фронтенд-разработчиком, основателем YouTube-канала Friendly Frontend (аудитория более 50 000 подписчиков) и телеграм-канала «Friendly Frontend», опытным наставником, который провёл более 200 персональных консультаций с разработчиками, помог прокачать их навыки. Александр успешно прошёл собеседования на позицию сеньора в нескольких крупных IT-компаниях России, а сейчас работает в компании ВК. В этом выпуске узнаем, что такое современная фронтенд-разработка, какие навыки нужны, чтобы войти в профессию, что выбрать (найм или фриланс), и сколько на самом деле зарабатывают фронтенд-разработчики.

IWANT - наш собственный fashion-магазин. Несколько лет он жил на InSales: на старте это правильный выбор: быстро, без разработки, всё из коробки. Но в какой-то момент мы уперлись в потолок платформы: каждый нужный модуль - это либо платное приложение, либо «так нельзя». Мы посчитали и решили перевезти магазин на собственный движок.

Это не история «платформы плохие, пишите своё». Это разбор конкретного переезда: что переносили, как устроен ETL из выгрузок InSales, на каком стеке собрали и почему именно на нём, какие модули пришлось писать самим, как прошёл катаут без простоя и кому такой переезд реально нужен, а кому нет.

Интернет полон историй безупречного успеха: «Мы взяли модный фреймворк, переписали систему с нуля, и всё стало летать». Но реальный мир корпоративной разработки – это legacy. Это системы вроде Redmine, которые живут десятилетиями, хранят в себе терабайты критических данных, и чья миграция обойдется бизнесу слишком дорого.

Мы в команде ArcFront решили, что хватит терпеть интерфейсы из 2006 года. Вместо того чтобы убегать на платные облачные трекеры, мы совершили хирургическую инъекцию. Мы внедрили молниеносный React SPA прямо в ядро старого Ruby-монолита. Без микросервисов. Без CORS.

Рассказываем, как мы заставили старого пса выучить новые трюки: от архитектуры инъекции и парсинга Textile до психологии интерфейсов и нашего официального перехода на бизнес-модель Open Core.

Когда продукт должен работать и на телефоне, и на планшете, и на ПК, и на маке, путей два. Первый по учебнику: нативка под iOS, нативка под Android, отдельный веб под десктоп, и дальше живёшь с тремя кодовыми базами, тремя релизными циклами и модерацией в сторах. Второй: одно сайт-приложение (SPA плюс PWA), которое ставится на домашний экран и работает везде одинаково.

В своём проекте, агрегаторе нейросетей, я сознательно выбрал второй путь. Дальше разберу на этом примере, почему так, что выиграл, что честно потерял, и три грабли из прода, которые этот выбор подсветил. С кодом.

Разбираю, почему нативного EventSource часто недостаточно для production SSE: авторизация через headers, контролируемый reconnect, backoff, race conditions, stale-stream watchdog и синхронизация нескольких вкладок через Web Locks + BroadcastChannel.

На базе этих проблем я вынес real-time слой из AI SaaS-продукта в open-source библиотеку sse-runtime и заменил ей самописную инфраструктуру: −3 455 строк кода в production PR, один useSSE-хук вместо ручного reconnect, leader election и отладочного boilerplate.

Представьте ситуацию: вы открываете какой-нибудь файл в проекте, которому уже года три (чаще всего это форма). И в голове всплывает мысль:  «А что тут вообще происходит?». Причём не в смысле «кто виноват», а в смысле «как мы вообще сюда пришли?».

Я фронтенд-разработчица, и за шесть лет в разработке такое случалось почти на каждом проекте, где мне удалось побывать. Я хочу сразу оговориться: это не статья из серии «как надо жить». Это скорее разговор по типу «смотрите, как все мы иногда делаем и даже не замечаем».

Здравствуйте, товарищи! Эта статья про state management во фронтенде, с непривычного угла. За два года я ни разу не написал ни одного редьюсера. Расскажу, как я к этому пришёл, что слышу со стороны про сторы, и почему вам, особенно если вы только заходите во фронтенд, не надо учить Redux в принципе.

Сначала немного о себе, потом про то, что такое стор и почему я считаю его антипаттерном. Затем покажу, как без него живёт моё реальное приложение. И разберем возражения

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

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

В этой статье я хочу поделиться своими мыслями о MobX - инструменте, который я искренне полюбил после многих лет разработки интерфейсов. Приятного чтения! :)