Вокруг vibe coding и всевозможных LLM не стихает информационный шум.

📌 Читая заголовки выступлений на митапах и конференциях, по ощущениям, половина о том, как подружиться с ИИ, как внедрить, управлять…, организовать процесс vibe coding…

📌 Вдруг, кто не знает, vibe coding - разработка, где человек, в основном, описывает задачу на естественном языке, а LLM генерирует код. Я решил написать свое отношение к теме vibe coding.

📌 Меня удивляет, что глубоко интегрируя этот процесс, человек не погружается глубоко в суть задачи, отдавая все на откуп ИИ. В итоге получается не всегда эффективное решение, поверхностное, с возможными ошибками. Здесь стоит сказать, что важно уметь с ним общаться, правильно и точно формулировать требования, исходную задачу и требуемый результат. В этом случае, конечно, процент ошибок ниже.

📌 Особенно остро этот вопрос касается джунов. ИИ делает хуже им, предоставляя готовые ответы, которые не позволяют набирать нужный опыт. Чем решение хорошо/плохо? Почему такое решение? Подобный подход подталкивает брать готовое решение и не разбираться в вопросе самостоятельно. А на первых этапах особенно важно походить по граблям и набить шишки.
В общем, я бы сказал, что внедрять джунам AI нужно не бездумно, а подкреплять его нормальными инженерными практиками, помощью коллег.

📌 Сложно спорить, есть очевидные плюсы

- Прототипирование возможных решений. Существенная экономия времени.
- Объемная и рутинная работа. Написать CRUD или что-то аналогичное. Быстро, удобно доставить бизнес-ценность.

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

Я использую llm для генерации документации, иногда для написания тестов. С правками получается неплохо. Не всегда, правда😅

📌 Вывод в том, что ИИ, на мой взгляд, это усилитель навыков, а не замена разработчика. Как молоток не делает из человека плотника, так и ИИ не делает из новичка senior-разработчика. ИИ требует осознанности, важно оценивать качество сгенерированного кода, а не просто копировать. Соблюдать баланс, еще одна важная часть нашей экспертизы.

А какие ИИ инструменты используете вы в разработке? Добавлю небольшой опрос. Если есть мысли, пишите в комментариях, интересно будет узнать!

NgStream / Чат

TypeScript 6.0. И никаких компромиссов.

Если предыдущие версии старались сохранять максимальную обратную совместимость, то версия 6.0 нацелена на решительное избавление от legacy и установку новых стандартов «по умолчанию».

Что изменится в новой версии?

📌 Strict Mode теперь обязателен. Это не просто изменение одного флага, а глубокая смена логики наследования настроек. Теперь такие критические проверки, как noImplicitAny и strictNullChecks, становятся стандартом. Также по умолчанию будет подразумеваться директива "use strict"
📌 target es5 deprecated. Минимально возможный стандарт теперь ES2015. Отказ от ES5 позволит команде упростить внутреннюю логику. Возможно, ускорит процесс сборки.
📌 Включение параметра noUncheckedSideEffectImports по умолчанию. Позволит улучшить существующие конфиги и выявлять некорректные импорты в IDE.

Значительная часть работы посвящена удалению старых опций для упрощения конфигурации. Помечены deprecated baseUrl, --outFile, а также module resolutions node10 и classic .

Публикация финальной версии намечена на март 2026 года, а план выпуска включает этапы бета-тестирования и релиз-кандидата.

24 февраля 2026 - RC Release.
17 марта 2026 - Final Release.

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

Подробнее здесь. Typescript Iteration Plan.

#typescript

NgStream / Чат

Команда Angular в последнем релизе все же представила новый вид селекторов. Точнее, selectorless подход. Эта функциональность не просто перешла в stable режим, но и была установлена как режим по умолчанию.

Суть подхода в обращении к классу компонента напрямую, минуя использование строковых селекторов, которые задаются в свойстве selector.

