JavaScript *

Компании уже оплачивают сотрудникам Claude Code, Cursor или Codex, но не всегда видят рост производительности.

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

Разбираю, зачем команде общая память, и при чём тут GBrain, OpenBrain и обычные Markdown-файлы.

Привет!

Это 17 выпуск Frontend Status — дайджеста по фронтенд-разработке.

В этом выпуске:

📺 Страница отрисована, а интерфейс всё ещё «оживает»: отложенная гидратация в TanStack Start на карусели Jack Herrington и подкаст с Андерсом Хейлсбергом — от Turbo Pascal до того, как ИИ меняет ремесло, когда код пишут не построчно — чтобы понять, где теряется скорость и куда движется разработка.

🤖 Половина кода уже с ИИ, а доверия меньше: опрос State of AI 2026 (54% сгенерированного кода), Яндекс и тысячи конфликтов при мерже Chromium, перцептрон 1959 года и «чтение мыслей» модели Anthropic — чтобы смотреть на внедрение ИИ цифрами и без иллюзий.

🛡️ Пустили агента в репозиторий — а что он может сломать: разбор Positive Technologies и история, когда ИИ «находит» CVE, который уже был в обучающих данных — чтобы не открывать доступ вслепую.

💫 Анимация замирает вместе с React: управление бесконечными CSS-циклами без прыжков и сравнение CSS, Motion и GSAP на главном потоке — чтобы интерфейс оставался плавным без лишнего JavaScript.

⚡ Нужна коллаборация как в Figma и Miro: Hocuspocus от Tiptap на Y.js и CRDT без гонок правок — WebSocket, офлайн и Redis — чтобы собрать совместное редактирование в своём редакторе без тяжёлого бэкенда.

⚡ Поиск раздувают до эмбеддингов и LLM: Fuse.js ~6 КБ с нечётким поиском, кириллицей и Web Workers в 7.4.0 — чтобы находить по списку в браузере без сервера и векторной базы.

⚡ TypeScript кажется очевидным, пока не упёрлись в типы: 15 коротких приёмов от Matt Smith — satisfies, проверка «все варианты учтены», строгий режим — чтобы писать безопаснее и без лишних аннотаций.

⚛️ React-шаблон на 35 000 звёзд без хаоса в репозитории: разбор Bulletproof React на Habr и MUI X 9.3 — чтобы взять проверенную архитектуру и не собирать стек с нуля.

🔥 Ember 7.0 без сюрпризов при мажоре: в основном сняли устаревшее, путь через 6.12 и Vite по умолчанию — чтобы обновиться без лотереи.

🅰️ Angular 22 меняет правила игры: OnPush по умолчанию, signal forms и инструменты для агентов в API — чтобы заложить новый проект на актуальных примитивах, а не по инерции.

𝐒 Svelte: $state.eager и pending больше не рвут зависимости, батчи идут связным списком — чтобы асинхронный UI вёл себя предсказуемо после обновления.

📦 Solid 2 в бета-версии, звонки WebRTC в production и шрифтовые иски на 15,3 млн ₽: асинхронность как примитив, грабли CallKit и SFU, PHP-парсер для проверки сайта — чтобы не удивляться ни релизу, ни иску.

🌎 Браузер снова забирает вёрстку у хаков: column-rule и row-rule в зазорах grid/flex и HTML внутри canvas за флагом — чтобы меньше DOM-обходов и проще UI поверх 3D.

🌐 Стандарты без костылей: сравнение объектов по значению (Composites в TC39) и элемент <install> для PWA без своего JavaScript — чтобы меньше полагаться на ссылки и самописные кнопки установки.

🛠️ Агенты под контролем: statewright с фазами и лимитами, свой Claude Code за вечер на DeepSeek и экспериментальный агент доступности GitHub н

Как обычно в начале месяца мы рассказываем вам о том, что изменилось в GigaIDE за прошедший месяц — май. Соответствующий обзор за апрель доступен здесь. Ниже — краткий обзор обновлений Pro-функциональности GigaIDE, который можно найти на нашем маркетплейсе.

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

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

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

Как я собираю ГИГАХРУЩ: survival horror / ARPG в браузере без Unity, Phaser и ассет‑пайплайна. WebGL/canvas raycasting, procedural textures/sprites/sound, A‑Life, самосбор как мутация мира и миллиарды LLM‑токенов, которые всё равно не компилируются.

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

Преподаю и много пишу код, который потом нужно красиво показать — в документах, статьях и особенно в презентациях для занятий. И на днях я случайно наткнулся на то, что мой давно любимый инструмент — надстройка Code Blocks для Google Docs — просто перестал работать.

