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

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).

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

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