На мой взгляд, изменение вида селекторов - весьма спорное нововведение по нескольким причинам.

🛠 Несоответствие стандарту HTML. Как я понимаю, selectorless раньше не внедряли специально для следования стандарту. Спецификация определяет void-элементы (например, <img>, <br>), которые не могут иметь содержимого и не требуют закрывающего тега (но в конце ставят /> , например: <img />). Поэтому формально для соответствия стандарту HTML именно Angular берет на себя задачу превращения этих инструкций в валидные DOM элементы с открывающими и закрывающими тегами. Однако, если вы попытаетесь использовать такой синтаксис напрямую в html файле без предварительной компиляции (например, через innerHTML в браузере), парсер браузера может интерпретировать это неверно, так как по стандарту HTML пользовательские элементы (custom elements) обязательно должны иметь закрывающий тег и не могут быть void-элементами.

🛠 Медленная адаптация в enterprise. Многие пользователи Angular это крупные компании и обычно изменения внедряются постепенно. Поскольку плюсы не видны (по крайней мере пока что), то просто так переписывать код не очень разумно.

🛠 Сложнее поиск компонента в дереве селекторов в devtools и в коде, если использовать имя компонента.

🛠 Самое интересное, зачем текущий html-like синтаксис превращать в JSX? (кто не знает, в Angular не html, а чуть другой формат) Мы привыкаем ко всему, но это определенно делает Angular непривычным и никаких причин для внедрения, кроме "modern Angular code", я не нашел в тексте МР.

#angular

NgStream / Чат

Корректирующая обратная связь

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

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

Рассмотрим пару примеров.
❌ «Ты всегда срываешь сроки!» // Обвинение
✅ «Я заметил, что последние два дедлайна были пропущены. Давай разберёмся, что мешает уложиться в сроки?» // Конструктивный подход.

Конструктивное общение — это навык, который можно развить. Его основы:
🔸 Уважение к собеседнику.
🔸 Конкретика в замечаниях.
🔸 Готовность помочь исправить ошибки.

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

Есть несколько причин давать корректирующую обратную связь.

📌 Ощущение безопасности. Когда критика не носит личный характер и направлена на решение задачи, люди перестают бояться ошибаться и скрывать проблемы. Поможет раньше задавать вопросы, адекватно оценивать риски.
📌 Формирование ответственности. Когда человек понимает реальное влияние своих действий на продукт, команду и клиентов, он начинает мыслить системно.
📌 Мотивация специалистов. Талантливые люди ценят рост, а отсутствие обратной связи - сигнал о стагнации и безразличии.

Получается, что это такой же инструмент инженерной культуры, как Code Review или тестирование. Если его правильно применять, это будет двигателем роста и для сотрудника, и для процессов команды, и для продукта в целом.

Если тема понравится, напишу отдельный пост и расскажу о фреймворке, который можно применять для корректирующей обратной связи.

#нетехзаметки

NgStream / Чат

На прошлой неделе релизнули 21.2

📌 Одно из нововведений - Exhaustiveness checking для @switch control flow! В этом случае требуется указание @case для каждого значения в типе. Проще говоря, появилась возможность добавить @default never;

Для тех , кто не знал, это называется "проверка на полноту", помогает убедиться при жонглировании набором значений, что задействованы все элементы Union type. Я стараюсь использовать в TS такую конструкцию для обеспечения дополнительной безопасности.
А сейчас добавлется еще один важный пункт - логика на UI теперь отражает модель данных.

// если пропустили/забыли добавить значение, компилятор вернет ошибку. В данном случае, если не указать 'reject' в @case, то получим ошибку.
type Status = 'draft' | 'review' | 'success' | 'reject';
status: Status = 'draft';

@switch (status) {
  @case ('draft') {...}
  @case ('review') {...}
  @case ('success') {...}
  @default never
}