Из трёх мажоров, описанных в предыдущей статье, два не всплыли в тестах. Они всплыли в двух дизайн-ревью, которые тесты провести не могут.

Локальные LLM сейчас — это действительно мощный инструмент. Они уже вплотную приблизились к проприетарным моделям вроде Claude, особенно в задачах кодинга. Я сам активно использую локальные модели для разработки на TypeScript и Go.

На данный момент самая интересная модель для моего стека — Qwen3.6-27B. Но один только выбор хорошей модели ничего не гарантирует. Без правильных параметров вы не получите ни скорости, ни качества.

В этой статье я расскажу, с какими конкретно параметрами запускаю Qwen3.6-27B в llama.cpp (мой текущий фаворит среди бэкендов), какие метрики считаю важными, и как нашел баланс между скоростью, стабильностью и качеством.

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

TL;DR. Две нейросетевые задачи — удаление фона (ONNX Runtime Web + модель silueta) и замазывание лиц (MediaPipe Tasks Vision + BlazeFace) — запущены полностью на клиенте: ни один пиксель не уходит на сервер. Ниже — почему «в браузере», какие модели выбраны и почему, как тянуть 43-мегабайтную модель с прогресс-баром, почему лица лучше пикселизировать, чем размывать, и подробный разбор бага, на который я убил вечер: Service Worker, кэширующий .mjs/.wasm, ломает dynamic import() с ошибкой «Failed to fetch dynamically imported module».

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

Перед любой командой со стороны менеджмента и бизнеса стоит одна и та же задача «давайте быстрее — надо было еще вчера». Нас эта судьба также не миновала. Первое, с чего начинается оптимизация, своя дизайн‑система. У нас уже была своя дизайн‑система, она выручала нас во многих кейсах, но она была старая, подходы к разработке давно изменились, и UI Kit уже не отвечал требованиям. Поэтому было принято решение параллельно разрабатывать новую, с учетом всех последних требований и подходов.

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

Разработка имеет такую очередь: архитектурно наш UI Kit лежит в закрытом artifactory npm пакетом. Также есть шаблон со всеми необходимыми зависимостями и UI Kit«ом. Когда приходит время нового проекта, делается fork заготовки. Это дает быстрый старт.»

Начинаем

Давайте посмотрим, как бы начиналась разработка приложения. Возьмем для примера компонент Select. Не будем писать сами, возьмем Antd Select и через обертку emotion стилизуем его под корпоративные стили.

Структура получится такая:

Каждый, кто пишет на TypeScript хотя бы пару лет, отлично знаком со стандартным DI-сценарием: класс, декоратор @Injectable(), флаг emitDecoratorMetadata в конфиге и рантайм-магия фреймворка. Этот подход казался прорывным в 2015 году, но современный TypeScript ушел далеко вперед. У нас появились мощнейший статический анализ и продвинутый вывод типов, в то время как популярные DI-контейнеры вроде NestJS, InversifyJS или TSyringe будто законсервировались в прошлом.

Слепая приверженность старым паттернам начинает откровенно тормозить индустрию. Из-за legacy-декораторов мы оказываемся заперты в рамках медленного tsc без возможности безболезненно уйти на сверхбыстрые сборщики вроде esbuild или SWC. Наша бизнес-логика намертво заражается инфраструктурными импортами сторонних библиотек, а ошибки в графе зависимостей и скрытые утечки памяти обнаруживаются не на этапе компиляции, а уже в рантайме под нагрузкой на проде.

Но что, если заставить компилятор TypeScript проверять валидность всего графа зависимостей еще до запуска кода? Без декораторов, reflect-metadata, кастомных трансформеров и тяжелой кодогенерации.

В этой статье мы разберем концепцию «экстремальной типизации» на примере InferDI — первого DI-контейнера, где сам граф зависимостей вместе с lifetime-правилами перенесен напрямую в систему типов. Мы поговорим о фундаментальных вещах: почему полный отказ от «удобной» магии аннотаций в пользу 100% ванильного TypeScript — это лучшая инвестиция в архитектуру, безопасность, скорость сборки и долговечность вашего проекта на годы вперед.

Можно ли запустить казуальную HTML5-игру на чистом JS в Яндекс Играх, не зная геймдева и верстки? Спойлер: можно, но придется пройти через 2-3 месяца модерации.

Под катом — честный постмортем инди-проекта, созданного по вечерам на коленке. Рассказываю про костыли SPA-архитектуры на тегах <div>, продвижение и реальные графики трафика и доходов за первые недели.

