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

MDN Baseline badges и влияние на поддержку браузеров в Angular

Начать стоит не с самого Angular, а с важного обновления в веб-документации MDN (Mozilla Developer Network). Там появились Baseline badges (метки), которые позволяют быстро оценить, насколько целесообразно использовать новую фичу — например, часть браузерного API.

Система простая. MDN смотрит на поддержку в четырех основных браузерах (Chrome, Edge, Firefox, Safari) и ставит одну из трех меток:

• Limited availability — фича реализована не во всех браузерах

• Newly available — поддерживается всеми браузерами, но менее 2,5 лет

• Widely available — поддерживается всеми браузерами не менее 2,5 лет

Это сильно упрощает работу: не нужно постоянно проверять таблицы совместимости.

Причем тут Angular?

Причина, по которой эта тема важна в контексте Angular, заключается в том, что с недавнего времени фреймворк формирует свой browserlist поддержки именно на основе widely available baseline. Перед релизом новой версии Angular ориентируется на набор браузеров примерно 30-месячной давности. Например, для Angular 20 используется этот baseline.

Такой подход может служить надежной точкой опоры при принятии решений о поддержке браузеров в проектах.

Standalone API и постепенный отказ от модулей

В Angular 15 API Standalone был помечен как stable с явной целью — заменить и со временем полностью вытеснить NgModule. Standalone-подход позволяет определять «модуль» с одним declaration в виде компонента, директивы или пайпа.

Согласно RFC, ключевые причины изменения — уменьшение шаблонного кода и улучшение tree shaking. Но если улучшение tree shaking действительно возможно при полном отказе от NgModule, то вторая причина выглядит спорно. Ручное указание импортов для каждого компонента может, наоборот, увеличить шаблонность.

Тем не менее сообщество в целом идею поддержало.

Команда Angular долго утверждала, что NgModule останется опциональным, но факты говорят о постепенном вытеснении:

• Angular 17 — standalone-проекты создаются по умолчанию

• Angular 19 — standalone: true автоматически добавляется всем компонентам, директивам и пайпам

• Появляются новые API (например, @defer), работающие только со standalone

Это формирует ощущение, что NgModule в перспективе может быть объявлен устаревшим (deprecated).

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

С учетом текущей динамики можно ожидать, что standalone станет стандартом де-факто. Однако способ внедрения этого решения со стороны команды Angular вызывает вопросы и выглядит не самым аккуратным.

Inject вместо DI (dependency injection) в конструкторе

Функция inject(), появившаяся в Angular 14, изначально воспринималась как шаг к более функциональному и реактивному подходу. Это было особенно заметно при переходе от классовых Route Guards к функциональным.

Со временем преимущества inject() стали очевиднее:

• Проще наследование. inject() избавляет от необходимости прокидывать зависимости через super().

• Изменения в ECMAScript 2022, которые привнесли стандартные class fields. Различия в тайминге инициализации полей могут вызывать проблемы с DI через конструктор. inject() полностью обходит эту проблему.

• Код становится более гибким и future-proof решением.

Новый control flow в шаблонах

Angular 17 представил новый встроенный control flow, который пришел на смену ngIf, ngFor и ngSwitch (впоследствии помеченных как deprecated).

Ключевые изменения:

• Появились @else if и более читаемый else без ng-template.

• У @for появился @empty, которое позволяет отображать кейс с пустым массивом.

• Упростился трекинг элементов — необходимость в trackBy-функциях возникает реже.

• @switch остался близок к прежнему поведению.

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

Signals

Signals — не новый концепт для фронтенда: его аналоги использовались в разных формах еще со времен Knockout. В Angular signals позиционируются как более легкая альтернатива Observable из RxJS.

Signals проще в управлении, лучше интегрированы во фреймворк и отлично подходят в качестве строительных блоков для OnPush change detection. В сочетании с effect, автоматически пересчитывающим callback при изменении зависимых сигналов, получается удобное API для создания компонентов с OnPush change detection’ом.

Билдеры: переход от Webpack к esbuild

Начиная с Angular 18, экосистема активно смещается от Webpack в сторону esbuild. Практика показывает ускорение сборки и более простой процесс разработки.

Однако в реальных проектах переход возможен не всегда. Например, при использовании динамического Module Federation все еще приходится полагаться на Webpack custom builder. Альтернативные решения либо сталкиваются с проблемами производительности, либо не справляются со спецификой Angular-сборки.

Сейчас остается открытым вопрос поддержки и расширяемости билд-процесса, и здесь хотелось бы видеть больше внимания со стороны команды Angular.

SSR в Angular

Команда Angular Universal была объединена с основной командой фреймворка, а SSR теперь развивается в рамках пакета @angular/ssr. Это позволило отказаться от экспериментальных решений и, наконец, решить проблему регидратации.

Текущее решение стало готовым к продакшену и заметно стабильнее по сравнению с опытом использования SSR в Angular 16. Вектор развития в этом направлении можно оценить как однозначно позитивный.

Zoneless Change Detection

Zoneless Change Detection несколько версий находился в статусе developer preview и неожиданно стал production-ready в Angular 20.2.

Отказ от Zone.js — серьезный архитектурный шаг. Signals действительно упрощают управление CD, но остаются вопросы, связанные с заменой applicationRef.isStable и управлением макротасками, которые раньше использовались для контроля первого состояния стабильности приложения.

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

Взгляд в будущее Angular

До релиза Angular 21 ожидался период стабилизации после волны крупных изменений — и частично эти ожидания оправдались.

Можно предположить следующие тренды:

• Standalone окончательно закрепится в гайдах и best practices.

• Интеграции с Signals продолжат развиваться и могут вытеснить RxJS из части сценариев.

• Zoneless станет стандартом по умолчанию (спойлер: это и произошло в Angular 21).

• Хочется верить, что появится больше возможностей для кастомизации билд-процесса.

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