📌 Стрелочные функции в шаблонах. Об этом уже написано в канале, не буду повторяться. Скажу, что конструкция избыточна и только размывает логику между шаблоном и классом. Шаблон все же предназначен для рендеринга, а не описания логики. А тут еще и поддержку оператора instanceof запилили. В шаблоне!
Есть нюанс. Вы не можете использовать стрелочную функцию в качестве обработчика события для вызова метода. Попытка написать (click)="() => doSomething()" приведет к ошибке на этапе компиляции (Template Type-Check error). Это ограничение связано с тем, как Angular оптимизирует привязку событий, и попытка «обернуть» вызов метода в стрелочную функцию внутри шаблона нарушает этот механизм.

📌 SignalFormControl. Здесь интереснее. Это инструмент для плавной миграции между реактивными и сигнальными формами. Позволяет применять правила, как это сделано в сигнальных формах, пример ниже. В шаблонах менять ничего не придется. Об изменениях касательно форм напишу отдельно=)

password: new SignalFormControl('', p => {
    required(p);
    minLength(p, 6);
  })

📌 Явность вместо неявности. С 22 версии OnPush стратегия по умолчанию для новых компонентов. А ChangeDetectionStrategy.Eager теперь является способом явно заявить, что компонент требует устаревшего «прожорливого» поведения. Это переименование необходимо для работы миграций. После обновления до 22, Angular CLI автоматически заменит отсутствие стратегии или Default на Eager.

📌 Интеграция с Prettier
Angular CLI теперь имеет встроенную интеграцию. При создании нового проекта .prettierrc добавляется «из коробки». Для больших команд это критически важное улучшение DX.

А вы уже мигрируете свои проекты на OnPush и сигналы или ожидаете принудительного перехода в v22?

Описание обновления.

#angular

NgStream / Чат

Обновления Signal Forms API

Еще одним полезным дополнением в 21.2 является новая утилита transformedValue для синхронизации значения с моделью.

Основные возможности
📌 Двусторонняя трансформация: функция parse (преобразование ввода → модель) и format (модель → отображение)
📌 Автоматическая обработка ошибок: Ошибки парсинга автоматически пробрасываются в родительскую форму. Ни на что не похоже?:)
📌 Гибкий механизм валидации: Функция parse может возвращать как успешный результат с value, так и массив errors
📌 Интеграция со встроенными валидаторами: Возможность возвращать стандартные ошибки валидации (например, min для отрицательных значений)
Пример использования: Пользователь вводит "20m" или "1h", а в модели данные хранятся в минутах. При неверном формате ввода форма получает соответствующую ошибку для отображения в UI.

Еще один инструмент - директива FormRoot , которая делает отправку форм полностью декларативной. Вместо навешивания на форму (submit)=submit($event) и директивы novalidate (которая отключает встроенные проверки браузера при проверке форм) используем FomRoot, которая связывает сигнал формы с шаблоном.

Обработку submit предлагается делать в специальном cb submission внутри сигнала form. Теперь не шаблон управляет отправкой, а сама форма определяет логику.

protected readonly form = form(this.credentials, {
  submission: {
    action: async () => await this.svc.save(this.credentials()),
    onInvalid: () => this.invalidSubmission.set(true),
    ignoreValidators: 'none'
  }
});

Кстати, .reset() по-прежнему сбрасывает только состояния touched и dirty. Для сброса значения формы указывать напрямую initial значение модели. В этом случае, сбросится значение формы и сигнал, содержащий модель данных.

Описание обновления.

#angular

NgStream / Чат

Вышел Vite 8.0

Главным нововведением стал переход на Rolldown, высокопроизводительный bundler на базе Rust, который заменяет связку из esbuild и Rollup для достижения кратного прироста скорости сборки.

Долгое время Vite балансировал между esbuild для сборки в режиме разработки и мощным Rollup для оптимизированных бандлов в production.