Когда маркетологи хотят всё: сырые данные в GA4, запись сессий в Метрике, хитмапы в Clarity и при этом «Lighthouse 100» в PageSpeed Insights — приходится изобретать. Расскажу, как мы это сделали на небольшом проекте и во что это обошлось по времени и нервам.

Проект — нишевый агрегатор российских хостинг-провайдеров. Более 120 страниц в sitemap, 31 статья, десятки категорий услуг, живые цены, сравнения. Стек: Astro 6 + Strapi 5 + Tailwind 4, плюс Partytown, PostgreSQL, Nginx и обычный VPS на Ubuntu. Сайт собирается в статику во время билда, никакого SSR в рантайме нет.

На desktop — Lighthouse 100 / 100 / 100 / 100. На mobile с жёстким throttling (4x slow CPU) — 99 / 100 / 100 / 100. В реальных условиях и по Chrome UX Report — 100 везде. LCP на desktop — 0,5 секунды, на mobile throttled — 1,7 секунды. CLS — ноль. TBT — 10 ms на мобильном и 0 ms на десктопе.

В этой статье расскажу о свежем баге, который ронял один тип транзакций, пока остальные работали штатно. Если используете @formatjs/intl-durationformat для форматирования времени - этот кейс может сэкономить пару часов отладки.

Миграция большого legacy-проекта с Vue 2 на Vue 3 — это не только про код. Основная сложность начинается ещё до первого коммита: оценка объёма работ, поиск несовместимых API, планирование и организация процесса разработки.

Почему вообще это важно, и как донести эту мысль до бизнеса я уже описывала в другой своей статье «Ты всё ещё думаешь или уже мигрируешь на Vue 3». Рекомендую почитать.

А тут я поделюсь своим опытом, где мне пришлось лидировать миграцию: самостоятельно составлять план миграции, оценку времени, рисков и проводить саму миграцию.

Когда проект на Next.js только начинается, прямой fetch во внешний API кажется самым коротким путём. Есть страница списка, есть поиск, есть внешний источник данных, значит можно сходить туда напрямую и сразу показать результат.

На маленьком экране это работает. Но дальше почти всегда начинаются одинаковые проблемы. Интерфейс начинает зависеть от чужой структуры ответа. Ошибки приходят в форме, которую неудобно показывать пользователю. Параметры запроса приходится валидировать в UI. Потом появляется базовый URL, который не хочется держать строкой в коде. Затем появляется ключ или другой секрет, который уже нельзя светить в браузере. В этот момент становится видно, что между UI и внешним API не хватает серверной границы.

В App Router такую роль часто закрывает Route Handlers. В официальной документации Next.js они описаны как пользовательские обработчики запросов внутри app directory на основе стандартных Web Request и Response API. Они доступны только в app, по смыслу заменяют старые API Routes из pages и поддерживают GET, POST, PUT, PATCH, DELETE, HEAD и OPTIONS. (Next.js)

Смысл Route Handlers в том, что они позволяют собрать внутренний серверный контур прямо внутри приложения. Через него можно проксировать внешний API, нормализовать ответ под нужды UI, спрятать env-переменные и секреты, а также вернуть в интерфейс уже свой контракт, а не чужой.

У вас один SSG-лендинг, а платный трафик льётся из 12 кампаний под разные боли ЦА. Все ведут на дефолтный hero — конверсия в заявку проседает на 30–50%. Делать 12 лендингов дорого и убивает SEO, подменять hero на клиенте — FOUC и дефолт для поисковых ботов.

Рабочая схема, поставленная в продакшен за день: edge-функция Cloudflare Pages переписывает HTML на лету через HTMLRewriter, SSG остаётся источником истины, client-side React дублирует логику при гидратации. 200 строк кода, латенси без изменений (HTMLRewriter работает потоком), Lighthouse не страдает. Разбираю код, нюансы интеграции с vite-react-ssg и грабли из прода.

Разбираем очень неприятный баг в React Native + iOS: почему push-уведомления сохраняются на Android, но теряются на iOS в background/killed state. В статье обсудим как на самом деле устроены APNS, Notification Service Extension, App Groups и почему проблема вообще не в React Native. Будет интересно…

🧮 Математика больших чисел: из игры с нулевой суммой в игру с растущей суммой

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

В статье разобран пример автоматизации, как искать тикер с притоком капитала

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

Теперь — следующий шаг.

Я хочу поделиться идеей, как с помощью уже работающего инструмента автоматически строить эпюры Q и M для всей балки целиком. На данный момент это концепция и алгоритм, который я планирую реализовать. Буду рад услышать мнение сообщества.