TypeScript *

Deep dive в техническую архитектуру: как работают воркеры, как создаются агенты за 2-3 минуты, и как устроена библиотека переиспользуемых утилит

Все говорят, что скоро Claude и GPT заменят программистов. Я руковожу студией разработки и вижу другую картину: AI не заменяет инженеров, но беспощадно наказывает за лень и отсутствие архитектурного мышления.

В этой статье я на живом примере покажу разницу между популярным «вайб-кодингом», который порождает неработающих монстров, и подходом Spec-Driven Development. Продемонстрирую, как превратить LLM из генератора случайного кода в костюм Железного человека для инженера, поделюсь ссылкой на репозиторий с реальным кодом и спецификацией, написанными ИИ, и расскажу, какие 5 навыков теперь нужны разработчику, чтобы оставаться в профессии.

Команда JavaScript for Devs подготовила перевод статьи о нововведениях WebStorm 2025.3. В обновлении — новая тема интерфейса Islands, серьёзные улучшения для монорепозиториев, поддержка удалённой отладки и интеграция умных ИИ-агентов прямо в IDE.

Привет, Хабр. Я Сергей Осипов, архитектор дизайн‑системы в T2. Вместе с моим коллегой, Данилом — экспертом группы разработки — мы подготовили материал, в котором подробно разберем процесс настройки UI‑Kit на React — от установки зависимостей до сборки готового пакета. Ниже в статье вы прочитаете о полном цикле разработки: сборке, тестировании, линтинге и документации.

Как превратить Claude Code из мощного ассистента в профессиональную платформу оркестрации с 33+ специализированными агентами.

Команда JavaScript for Devs подготовила перевод большого апдейта от команды TypeScript. Разработчики рассказали, как идёт переписывание компилятора на нативный код, что уже работает в превью TypeScript 7, какие ограничения остаются и почему версия 6.0 станет последним релизом на JavaScript. Новый TypeScript обещает серьёзный рывок в скорости и стабильности — самое время понять, что нас ждёт.

Пользователи ненавидят спиннеры. Они хотят видеть лайк сразу после клика. Optimistic UI решает эту проблему, но создает новую: что делать, если сервер вернет ошибку?

В императивном коде (Promise/async-await) откат состояния превращается в ад из try/catch и ручных мутаций переменных, порождая Race Conditions.

В этой статье я покажу, как реализовать надежный паттерн Compensating Transaction на чистом RxJS. Мы построим архитектуру, где состояние это поток, который невозможно "сломать" частыми кликами или сетевыми сбоями. Никаких if/else, только чистые потоки.

Недавно команда TypeScript представила TypeScript 7 — новую версию, переписанную на Go. Главные обещания: до 10× ускорения компиляции и до 8× более быстрый старт анализа проекта. Но самое интересное спрятано чуть глубже: вместе с TS-Go появляется полноценный LSP-сервер, встроенный прямо в компилятор.

Для многих IDE это шаг вперёд.
Для нас, команды OpenIDE, — это ещё и освобождение от ограничений, с которыми TypeScript приходилось поддерживать долгие годы.

В статье делимся контекстом, собственными экспериментами и наблюдениями — что уже работает, что нет и как новый сервер ощущается в реальной IDE.

Меня зовут Артём. Я — fullstack-разработчик уровня Middle, работаю с проектами на Python, JavaScript, Golang, Rust. В этой статье хочу рассказать о том, как я, подсмотрев западное приложение Kahoot, решил с нуля разработать собственную платформу для интерактивного обучения с огромным количеством ИИ-функций.

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

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

Казалось бы, задача простая: берёшь любую библиотеку, читаешь файл и показываешь. На практике всё оказалось гораздо интереснее.

Привет, снова Костя из Cloud.ru. Мы поговорили уже про as для типобезопасного полиморфизма, asChild для композиции и FACC для вариативного дизайна. Но что, если я скажу, что есть способ комбинировать логику ещё элегантнее и не смешивать ее с отрисовкой? Сегодня разбираем полиморфные декораторы - HOC'и на стероидах.