Rolldown был спроектирован для того, чтобы объединить нативную производительность (уровня esbuild) с богатой экосистемой плагинов Rollup. Теперь и разработка, и prod сборка используют одни и те же механизмы парсинга и разрешения модулей, что гарантирует идентичность поведения кода.

В экспериментальном режиме Full Bundle Mode обещают какие-то фантастические цифры:
- Старт сервера в 3 раза быстрее.
- Полные перезагрузки страниц на 40% быстрее.
- Снижение количества сетевых запросов в 10 раз.

Теперь цепочка «инструмент сборки (Vite) - бандлер (Rolldown) - компилятор (Oxc)» работает как единое целое с глубокой AST-интеграцией.

Команда предлагает специальный Migration guide, обещая плавный переход без значительных изменений в конфигах.

Более подробно можно ознакомиться по ссылке.

#angular

NgStream / Чат

На просторах интернета нашел статью о глубоком погружении и использовании Claude Code на примере Angular и решил скинуть. Мне показалось, что описано подробно и будет полезно для тех, кто сейчас разбирается в процессе.

📌 Здесь и о настройке первого проекта, пояснениях документации, Angular MCP, режимах планирования, интеграции с Git и плагинами. И даже с пайплайнами CI.

📌 Главная проблема LLM - устаревание знаний, а Angular развивается довольно быстро (Signals, Resource API), поэтому ответы могут быть некорректными. Но есть Model Context Protocol (MCP), который позволяет Claude подключаться к актуальной документации Angular CLI напрямую.

📌 Еще одна проблема - это высокая автономность, и ошибки AI могут быть фатальными. Решением является изоляция. Для этого предлагается использовать Docker Sandbox. Запуск через claude --docker изолирует агента в microVM.
Неплохая фраза, которую нашел в статье и которая описывает текущее состояние:

ваша задача - быть «пилотом», который задает курс и проверяет качество.

📌 А на прошлой неделе еще появилась новость, что Anthropic признали угрозой национальной безопасности и приказали федеральным агентствам прекратить использовать Claude. Bloomberg.

#angular

NgStream / Чат

Обновление Angular roadmap

Команда выделяет основные направления:

📌 Самое громкое изменение - повышение приоритета «Improve the AI experience for developers». Angular не просто «надеется», что LLM напишут хороший код, а системно оптимизирует свои инструкции, документацию и внутренние API, чтобы модели, вроде Gemini, выдавали качественный результат. Для оценки прогресса используется собственная инфраструктура тестирования - Web Codegen Scorer.

📌 Эволюция реактивности и Signals. Сигналы становятся центральной частью архитектуры Angular, проникая во все ключевые пакеты.

-Signal Forms. В планах обеспечение бесшовной миграции с Reactive Forms.
- Асинхронная реактивность. Внедрение примитивов resource и httpResource для обработки асинхронных потоков данных как сигналов.
- В разработке создание оберток на базе сигналов для Router и других модулей.
- Повышение производительности. Переход на zoneless и использование стратегии обнаружения изменений OnPush по умолчанию.

📌 Улучшение DX. Здесь, как я понял, команда отметила, что завершена работа над запланированными изменениями. И ничего не было написано о новых. Angular переходит на сторону популярных инструментов экосистемы.

- Vitest (Experimental, v20). Современная и быстрая альтернатива Karma/Jasmine становится частью официального тулинга.
- Стабильный HMR (v20). Горячая перезагрузка шаблонов и стилей наконец-то получила статус Stable, что делает цикл «правка-результат» практически мгновенным.

Ссылка на МР с обновлением.

#angular

NgStream / Чат

Сигналы становятся центральной частью Angular, вытесняя старые механизмы управления состоянием и запросами к шаблону. Некоторые (если не многие) проекты сейчас в состоянии перехода на новые сигнальные API.

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

Для миграции нам понадобятся два ключевых инструмента ESLint (с плагином @angular-eslint) и schematics, которые были представлены вместе с выходом нового API.

