TypeScript *

В Next.js формы и inline CRUD довольно быстро упираются в одну и ту же развилку. Можно пойти привычным путём и собрать ручной API: отдельный route handler, fetch из клиента, локальные флаги pending, error, success, плюс своя логика для blur, Enter, Escape и закрытия редактора. На небольшом примере это выглядит терпимо. Но как только в проекте появляются создание, переименование, удаление и несколько inline-форм на одном экране, код начинает расползаться не по бизнес-логике, а по обвязке.

Проблема в количестве промежуточных слоёв между формой и записью данных. Отдельный endpoint, отдельный клиентский submit, отдельный формат ответа, отдельные флаги состояния, отдельная синхронизация UI после успеха или ошибки. Для таких сценариев Server Actions в App Router нужны потому, что для форм и inline-редактирования дают более короткую и предсказуемую write-точку.

В проекте примере Workbench покажем на создании, переименовании и удалении проектов, секций и заметок. У формы есть action, серверная функция получает FormData, возвращает типизированное состояние, а клиент живёт вокруг одного паттерна: state, formAction, isPending. В результате форма собирается как связанный цикл, а не как набор разрозненных обработчиков.

Почти всё, что я считал про устройство Claude Code изнутри, оказалось упрощением. Я распаковал бандл версии 2.1.88 — около 1884 файлов в src/ — и пошёл сверять, что из общеизвестного правда, а что нет. Ниже восемь мест, где расхожее мнение разошлось с кодом, и под конец одна вещь про безопасность, которая мне самому не понравилась.

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

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

Привет!

Это 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‑токенов, которые всё равно не компилируются.

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

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

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

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

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

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

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

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

Начинаем

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

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

Рассказываем, как заменили Context.dev API на Jina Reader и Vercel AI SDK, чтобы генерировать DESIGN.md для AI-агентов без платной подписки.

Если вы когда-нибудь пытались скормить сырой HTML с глубокой вложенностью React-компонентов в LLM-контекст, вы знаете эту боль: 20 000 токенов уходит на бесполезный <div>-суп и закрывающие теги. Именно для решения этой проблемы одни хорошие люди и создали designmd.supply — инструмент, который парсит сайт и собирает из него структурированный DESIGN.md для AI-ассистентов. Проблема в том, что его ядро опиралось на платный Context.dev API, который недавно закрыл бесплатный доступ.

Открытый форк open-designmd решил эту задачу иначе: все проприетарные эндпоинты заменены на бесплатные альтернативы — Jina Reader для парсинга HTML в Markdown, Microlink для скриншотов, и любой LLM-провайдер через OpenRouter или Ollama. Весь пайплайн работает локально, без подписки и кредитных карт.

В этом разборе — как именно устроен этот переход, с конкретными фрагментами кода, ловушками и решениями, которые мы приняли по ходу.

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

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

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

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

Семь дней — от разрозненных заметок и черновиков до работающей AI-базы знаний, где искусственный интеллект сам структурирует контент, обновляет документацию и ищет противоречия.

В статье — практический опыт создания LLM Wiki на стеке Astro + Starlight + Markdown. Без Notion, без Google Docs, без проприетарных форматов. Контент — просто файлы, AI-агенты — редакторы с четкими правилами из AGENTS.md, хостинг — бесплатный GitHub Pages.

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

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

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

Принципы SOLID, DRY, KISS во фронтенде работают ровно так же, как в любой другой разработке. Но если открыть почти любой проект, всё равно натыкаешься на мешанину.

Причём дело обычно не в том, что код «грязный» — он как раз бывает типизирован и проходит linter. Дело в том, что эти принципы отвечают на вопрос «как написать», а не «зачем мы вообще это пишем». А без ответа на «зачем» чистый код превращается в красиво оформленную путаницу.

На примере такой вещи, как store попробуем ответить на вопрос: что вообще такое контракт, зачем же нужна типизация и действительно ли это помогает в разработке.

Недавно я решил завести собственный блог. Сначала посмотрел в сторону SSG, но они показались мне не слишком удобными для того сценария, который я хотел получить. Затем попробовал несколько CMS, однако быстро упёрся в другую проблему: мой сервер оказался слишком слабым для большинства современных решений.

В итоге ни одно из готовых решений так и не смогло закрыть все мои требования одновременно. Так и появилась идея сделать небольшую файловую CMS на Rust, которая не требует базы данных, не потребляет много памяти и при этом остаётся достаточно гибкой для повседневного использования.

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

Мы были двумя 16-летними студентами колледжа, чья программа безнадёжно отставала от индустрии. Пока на парах проходили технологии пятилетней давности, реальный мир уже жил в экосистеме React, Next.js и WebAssembly. Пришлось учиться самим — по вечерам разбирая современный стек и споря об архитектуре. Эта тяга сподвигла нас создавать не абстрактные проекты для портфолио, а реально полезные инструменты, которыми хочется пользоваться каждый день.

Так четыре года назад родился наш проект — 167 утилит и 8 интерактивных песочниц в одном сервисе. Форматтеры, конвертеры, генераторы паролей и UUID, DevOps-конфиги, шпаргалки и песочницы для Python, SQL и Bash. Всё сделали прямо в браузере, без сервера.

Рассказываем как это было.

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

открыл DevTools → нашёл элемент → поменял значение → понравилось → скопировал → переключился в редактор → нашёл файл → вставил.

Это семь шагов ради однострочного изменения. Я сделал LiveStyleSync, чтобы это был один шаг.

Когда «снисходительность к входным данным» становится ловушкой? Когда имя хука начинает диктовать потребителю модель мышления? Когда подстановка снимка состояния — это не приём, а сигнал, что фазы жизненного цикла стоят не на том такте? Три мажорных релиза одной библиотеки — про эти три вопроса.

Онлайн доска DGRM.net кеширует файлы в постоянном кеше. Постоянный кеш не удаляется при закрытии вкладки. Рассказываю как хранить большие файлы в браузере.

Статья о том, как получить наблюдаемость (observability) в приложении с минимальным кодом, а бонусом получить структурированные логи с типизированными шаблонами, автоматическую корреляцию со спанами OpenTelemetry, всё это с помощью набора библиотек, которые я называю CleverBrush Framework.