Как мы провели 12,000+ API-вызовов к 11 моделям, открыли правило 60-70, и построили систему маршрутизации с ROI 4,853x

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

До этого «скоро» ещё далеко, но это не повод не использовать ИИ-агентов в автоматизации различной рутины. Например, в написании платёжных интеграций для POS-терминалов в разных странах. Передать ИИ-агентам такую задачку — не очень просто, но у нас получилось! Сегодня расскажем, как мы это сделали.

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

LLM Judge для валидации образовательного контента: архитектура кросс‑модельной оценки с бюджетом $0.014 за курс

Как мы решили проблему «стохастической дивергенции» при генерации уроков и снизили затраты на валидацию в 17,000 раз по сравнению с ручной проверкой.

Я работаю старшим фронтенд-разработчиком в it-отделе одного из крупнейших федеральных застройщиков. Специфика разработки в такой непрофильной компании — сроки спускаемые сверху и вообще не имеющие корреляции с реальными ресурсами и возможностями команды. Именно поэтому мы работаем очень быстро, постоянно пытаясь получить (максимум результата)*3 за (минимум времени)/4.

В этих условиях мы делали большие интеграции с headless CMS Directus и непосредственно с бекендом, используя моковые данные на фронте.
Интеграции были большие и быстрые — и вот тут-то и стало видно, что большинство фронтенд-разработчиков не очень понимают, как подготовить интеграцию, чтобы потом было быстро и не больно заменять моки на реальные ответы. В этой статье пойдет речь о таких подходах на фронтенде,

А ещё — без бюджета на мощную инфраструктуру, опыта работы в команде и прокаченных софтов.

В этой статье — путь наших студентов, которые разработали приложение для деловых знакомств на базе Python и TypeScript. Сами выбрали стек, организовали командную работу, проводили ретро, учились распределять неинтересные задачи и ошибались в оценке сложности тасков. Кому интересно почитать про нюансы создания такого проекта и что в итоге получилось, приглашаем под кат. 👇

Привет, с вами снова Костя из Cloud.ru. Мы поговорили про паттерн as для типа безопасного полиморфизма и asChild для чистой композиции. Но сегодня поговорим о подходе, который даёт такую гибкость в вариативном дизайне, что дизайнеры будут гордиться вами - FACC (Function as Child Component).

Пять лет назад мы запустили интернет-магазин на Nuxt 2. За это время он превратился в классический монолит: вносить правки стало дорого, а сайт начал «задыхаться» под нагрузкой. Когда вышел Nuxt 3, перед нами встал выбор: пытаться оживить проект через Nuxt Bridge или переписать всё с нуля.

Мы проанализировали код и поняли: плавная миграция для нас — это путь к созданию «зомби-проекта». Слишком много фундаментальных отличий: Options API против Composition API, Vuex против Pinia, смена логики роутинга и несовместимость ключевых библиотек.

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

Внутри кейса:
• 4 технических «фаталити», которые делают миграцию легаси-монолита невозможной.
• Архитектура FSD + Nuxt 3: как мы подружили фронтенд с бэкендом на Symfony и навели порядок в зависимостях.
• Паттерн «Фабрика»: как упростить сложную логику доставки в Composition API.
• Бонус: почему благодаря правильному старту недавнее обновление с Nuxt 3 до Nuxt 4 заняло у нас минимум времени, в отличие от мучений с Nuxt 2.

Если вы всё еще поддерживаете проекты на второй версии и боитесь подступиться к обновлению — этот опыт для вас.

После работы с React/Vue/Angular захотелось вернуться к основам, но с современными возможностями. Сделал RWC — библиотеку реактивных веб-компонентов.

Ключевые преимущества:
• Совместимость — компоненты работают в любом проекте
• Производительность (сигналы для реактивности) — точечные обновления DOM
• Простота — минимальный API, легко обучать команду
• TypeScript-first — типизация из коробки без костылей

Компоненты, написанные на RWC, можно встроить в React, Vue, Angular или даже legacy jQuery-проект. Никакого vendor lock-in.

Библиотека весит <10KB, компоненты работают в любом проекте.