📌 Мы можем использовать правило prefer-signals. Оно помечает использование @Input как ошибку, предлагая заменить на input. Аналогично для других legacy декораторов.

📌 Что с [(ngModel)] ? Мы знаем, что можно заменить на сигнал model(), который упрощает реализацию двустороннего связывания (two-way data binding). Выглядит следующим образом: value = model.required<string>();

Здесь нам помогает правило prefer-signal-model. Поскольку сигналы не должны переназначаться, правила ESLint предлагают автоматически добавлять модификатор readonly к объявлению свойств.

В общем, с использованием правил линтера немного проще мигрировать большие enterprise проекты на новый API, писать код чище, современнее и безопаснее. Успешной миграции!

#angular

NgStream / Чат

Все же представлен экспериментальный компилятор Angular от OXC

VoidZero заявляют:
- об ускорении билда в 20 раз за счет переноса логики обработки и преобразования шаблонов на сторону Rust и интеграции с экосистемой Oxc и Vite.
- в 6 раз быстрее, чем Angular CLI и в 20 раз быстрее, чем Webpack.
- vitejs plugin с полной поддержкой HMR.

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

Из интересного - компилятор написан на Rust! И разработан с использованием искусственного интеллекта. Пишут, что инженеры использовали Claude и Codex. Агенты проанализировали проект Oxc и определили, как использовать его компоненты (Parser, Semantic, Transformer) для замены функционала TypeScript. Были внедрены высокопроизводительные паттерны Rust, такие как arena memory allocation и применение существующих SIMD crates.

Oxc Angular Compiler не планируют поддерживать в дальнейшем, поскольку задача была удостовериться в возможностях AI, его эффективности и переносе Angular single-file компиляции на Rust.

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

Команда Angular уже проводит собственные эксперименты, что позволит интегрировать решения для существующего компилятора и работать с Vite.

Ссылка на статью с подробностями.

#angular

NgStream / Чат

Недавно были новости о том, что OnPush сделают стратегией по умолчанию. И вот, MR с этими изменениями влит. Нововведение ожидается с 22 версии. Напомню, что с v21 новые проекты создаются по умолчанию в Zoneless режиме.

Что это дает?

Меньше "шума" в классах, можно убрать явное указание использования стратегии для каждого компонента.
Пожалуй, постепенно придем к тому, что компоненты будут максимально чистые, свойства декораторов будут содержать только template и styles.
Ведь указание селекторов могут убрать с переходом на selectorless подход (к сожалению), а указание standalone: true аналогично покажется излишним, поскольку подавляющее количество компонентов, так или иначе уже создаются вне модулей (NgModule, если кто помнит).

Что изменено?

📌 Если стратегия не указана, значит выбран OnPush.

📌 Если нужно оставить предыдущее поведение, то нужно вручную указать Eager. Это новый алиас для Default стратегии. Сейчас, если не указана стратегия, значит выбран Default.

Впрочем, при переходе на версию 22 миграция будет сделана автоматически.

#angular

NgStream / Чат

Angular продолжает "эволюцию" и в этот раз опубликован МР, где предлагают отказаться от "устаревшего" и, показавшегося избыточным, декоратора @Injectable. И добавить новый @Service.

В чем разница?

📌 @Service по умолчанию providedIn: 'root'. Можно вручную установить на нём параметр autoProvided: false и указать сервис в массиве providers: [] в нужном месте.
📌 @Service не поддерживает constructor-based injection, указание зависимостей возможно только через inject().
📌 @Service не поддерживает useClass, useValue и тд, только factory.

Лично я не вижу значительных преимуществ от предлагаемых изменений. Кроме большого количества материалов и AI базы знаний, которые станут устаревшими (о чем, кстати, пишут в комментариях), пострадает интуитивно понятное Angular API. Еще остается непонятным, что указывать при провайдинге на уровень платформы? Для такой более точечной настройки DI, скорее всего, оставят старый добрый Injectable. Но опять же, возникает больше чем один способ сделать одну вещь. И это отличается от привычной философии Angular.

Есть противоположная точка зрения. Якобы, вариант ниже смотрится менее понятным и с большим количеством бойлерплейта.

@Injectable({ providedIn: 'root' })
export class BookStore {}
// Предлагаемая версия
@Service
export class BookStore {}

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

Ну и здесь в чате можете не стесняться:)

#angular

NgStream / Чат

В марте Temporal API перешел в статус Stage 4 (что означает добавление в стандарт) в TC39 и официально включен в спецификацию ECMAScript. Это эпохальное событие для JS.

На момент публикации заметки - на MDN статус Widely available. Не поддерживается в Safari.
Temporal предлагает строгое соблюдение формата ISO, удобную работу с часовыми поясами, корректную индексацию месяцев и иммутабельность объектов, позволяющих избежать случайных ошибок при математических операциях с датами.

Подробно о минусах встроенного Date писать не буду, мы все и так об этом знаем.

📌 Для чего уже можно применять?
- Простые даты. Создание, манипуляции без вычитания единицы из месяцев.
- Операции - добавление дней, месяцев или часов возвращает новый объект.
- Явная и предсказуемая работа с часовыми поясами.
- Форматирование - встроенное форматирование с учетом локализации.

📌 На мой взгляд, это шаг в сторону отказа от библиотек. Или выбор одной из них, поскольку есть вероятность, что внутри они будут переходить на новое API для простоты, уменьшения количества костылей и оптимизаций.

📌 Завершение стандартизации означает, что Date станет историческим артефактом и останется только для обратной совместимости. Можно будет сказать: "а я еще Date использовал".

#js

NgStream / Чат

Команда Angular добавит функционал debounce для асинхронной валидации форм.

📌 По факту, это параметр в функции validateAsync и validateHttp . Аналогично debounce из RxJS он позволяет сократить количество запросов при проверке данных. В рамках изменений был внедрен новый тип данных DebounceTimer, который унифицирует настройку времени ожидания. Теперь выполнение проверок может быть отложено на заданное количество миллисекунд или до завершения работы конкретной функции.

В общем, приятное дополнение для Forms.

🎉 Кроме того, с версии Angular 22 Resource API (resource, rxResource, httpResource) перейдет в статус stable!

#angular

NgStream / Чат

Довольно позитивная новость, о которой забыл написать в канале.

На апрельском Q&A Angular community сообщили об изменении roadmap. В частности, о приостановке внедрения selectorless подхода для компонентов. Приоритетом стала стабильность синтаксиса для корректной генерации кода AI инструментами, т.к. они эффективны, когда используется консистентный и хорошо изученный синтаксис.

В общем, руководством была взята пауза и решено временно отказаться от масштабных breaking changes, чтобы не нарушать работу LLM-моделей, которые только начинают эффективно осваивать текущие стандарты Angular. Но планируют вернуться позже.

Или все же одумаются, что это может поломать работающие подходы, завязанные на селекторы.

#angular

NgStream

C версии 22 resource API перейдут в статус stable. Незамеченной оставалась еще одна фича - resource composition. Пока в experimental.

📌 Суть нововведения в том, чтобы показывать на UI текущее состояние, пока загружается новое. Разберем простейший пример - отображаем погоду в Санкт-Петербурге. Кликаем на Ростов.

Что происходит сейчас?

📌 Resource переходит в состояние loading, value - undefined. Карточка погоды исчезает, отображается skeleton, загружаются данные, а затем появляется карточка с новым городом.

📌 Как вы уже догадались, используя эту функцию, предлагается отображать предыдущее состояние и заменять на него loading state. Что позволит избегать мерцания/лишних переключений на экране.

Ссылка на MR.

#angular

NgStream

Как вы знаете, 19-20 мая прошла Google IO.

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

Обновили Antigravity. Представили версию 2.0, которая полностью переработана под мультиагентную оркестрацию. Теперь это не просто редактор, а хаб, где разные агенты могут параллельно решать задачи. В качестве стандартной модели используется Gemini 3.5 Flash (новая модель).

Gemini Spark - агент, который не просто отвечает на вопросы, а живет в вашем контексте, взаимодействуя с Google Workspace и сторонними сервисами.

Не обошлось и без Angular. Куда же без него?)

Boundary (Error Boundaries)
Новый блок @boundary позволяет изолировать ошибки. Был показан виджет «бесплатной доставки». Если он упадет из-за ошибки в данных, то не положит весь процесс оформления заказа. Пользователь увидит fallback UI, в котором можно реализовать логику повторных запросов.

@boundary {
  <app-promotional-widget>
}
@error (let err) {
  <app-default-promotional-widget>
}

Статус: Developer Preview в Q3 2026.

Обновленный Switch Statement
Синтаксис стал чище и, что важнее, безопаснее.
- Multiple Case Matching. Группировка условий теперь избавляет от лишнего бойлерплейта.
- Exhaustiveness Checking. Если вы используете union-типы, добавление блока default с ключевым словом never позволит Angular проверить полноту обработки всех сценариев на этапе компиляции. Это исключает runtime-ошибки при расширении типов.

Inline-функции
Конец многолетних дискуссий: Марк Томпсон официально подтвердил, что использование коротких стрелочных функций в шаблонах нормально. Это значительно улучшает DX для простой логики, не влияя негативно на производительность. Но если вы следуете правилу - "сложная логика в классе, а небольшие преобразования в шаблоне".

И повторили, что перейдет в статус stable:

- Signal Forms.
- Angular Aria. Напомню, что это набор из 11+ паттернов доступности (от Toolbars до сложных меню). Google берет на себя логику ARIA-атрибутов, оставляя разработчикам только CSS. Важнейшее новшество - появление test harnesses, что делает тестирование доступности тривиальной задачей.
- Asynchronous Reactivity. Главный архитектурный анонс API resource и httpResource. Это фундамент новой модели работы с асинхронными данными.

Версия 22 ожидается на следующей неделе (3 июня).

#angular

NgStream

Многие с появлением AI инструментов поверили, что разработчики не нужны и агенты будут «писать код за человека». Это главное заблуждение, на мой взгляд.

В марте прошла AI Dev Day 2026 от Яндекса. Эта конференция стала моментом истины для всей индустрии. Главный вопрос - стали ли разработчики действительно продуктивнее спустя год тотальной «нейронизации»?

Авито представили данные внутреннего исследования: написание кода занимает лишь 32% времени разработчика. Если ваш AI-агент станет идеальным, получится сэкономить только треть рабочего дня. Цифры из Яндекса аналогичные - разработчики тратят 35% на написание кода, 30% времени на коммуникации, 15% на планирование и поиск информации, и по 5% на DevOps, работу с данными и кодревью.

Я посмотрел не все, только некоторые выступления. В частности, ТБанк представил довольно интересные метрики на основе технических данных (DORA), удовлетворенности (SPACE) и когнитивной нагрузки (DevEx). Но слишком мало подробностей. Конечно хотелось бы услышать, как считали и как подкручивали процессы.

Понятно, что для опытного разработчика это помощник, не заменитель. На практике агенты способны закрывать лишь часть рутинной работы. Более того, опыт сеньоров становится еще более критичным: например, в Amazon именно senior-инженеров явно просят валидировать изменения в коде, которые вносят ИИ-модели и менее опытные сотрудники.
Компании понимают, что оптимизировать надо не только написание кода, но и остальные блоки, и прилагают усилия к уменьшению времени поиска, ускорению код ревью и тд. Общая производительность определяется не суммой усилий всех участников, а пропускной способностью одного единственного узкого места.

#ai

NgStream