Angular против React: зарплаты, кризис в IT и почему корпорации остаются на Angular

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

Я, Александр, автор телеграм-канала «Shulepov Code ^[1]», поговорил с Олегом Щёголевым — frontend-разработчиком, преподавателем, ментором и специалистом по Angular автором Telegram-канала «SUMMON_THE_CODER ^[2]».    

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

Из науки во фронтенд: как начинается путь Angular-разработчика

Александр: Олег, расскажите немного о себе: образование, путь к профессии и как вы пришли к Angular.

Олег: Мой путь был довольно осознанным, хотя я учился не на IT-направлении. Моё образование связано с микро- и наноэлектроникой: это научная область, где исследуют материалы, необходимые для работы оперативной и постоянной памяти ^[3]. У меня была диссертация на эту тему. После окончания обучения я понял, что в науке ^[4] мне будет сложно: вознаграждение не соответствовало затраченным усилиям. В тот момент я уже работал около IT – в Банке России, но занимался сетями. Позже стало ясно, что и это направление для меня слишком узкое: оно не давало того развития, которого хотелось. После увольнения из банка у меня был своего рода «золотой парашют». Можно было потратить его на отдых, а можно было растянуть на несколько месяцев, купить курсы, книги и попробовать изменить жизнь. Я выбрал второе: заперся дома и учился семь дней в неделю. Параллельно нашёл part-time работу примерно на один день в неделю, а всё остальное время занимался обучением. Чуть меньше чем за год я вошёл во фронтенд.

Александр: Не было жалко уходить из науки?

Олег: Наука – очень интересная область. В то время были большие надежды на нанотехнологии, это направление активно обсуждалось. Но на практике всё оказалось сложнее. Я не жалею о научном образовании: оно помогает мыслить системно, а иногда даже понимать научные шутки раньше, чем их объясняют.

Александр: Что вы изучали в тот период, когда решили уйти в разработку?

Олег: Я купил курсы. Сейчас кажется, что курсов миллион, но тогда выбор был гораздо меньше. Одной из крупных платформ был GeekBrains. Там было несколько направлений: фронтенд, бэкенд и, кажется, мобильная разработка. Я выбирал, чем мне было бы интересно заниматься, и остановился на фронтенде. Тогда в обучении был React, его уже активно продвигали как основной вход во фронтенд. Я прошёл курс, параллельно покупал книги по Computer Science и смежным темам, но основной базой стал именно GeekBrains.

Александр: Почему вы выбрали фронтенд, а не бэкенд?

Олег: Обычно говорят: «Мне нравится фронтенд, потому что я сразу вижу результат на экране». В моём случае это тоже было важно, но позже я понял другое: фронтенд – это первый рубеж знакомства пользователя с продуктом или системой. Каким бы сильным ни был бэкенд, если фронтенд плохой, первое впечатление ^[5] о продукте будет испорчено. Мне захотелось развиваться в направлении, где я могу делать продукты, которыми приятно пользоваться. В то время веб активно набирал обороты: компании массово переходили к SPA, веб-приложениям, новым интерфейсам. Это выглядело как очень перспективная область.

Александр: Почему именно Angular, а не React? Сначала ведь у вас был React?

Олег: Да, сначала был React. Можно было бы красиво сказать, что я выбрал Angular из-за архитектуры, Google и enterprise-подхода, но на самом деле всё было проще. Я пришёл в первую компанию и сказал: «Я учил React». Мне ответили: «А у нас Angular. Будете работать?» Терять мне было нечего: первая работа, новый фреймворк, можно переучиться. Тогда это был ещё первый Angular, AngularJS. Было непросто. Я пришёл не на учебные кнопки и блоки, а на большой рабочий продукт: Docker, крупный проект, много логики. После учебного React это был серьёзный переход. Первые полгода были действительно тяжёлыми.

Александр: Где вы брали информацию и как обучались Angular?

Олег: С информацией тогда была проблема, особенно на русском языке. Хороших русскоязычных материалов по Angular почти не было. Очень помогали индийские туториалы на YouTube. Позже поворотной точкой стал курс Владилена Минина на Udemy – кажется, по Angular 8 или 9. После него картина начала складываться. Потом я открыл для себя Максимилиана Шварцмюллера, у него очень сильные курсы по разным технологиям. Мой путь был таким: документация, курсы, практика и постепенное понимание.

Александр: Есть ли проект, которым вы особенно гордитесь?

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

Александр: Это закрытый проект или можно назвать компанию?

Олег: Компания называется PIR Expo. Она проводит выставки в сфере HoReCa: ресторанный бизнес, гостиничный бизнес, кофейный бизнес.

Александр: И всё это на Angular?

Олег: Да. В компании проекты в основном на Angular: виджеты, небольшие приложения, админка, вспомогательные инструменты. Практически всё переписано на Angular.

Александр: Вы сейчас работаете в найме, на себя или в команде?

Олег: Основная занятость – в компании, в команде. При этом есть менторство, IT-направления и дополнительные проекты, которые иногда приходят по знакомству или через нетворкинг.

Александр: То есть вы совмещаете найм и самостоятельные проекты?

Олег: Да. У меня оформление как ИП, поэтому со стороны может казаться, что это фриланс. По сути, я работаю и в компании, и самостоятельно, но основная часть времени уходит на основную команду.

Александр: Что сейчас вам ближе: фриланс или найм?

Олег: На данный момент – найм. В наше время стабильность многое решает.

Александр: Был ли проект, который серьёзно «вынес мозг»?

Олег: Да. Я работал над сайтом и гибридным приложением аэропорта Шереметьево на Angular. Нужно было обновить карты терминалов. Карты терминалов – это огромные SVG и JavaScript-структуры данных, которые почти не прощают ошибок. Если ошибиться на один вложенный объект, карта может полностью сломаться. Пользователь в аэропорту масштабирует карту, перемещает её, видит подсветку терминалов, строит маршрут. Всё это сложно устроено. Документации фактически не было. Пришлось примерно неделю дебажить и распутывать, как всё работает. Помогло то, что удалось найти разработчиков из предыдущей команды и вместе разобраться в логике ^[6].

Александр: То есть если проект достался после прошлой команды, иногда нужно искать этих людей?

Олег: Да. На том же проекте была ещё одна сложная история: Angular использовался на фронте, на стендах с картами, на часах. После обновления Android API перестали работать уведомления о рейсах. Приложение было не новым, Angular был обёрнут Ionic, сверху было несколько уровней обёрток. Мы долго разбирались, но, насколько помню, задачу до конца тогда так и не довели.

Александр: Был ли случай, когда вы «положили» проект?

Олег: С точки зрения ^[7] фронтенда вспоминаются две истории.

Первая – миграция на новый SSR в Angular. В новом SSR изменилась логика обработки ошибок в шаблонах. У нас был e-commerce-проект, где много условий: скидки, промокоды, разные варианты рендера. При определённых условиях получалась невалидная вёрстка, например ссылка внутри ссылки. Браузер на клиенте мог это «съесть», но SSR падал сразу. Ошибка ^[8] выглядела как 500: сервер упал, BFF не работает. Мы сделали релиз, ушли довольные, а потом получили сообщение, что фронт лежит. Бэкенд работал, но фронт падал. Полдня ушло только на то, чтобы распутать причину.

Вторая история связана с системой продаж билетов. Мы мигрировали на новую библиотеку динамических форм. Раньше пользователи покупали 5-10 билетов, и всё работало. Потом появились новые типы билетов и анкет, компании начали покупать по 50-70 билетов. Каждый билет – большая анкета: десятки полей, чекбоксы, селекты, динамические зависимости. Нагрузочное тестирование фронтенда мы не провели. В итоге при создании десятков анкет инициализировалось слишком много инстансов библиотеки, вкладка уходила по памяти и падала. Пользователи несколько дней не могли нормально покупать билеты при определённых сценариях. Пришлось срочно исправлять.

Александр: Хотели ли вы когда-нибудь бросить программирование?

Олег: В целом – нет. Я удачно попал в профессию, потому что это именно то, чем мне интересно заниматься. Бывают периоды дедлайнов, когда несколько дней подряд сидишь за задачами, смотришь в окно и думаешь: «Кажется, я больше не хочу этим заниматься». Но дедлайны проходят, и интерес возвращается.

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

Сложные фронтенд-задачи почти всегда связаны не с «кнопочками», а с архитектурой, производительностью, SSR, памятью и поддержкой старого кода.

Рынок Angular: крупные проекты, зарплаты и поиск работы

Александр: Можете назвать крупные проекты, которые работают на Angular?

Олег: Начнём с Google, потому что это создатели Angular. Есть заблуждение, что у Google не так много проектов на Angular. На самом деле открытых проектов видно немного, но внутренне Angular используется очень широко. Из открытого можно назвать Google Fonts, Cloud Console для управления облачными ресурсами. Раньше веб-интерфейс Gemini тоже был на Angular, но сейчас я не уверен, потому что появился Google AI Studio. Google сами говорили на стримах, что внутри у них в репозитории более 600 собственных проектов. Они сами являются крупным потребителем своего продукта. Из российских примеров можно вспомнить T-Bank, который активно использует Angular и связан с популярной UI-библиотекой. Также есть банки вроде PSB Bank, Росбанка, крупный ритейл, М.Видео, Kion от МТС, Госуслуги. Angular не всегда на виду, но проектов много.

Александр: А иностранные проекты?

Олег: Из очевидного – Google Fonts. Также, насколько помню, что-то на Angular было у Booking. Есть много авиакомпаний и банков. Например, канадский банк Mint целиком работал на Angular. В целом это довольно популярный фреймворк в крупных системах.

Александр: Сколько могут зарабатывать Angular-разработчики?

Олег: Всё зависит от компании и уровня. Сейчас зарплаты фронтенд-разработчиков в целом выровнялись. Раньше Angular-разработчик мог рассчитывать на плюс 10-15%, потому что специалистов было меньше. Сейчас Angular-, React- и Vue-разработчики по рынку ближе друг к другу.

Если говорить грубо: junior – от 60 тысяч до 120-150 тысяч рублей, если это сильный junior+. Middle может спокойно получать 200-300 тысяч. Senior раньше мог рассчитывать на 450 тысяч, сейчас такая вилка уже скорее роскошь. Более реалистично – 350-400, иногда 420 тысяч рублей. Для фронтенда на текущем рынке это всё ещё неплохо.

Александр: При этом Angular-разработчиков всё равно меньше?

Олег: Да, дефицит есть. Это одна из проблем. Angular-разработчики – редкие специалисты, но кризис на рынке всё равно влияет на зарплаты.

Александр: Большое количество людей, которые пошли в IT после 2020-2022 годов, влияет на зарплаты?

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

Александр: Как сейчас искать работу разработчику?

Олег: Сейчас рынок во многом реферальный. Я бы в первую очередь пошёл в профильные сообщества. Например, я состою в сообществе «Айтихозяева»: там есть чат с рефералками, где можно описать, кто вы, что умеете, и попросить рекомендацию. Есть чат с разбором резюме: можно прийти, получить обратную связь, доработать CV, сопроводительное письмо, метрики.

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

На hh.ru ^[9] можно разместиться «для галочки», но найти там хорошую вакансию сейчас сложно.

Александр: Что случилось с hh.ru ^[9]?

Олег: Во-первых, слишком много откликов. На вакансии может быть тысяча кандидатов, и не факт, что до вашего резюме вообще дойдут. Во-вторых, появились ИИ-ассистенты и чат-боты, которые задают одни и те же вопросы: гибрид или удалёнка, зарплатная вилка и так далее. Люди пытаются пробиться к живому человеку, но это не всегда получается. Плюс требования к кандидатам часто выглядят странно: хотят 3-6 лет опыта ^[10], но не объясняют, где новичку взять эти годы. Поэтому я бы не делал hh.ru ^[9] основным каналом поиска.

Александр: Вы бы сейчас наймом не занимались?

Олег: Скорее нет. Каждый день появляются новые советы: нужно фото или не нужно, указывать возраст или нет, писать сопроводительное или нет, нужны ли достижения и метрики. Требования постоянно меняются. Проще поговорить с нанимающей стороной лично, чем бесконечно подгонять резюме под очередной идеальный шаблон.

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

Зарплаты Angular-разработчиков остаются сильными, но рынок стал осторожнее: дефицит специалистов не отменяет общего давления кризиса.

Нейросети, вайбкодинг и GDE: где ИИ помогает, а где создаёт долг

Александр: Используете ли вы искусственный интеллект ^[11] в работе?

Олег: Да, постоянно. На панели у меня есть почти все основные нейросети: ChatGPT, Claude, Perplexity, Grok, DeepSeek.

Александр: А GigaChat?

Олег: Его я почему-то не использовал.

Александр: Почему, на ваш взгляд, рекламируемыми российскими нейросетями пользуются меньше?

Олег: Насколько я видел в бенчмарках, они слабее топовых моделей. Когда вы работаете с кодом, вы хотите получить максимальный результат за минимальное усилие и за ту же стоимость подписки. Для программирования, на мой взгляд, пока сложно найти что-то лучше ChatGPT и Claude. Есть отдельные IDE и модели для кода, но по отзывам знакомых они слабее даже некоторых китайских решений.

Александр: Как нейросети справляются с кодом?

Олег: Всё зависит от запроса. Если написать «сделай красиво», модель что-то сделает, но не факт, что это будет работать. Главное правило – правильно описывать, что вы хотите получить. Ещё лучше хранить правила проекта в отдельных Markdown-файлах: как писать компоненты, как устроена архитектура, как писать стили, какие API использовать, какие не использовать. Это экономит контекст и создаёт базу знаний проекта. Вы описываете правила один раз, даёте их AI-агенту, и он начинает работать гораздо адекватнее.

Александр: Какие рекомендации вы дали бы по работе с ИИ и кодом?

Олег: Сначала стоит развести понятия. Вайбкодинг в исходном смысле – это когда человек почти не знает программирование и пытается сделать приложение через AI-агента. Например: «Сделай мне приложение для учёта калорий». Модель что-то выдаёт, но человек не понимает, как это устроено.

Когда опытный программист использует ИИ как помощника, это скорее AI-assisted development, а не вайбкодинг.

Если нужно быстро собрать MVP и проверить идею, нейросети – отличный инструмент. Но если проект должен расти, набирать пользователей и выходить в продакшен, полностью отдавать разработку на автопилот опасно. Программисты большую часть времени читают код, а не пишут. Если вы сгенерировали проект и не понимаете, где какие сущности, как всё связано и почему работает, дальше сопровождение станет проблемой.

Главный совет – работать точечно. Разбивать фичу на маленькие подзадачи, контролировать каждый этап, делать коммиты после понятных изменений. Нельзя просто сказать: «Сделай мне приложение» – и считать задачу закрытой.

Александр: Используете ли вы ИИ в жизни, кроме работы?

Олег: Да. Сейчас мне часто лень гуглить: на панели закладок уже почти нет поисковика, всё занято чатами. Я задаю бытовые вопросы, прошу что-то посчитать, сделать быстрый ресёрч. Perplexity удобен, когда нужно быстро разобраться в теме: задаёте тему, уходите пить кофе, а потом получаете суммаризацию десятков статей.

Один из любимых кейсов – работа с видео через Gemini. Я даю длинный ролик и прошу: «Сделай конспект по таймлайну и выдели тезисы». Часовое видео превращается в несколько страниц текста. Если какой-то тезис интересен, можно перейти к нужному таймкоду и посмотреть фрагмент. Так за ограниченное время удаётся проанализировать гораздо больше материалов.

Александр: Какие три нейросети вы используете чаще всего?

Олег: Gemini – точно. В том числе для кодинга, потому что у них есть отдельное направление, связанное с Angular и созданием приложений. На втором месте – Qwen: он стал хорошо себя показывать, у него есть отдельная модель для кодинга и CLI-инструмент. Третье место я бы разделил между GPT и Claude: обычно держу открытыми оба, сравниваю ответы и совмещаю результат.

Александр: Что такое GDE и как попасть в эту программу?

Олег: GDE – это Google Developer Experts, программа экспертов Google. Она даёт не только «значок», но прежде всего сильный нетворкинг. Вы попадаете в среду GDE, а таких людей в мире немного – около тысячи. В России до 2022 года их было примерно 17-20.

Чтобы попасть в программу, нужно вести медиадеятельность: блог, подкаст, канал; делать вклад в open source; заниматься образовательной деятельностью, менторством. Затем проходит техническое интервью по выбранной области. Если вас принимают, вы получаете статус GDE.

Важно, что статус нужно поддерживать: нельзя снять несколько видео, получить GDE и больше ничего не делать. Нужно продолжать вклад в сообщество. Для Angular это также прямой доступ к команде: можно общаться с разработчиками фреймворка, обсуждать API, вносить предложения.

Александр: У вас есть этот статус?

Олег: Нет. Сейчас, к сожалению, получить его из России фактически невозможно.

Александр: Хотели бы получить?

Олег: Да, хотелось бы. Это возможность войти в комьюнити сильных экспертов и напрямую общаться с командой, которая развивает фреймворк.

Александр: Почему сейчас невозможно?

Олег: Из-за политической ситуации и санкций. Даже GDE, которые уехали, часто осторожно взаимодействуют с русскоязычным сообществом. Были случаи, когда мы звали GDE-специалистов на конференцию, но они отказывались, опасаясь потерять статус.

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

Для быстрого MVP нейросети полезны; для большого продакшена автопилот без контроля превращается в технический долг.

Что такое Angular и почему его выбирают корпорации

Александр: Что такое Angular простыми словами? Чем он отличается от React и Vue?

Олег: Angular – это веб-фреймворк от Google для создания single-page applications, то есть одностраничных приложений. От других инструментов он отличается тем, что несёт в себе разные концепции и подходы сразу из коробки. Например, в Angular есть DI-паттерн – dependency injection, внедрение зависимостей. Есть классовые компоненты и встроенная архитектура. Если коротко: это веб-фреймворк для создания веб-приложений.

Александр: То есть это не библиотека?

Олег: Нет. Angular – именно фреймворк. В нём изначально заложена архитектура, а базовый функционал идёт из коробки. Для создания базового приложения вам в целом не нужно ничего, кроме Angular: есть формы, роутинг, HTTP-клиент, инструменты для управления состоянием.

Александр: Чем вы чаще всего пользуетесь при работе с Angular?

Олег: Если поставить Angular из коробки, там уже есть всё необходимое: формы, роутинг, HTTP-клиент, базовые возможности для state management. Поверх этого я люблю использовать Nx. Изначально Nx создавался для монорепозиториев, но сейчас это удобная надстройка над Angular CLI. Он расширяет возможности проекта: даёт генераторы сущностей, преднастроенные линтеры, prettier, тесты и другой tooling для больших проектов. Также часто подключают UI-kit: Angular Material, Taiga UI от T-Bank, PrimeNG и другие. Для сложного клиентского состояния можно взять внешний state manager, например решения на сигналах.

Александр: Почему стоит выбрать Angular для большого проекта, например банка?

Олег: Angular традиционно считают enterprise-решением. Сейчас это уже не совсем так, но для больших систем у него действительно есть сильные стороны.

Во-первых, масштабируемость: чтобы упереться в возможности Angular, нужно очень постараться. Во-вторых, архитектура: из коробки есть «рельсы», по которым движется команда, поэтому в проекте меньше хаоса. В-третьих, много встроенных инструментов, а значит меньше сторонних зависимостей и меньше головной боли ^[12] при обновлениях.

С тех пор как вышла вторая версия, Google аккуратно поддерживает обратную совместимость. Новые версии стараются не ломать существующий функционал. Есть миграции: при выходе новой версии или нового API проект часто можно обновить одной командой. Не всегда всё проходит идеально, особенно если в проекте сложная логика, но в целом обновления сильно автоматизированы.

Александр: Ещё большой плюс Angular – строгая типизация и переносимость опыта. Если команда ушла, новая команда может быстрее разобраться в коде. Можете развить эту мысль?

Олег: Да, это важная мысль. В Angular высокая переносимость опыта между проектами. Если вы приходите из одного Angular-проекта в другой, вы примерно понимаете, как всё устроено: компоненты, сервисы, DI, state management. Внешний state management чаще всего тоже один из известных вариантов, например NgRx.

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

Александр: Почему тогда Angular часто критикуют за строгость, если она помогает?

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

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

Раньше Angular действительно был отдельным «котлом» во фронтенде. Например, много асинхронной логики строилось вокруг RxJS, и можно было почти забыть про промисы. Сейчас ситуация меняется: в Angular пришёл Vite, используются общие индустриальные инструменты для сборки и тестирования, экосистема стала более открытой.

Александр: Часто Angular критикуют люди, которые опираются на старую информацию.

Олег: Это распространённая проблема. Когда спрашиваешь, почему человеку не нравится Angular, он часто приводит аргументы из 2020-2023 годов. Но фреймворк сильно изменился. Если критика строится на старых тезисах, возникает вопрос: смотрел ли человек, что происходило в Angular последние годы?

Александр: Что посоветовать новичку, который хочет заниматься Angular? Что нужно учить?

Олег: База – это HTML, CSS и JavaScript. TypeScript тоже нужен, но на старте не обязательно глубоко: достаточно понимать базовые типы, типизацию функций, простые конструкции. Сложные utility-типы и advanced-уровень можно отложить.

Сейчас большой плюс Angular – отличная документация. В ней есть туториалы на разные темы: создание приложения, сигналы, формы. Появились бесплатные материалы для входа во фреймворк. Комьюнити стало активнее.

Также Angular активно развивает AI-направление. В документации есть AI-инструменты, MCP-сервер, AI-тутор, который через CLI может обучать Angular, ходить по проекту и объяснять код. Есть AI-чатбот для работы с документацией. Материалов стало много, нужно только подобрать свой формат обучения.

Александр: Расскажите о цели вашего Telegram-канала.

Олег: Цель простая: make Angular great again. Я давно хотел зайти в YouTube: канал создан, заставка и джингл готовы, дома стоит свет, есть микрофоны. Но мешал перфекционизм и мысль: «Все и так всё знают, что я буду рассказывать?» Потом оказалось, что по Angular в русскоязычном сегменте активных авторов очень мало. Есть каналы-агрегаторы с новостями и статьями, но авторского мнения от практикующих специалистов немного. Я понял, что это свободная ниша, и начал хотя бы писать текстом, структурировать информацию и показывать, что Angular не так страшен, как его описывают.

Александр: Что посоветовать человеку, который попробовал Angular несколько лет назад, не смог разобраться и решил, что это «не его»?

Олег: Сейчас стоит попробовать заново. В документации есть отдельный блок туториалов. Они действительно ведут за руку: не нужно ничего устанавливать, внутри работает Playground и веб-контейнер, всё можно делать прямо на сайте.

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

Александр: Будет ли Angular популярен в России?

Олег: Он уже популярен, просто не всегда на виду. Когда рассказываешь, какие компании его используют, люди часто удивляются. Но шлейф React и выбор экосистемы будут ещё долго влиять на рынок. Плюс сейчас есть ИИ, и непонятно, как он изменит разработку. Но тенденции к росту Angular, на мой взгляд, есть.

Angular ценят не за хайп, а за предсказуемость: архитектура, миграции, DI, TypeScript и стабильный подход важны для больших команд.

Главная проблема репутации Angular – старые мифы: многие продолжают критиковать фреймворк таким, каким он был несколько лет назад.

Компоненты, CLI, RxJS, сигналы и SSR: что изменилось в современном Angular

Александр: Что такое компоненты в Angular и зачем они нужны?

Олег: Компонент – минимальный строительный блок приложения. Он состоит из шаблона, стилей и логики. Компоненты в Angular всё ещё классовые.

Александр: Что такое компонентная ориентированность?

Олег: Это подход, при котором мы работаем с веб-приложением как с набором компонентов. Страницу можно разделить на переиспользуемые сущности: кнопки, модальные окна, header, footer, список товаров и так далее. У компонента есть контракт: входящие и выходящие свойства. Внутри могут быть бизнес-логика, синхронизация и стилизация.

Александр: То есть структура Angular-проекта состоит из компонентов: шапка, блок, footer?

Олег: Да. Компонент – минимальный строительный блок Angular-приложения.

Александр: Это похоже на ООП?

Олег: Не совсем. Часто говорят: «В Angular классы, значит, это ООП». Но классы сами по себе не означают объектно-ориентированное программирование. В Angular класс – это удобная обёртка для описания логики компонента. Не обязательно активно использовать наследование и другие ООП-подходы. Более того, за наследование в Angular можно получить проблемы: оно может вести себя непредсказуемо при развитии проекта.

Александр: Из чего состоит структура стандартного Angular-проекта?

Олег: Обычно проект создаётся через Angular CLI – это удобная утилита для работы с проектом.

Александр: Что такое CLI и зачем он нужен?

Олег: CLI – Command Line Interface, интерфейс командной строки. В Angular это одна из killer-фич. Через CLI можно создавать проекты, генерировать компоненты, сервисы и другие сущности, запускать проект, собирать его, деплоить, запускать тесты и линтеры. Это сильно снижает ручной труд. После React мне было очень приятно увидеть инструмент, который позволяет не создавать папки и файлы вручную, а за несколько минут накидать минимальную структуру проекта. Если разработчик не любит терминал, можно использовать расширения с графическим интерфейсом: выбирать создание компонента мышкой, а файлы всё равно будут сгенерированы автоматически.

Александр: В чём разница между AngularJS и Angular?

Олег: Это два разных инструмента. AngularJS вышел в 2010 году, Angular 2 – в 2016-м. При переходе Google фактически потерял обратную совместимость. Вторая версия была несовместима с первой. Гайды по миграции существовали, но на больших приложениях обычно не работали: крупную кодовую базу трудно автоматически перенести. Это стало большой болью для сообщества. Многие поняли, что при переходе на новый Angular им придётся переписывать годы работы. В некоторых проектах даже встраивали второй Angular внутрь первого и роутировали части приложения на веб-сервере. Этот шаг сильно ударил по доверию к фреймворку, и часть сообщества ушла в React.

Александр: В чём разница между Angular 2 и современным Angular?

Олег: Путь был большой. Если сравнивать Angular 2 и Angular 21, это почти два разных инструмента, хотя базовые сущности – компоненты и сервисы – остались.

Крупные вехи: в Angular 9-10 появился новый компилятор шаблонов Ivy, который принёс типизацию шаблонов, нормальный tree-shaking и другие улучшения. В Angular 14 появились standalone-компоненты. В Angular 16 – сигналы. Затем активно развивался SSR. Сейчас многое вращается вокруг экосистемы сигналов. Большинство API заметно эволюционировало.

Александр: Angular считается тяжёлым. Это правда или миф?

Олег: Раньше вход действительно был сложнее. Было мало информации, а RxJS пронизывал фреймворк. Новичок приходил и сразу получал классы, Observables, роутинг, формы, DI. Всё наваливалось одновременно. В React можно было постепенно наслаивать инструменты, а в Angular приходилось сразу разбираться со многим.

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

Александр: Что такое RxJS?

Олег: RxJS – Reactive Extensions for JavaScript, библиотека для реактивного программирования. Она позволяет писать асинхронный код через потоки. Любой набор данных во времени можно превратить в поток и реагировать ^[13] на него.

Александр: Что такое поток?

Олег: Поток – это набор значений во времени. Например, данные приходят с сервера, пользователь кликает, двигает мышью, вводит текст. Два клика – это поток событий о действиях пользователя. RxJS позволяет управлять такими источниками данных, комбинировать их и обрабатывать сложные асинхронные сценарии.

Для сложной логики с конкурентными событиями, race conditions и большим количеством асинхронности RxJS остаётся одним из лучших инструментов. Но для новичков это была первая стена: потоки, подписки, отписки, операторы, утечки памяти. Мышление ^[14] в RxJS отличается от промисов, где создали промис, получили результат, обработали.

Александр: Какие частые ошибки совершают новички при изучении Angular?

Олег: Первая ошибка – перенос подходов из других фреймворков. Человек приходит из React и пытается писать Angular как React. Это видно почти сразу.

Вторая – неправильная декомпозиция логики. Новички часто размазывают код по компонентам, делают слишком сложные компоненты с большим количеством логики или, наоборот, выносят почти всё в сервисы, и становится непонятно, что должно оставаться в компоненте.

RxJS тоже важно понимать, но в Angular 21 можно написать среднее приложение с запросами и роутингом вообще без RxJS – на сигналах. Некоторые API ещё экспериментальные, поэтому не всё стоит сразу нести в продакшен, но для pet-проекта это хороший способ тренироваться.

Александр: Что такое сигналы?

Олег: Сигналы – новая важная веха Angular. До них система реактивности, построенная на RxJS, не подходила для многих UI-сценариев. В интерфейсе много синхронных состояний: checkbox включён или выключен, toggle переключён, форма открыта или закрыта. Для таких вещей поток не всегда нужен: это детерминированный набор состояний.

Сигнал – это реактивный примитив. В сигнал можно обернуть любое значение: число, строку, объект, массив. Если вывести сигнал в шаблон, Angular берёт на себя синхронизацию состояния и UI. У вас всегда актуальные данные в шаблоне, меньше риска рассинхронизации.

До сигналов Angular по умолчанию проходил по дереву компонентов и проверял, что изменилось. В сложном бизнес-приложении с сотнями компонентов это могло быть тяжело. Стратегия OnPush улучшала ситуацию: проверялась только нужная ветка. Сигналы принесли следующий шаг – локальную детекцию изменений. Если что-то поменялось в конкретном компоненте, проверяется именно он, а не всё дерево.

Александр: Что такое change detection?

Олег: Change detection – механизм, который определяет, когда что-то изменилось и что нужно перерисовать. Раньше Angular сам не умел делать это так точечно. За отслеживание отвечала Zone.js: она оборачивала браузерные API, ловила события и говорила Angular: «Событие завершено, иди проверь изменения».

Это было не самое оптимальное решение. Во-первых, сторонняя библиотека. Во-вторых, обёртки функций. В-третьих, всё происходило в runtime: при запуске приложения Zone.js патчила множество API, а это влияло на старт приложения и метрики производительности.

С приходом сигналов Angular научился сам под капотом понимать, где что поменялось. Появился batching: если в одном цикле несколько раз обновить сигнал, события объединятся, и UI получит последнее значение. Это более оптимизированный вариант рендеринга.

Александр: Что такое SSR в Angular?

Олег: SSR – server-side rendering, серверный рендеринг. Раньше с ним была большая проблема: не было нормальной гидрации. Сервер рендерил страницу, отправлял её клиенту, а клиент не понимал, что с ней делать, разрушал DOM и заново собирал всё приложение. Для пользователя это выглядело как моргание: сначала страница появилась, затем белый экран, затем страница снова появилась. Были двойные запросы и двойная работа.

С Angular 16 пришла гидрация: сервер отдаёт страницу, клиент её использует, не разрушая и не пересоздавая всё с нуля. Пользователь получает быстрый отклик.

Позже появилась частичная гидрация. Например, внизу страницы есть слайдер рекомендаций, до которого пользователь может вообще не долистать. Зачем загружать его JavaScript на старте? Можно сказать фреймворку: оживи этот компонент только когда пользователь наведёт курсор или кликнет. До этого он видит вёрстку, но компонент ещё не интерактивен.

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

Есть и Event Replay: если пользователь нажал кнопку до загрузки нужного JavaScript-бандла, Angular запоминает действие и воспроизводит его после гидрации. Это важная технология для UX.

Александр: Что такое AnalogJS?

Олег: Это метафреймворк для Angular, близкий по идее к Next.js для React и Nuxt для Vue. Он ориентирован на SSR. Если классический SSR загружает первую страницу, а дальше приложение работает на клиенте, то AnalogJS позволяет переносить больше логики на сервер: валидацию форм, загрузку данных и другие действия. Клиент получается более «тонким».

Александр: Что вам не нравится в Angular?

Олег: Первое – количество вакансий. Хотелось бы больше.

Второе – недавний шторм изменений. В Angular каждые полгода выходит major-версия, и когда вы обучаете фреймворку, приходится объяснять не только новые подходы, но и legacy: сигналы и RxJS, декораторы и новые API, старые и новые способы решения одной задачи. Новичок может не понимать, зачем учить два подхода. Но старые проекты существуют, и в реальной компании можно столкнуться не с самым новым Angular.

Третье – экосистема. Раньше по количеству и качеству библиотек Angular отставал от React, потому что React-сообщество больше. Сейчас ситуация выравнивается: за последние полтора года появилось много библиотек, включая аналоги headless-компонентов вроде shadcn-подхода – Spartan, ng-primitives, Zard UI. Экосистема заметно выросла.

Александр: А что вам нравится в Angular?

Олег: Мне нравится жёсткость подходов. Angular – opinionated framework: он диктует, как работать. Мне это подходит, потому что я не люблю бесконечно выбирать. Фреймворк говорит: у вас есть такие инструменты, работайте с ними.

Также мне нравятся внутренние подходы: как декларируются компоненты, как работает DI, как можно гибко настраивать зависимости на разных уровнях приложения. Нравится и то, как Google поддерживает фреймворк: обратная совместимость, схематики для обновлений, автоматизированные миграции.

Александр: Думали ли вы эмигрировать?

Олег: Честно – нет. Слишком многое держит здесь: семья, родные, имущество. Я не представляю, как оставить близких без поддержки. И в целом есть ощущение: где так же хорошо, как здесь?

Александр: Почему Angular всё-таки проигрывает React по популярности?

Олег: Это комбинация причин. Первая – недальновидная политика Google при переходе с AngularJS на Angular. Сообщество помнит этот разрыв и боится повторения: вдруг выйдет условный Angular 3.0, и снова придётся переписывать.

Вторая – обманчивая простота React на старте. За выходные действительно можно научиться делать приложение. Но многие забывают о следующем этапе: как выстроить архитектуру, управлять состоянием, разделить слои. React – не плохой инструмент, но он требует архитектурно зрелой команды или разработчика. Angular изначально даёт структуру.

Есть и фактор ИИ. Если попросить нейросеть сделать основу приложения, в большинстве случаев она выберет React. В датасетах React больше: Angular часто используется в enterprise, а такой код закрыт. Иногда модель даже на просьбу сделать Angular-компонент пытается импортировать что-то из React.

Александр: Какой главный миф об Angular вы бы развеяли?

Олег: Что Angular – это большой, неповоротливый и непроизводительный фреймворк только для enterprise-приложений. Это устаревший тезис. Сейчас на Angular можно делать не только большие корпоративные системы. Я делал на нём даже лендинги и небольшие страницы, потому что в компании уже был Angular-стек, инфраструктура и утилиты. С SSR такие проекты нормально работают.

Александр: Если бы вы одинаково хорошо знали React и Angular, что выбрали бы для развития, роста и заработка?

Олег: Я всё равно выбрал бы Angular. Возможно, это предвзято, но я не люблю постоянно выбирать. В React на этапе настройки проекта уже нужно принимать много решений: какие библиотеки взять, как организовать архитектуру. Я бы устал ещё до старта. Angular в этом смысле мне ближе.

Александр: Что такое директивы и зачем они нужны?

Олег: Директивы – это расширители для компонентов и DOM-узлов. Они добавляют функциональность к уже существующему элементу: добавить класс, условно что-то отрендерить, показать список, подсветить элемент, сделать кнопку «назад», добавить tooltip.

Есть структурные директивы: они меняют шаблон, например рендерят часть интерфейса по условию или выводят список. Есть кастомные директивы, которые можно писать самостоятельно. Директивы помогают выносить повторяемые действия и переиспользовать их. Компонент, кстати, – частный случай директивы, просто директива с шаблоном.

Александр: Как понять, что выносить в компонент, а что – в директиву?

Олег: Нужно смотреть, насколько поведение ^[15] переиспользуемо и на каких элементах оно нужно. Если есть хитрая логика кнопки «назад», которая может быть и кнопкой, и иконкой, и другим элементом, я бы вынес это в директиву. Тогда её можно повесить на любой DOM-узел или компонент.

В Angular также появился Composition API для директив. Он не делает директивы полностью динамическими в runtime, но позволяет задавать их на уровне метаданных компонента. Например, можно сказать, что на конкретном компоненте всегда должна быть определённая директива, и вся нужная логика будет капсулирована внутри.

Александр: Что такое шаблоны в Angular?

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

Сейчас синтаксис шаблонов сильно расширили. Можно делать много логики, хотя не всё стоит делать прямо в шаблоне. Важный плюс – типизация и безопасность: если в шаблоне что-то не так, Angular подсветит ошибку. Например, если в событие передаётся не то значение, это можно поймать ещё на этапе разработки.

Александр: Что такое модули в Angular?

Олег: Сейчас мы стараемся вспоминать о них как о страшном сне ^[16]. Модули активно использовались до появления standalone-подхода. Они должны были решать архитектурную задачу: объединять фичу, например расписание, список, детальную страницу, сервисы, публичный API.

Но на практике это часто давало overhead. Особенно проблемным был shared module: туда складывали общие компоненты и импортировали его везде. Сборщик плохо обрабатывал такие случаи, и вес приложения мог расти. Были сложности с dependency injection и инжекторами. Новичкам приходилось объяснять: есть компоненты, есть модули, есть модули для компонентов, есть модули внутри модулей. Это путало.

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

Александр: Вы не работаете с модулями?

Олег: Да, стараемся не работать и переходить на standalone.

Александр: Что такое pipes и как они помогают в шаблонах?

Олег: Pipe – встроенная фича Angular для форматирования данных в шаблоне. Например, есть дата, и её нужно показать как число, месяц и год. Или есть валюта, которую нужно вывести по правилам конкретной локали. Или нужно обрезать текст. Делать это в модели данных странно: там должны быть данные, а не представление. Pipes позволяют описать, как данные должны выглядеть в интерфейсе. Плюсы – переиспользуемость и оптимизация: pipe не пересчитывается лишний раз, если данные не меняются.

Современный Angular – это уже не только модули и RxJS: standalone, сигналы, улучшенный SSR и частичная гидрация сильно изменили опыт разработки.

Самые важные темы для понимания фреймворка: компоненты, DI, CLI, шаблоны, директивы, pipes, change detection и сигналы.

Личная сторона профессии: хобби, альтернативы и мечты

Александр: У вас есть хобби?

Олег: Если отделять хобби от работы, это не так просто: Telegram-канал уже стал чем-то похожим на хобби, хотя ведение отнимает много времени. Из обязательного – спортзал: работа сидячая, нужно двигаться. Ещё дома стоит гитара, которую я иногда беру в руки.

Александр: Если бы не программирование, чем бы вы могли заниматься?

Олег: Меня всегда тянуло в музыку. Я много слушаю музыку, занимался со школы, играю на гитаре. Возможно, пошёл бы туда – может быть, стал бы музыкантом на Арбате.

Александр: У вас есть мечта?

Олег: Практичная мечта на ближайшие годы – достроить дом. Ремонт и строительство оказались очень ресурсоёмким процессом: ментально, физически и финансово.

Если говорить о более большой мечте, меня не устраивает человеческий жизненный цикл: кажется, мы живём слишком мало. Хотелось бы увеличить продолжительность жизни и увидеть больше поколений. Обычно мы читаем о смене поколений в книгах, а было бы интересно наблюдать это лично, видеть успехи науки и пожить немного дольше.

Даже у технических специалистов мотивация ^[17] часто не только в коде: важны стабильность, семья, здоровье и личные проекты.

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

---

Глоссарий

AI-assisted development – разработка с помощью ИИ-ассистента. Разработчик сам понимает задачу и архитектуру, а нейросеть помогает с рутиной, подсказками, boilerplate-кодом и проверкой идей.

Angular – фреймворк от Google для создания веб-приложений. Даёт много возможностей из коробки: компоненты, роутинг, формы, HTTP-клиент, DI, CLI, SSR и другие инструменты.

AngularJS – первая версия Angular, вышедшая раньше современного Angular. Это отдельный инструмент, почти несовместимый с Angular 2+.

Angular CLI – командная утилита Angular. Позволяет создавать проект, генерировать компоненты и сервисы, запускать сборку, тесты, линтеры и другие задачи.

API – интерфейс, через который разные части программы общаются друг с другом. Например, фронтенд через API получает данные от сервера.

BFF – backend for frontend, серверный слой, который обслуживает конкретный фронтенд и подготавливает для него данные.

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

Change detection – механизм Angular, который определяет, что изменилось в состоянии приложения и какие части интерфейса нужно обновить.

CLI – command line interface, интерфейс командной строки. Это способ управлять инструментом через терминал.

Component / компонент – минимальный строительный блок Angular-приложения. Обычно включает шаблон, стили и логику.

Composition API для директив – возможность задавать директивы на уровне компонента, чтобы переиспользовать поведение ^[18] и капсулировать его внутри компонента.

Dependency Injection / DI – внедрение зависимостей. Механизм, при котором класс получает нужные сервисы и зависимости не вручную, а через систему фреймворка.

DOM – объектная модель документа. Упрощённо: дерево элементов HTML-страницы, с которым работает браузер.

E-commerce – интернет-торговля: сайты и приложения для продажи товаров или услуг.

Enterprise – крупные корпоративные системы, обычно с большой кодовой базой, долгим сроком жизни, сложными процессами и высокими требованиями к поддержке.

Event Replay – технология Angular, которая запоминает действия пользователя до полной загрузки интерактивного JavaScript и воспроизводит их после гидрации.

Frontend / фронтенд – клиентская часть приложения: интерфейс, с которым взаимодействует пользователь.

GDE / Google Developer Experts – программа экспертов Google. В неё попадают специалисты, которые развивают сообщество, делают образовательный контент, вносят вклад в open source и проходят технический отбор.

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

HoReCa – сфера гостиниц, ресторанов и кафе: hotel, restaurant, catering/cafe.

HTTP-клиент – инструмент для выполнения запросов к серверу: получить данные, отправить форму, обновить информацию.

Hydration / гидрация – процесс, при котором страница, отрендеренная на сервере, становится интерактивной на клиенте без полной пересборки DOM.

Ionic – фреймворк для создания мобильных и гибридных приложений на веб-технологиях.

Ivy – компилятор Angular, который улучшил сборку, типизацию шаблонов и tree-shaking.

JavaScript / JS – основной язык веб-разработки, который выполняется в браузере и используется во фронтенде.

Lazy loading – ленивая загрузка. Подход, при котором часть кода или интерфейса загружается только тогда, когда действительно нужна.

Major-версия – крупная версия продукта, где могут появляться важные изменения, новые API и потенциально несовместимые обновления.

Markdown / MD-файлы – простой текстовый формат для документации. Его часто используют, чтобы хранить правила проекта, инструкции и описания архитектуры.

MCP-сервер – сервер для подключения AI-инструментов к контексту проекта или документации. В контексте Angular может использоваться для обучения и помощи по коду.

Middle / Junior / Senior – уровни разработчиков: начинающий, уверенный самостоятельный специалист и опытный разработчик, который решает сложные задачи и влияет на архитектуру.

Монорепозиторий / monorepo – один репозиторий, в котором находятся несколько приложений, библиотек или пакетов одного большого проекта.

NgRx – популярная библиотека для управления состоянием в Angular-приложениях.

Nx – инструмент для работы с большими проектами и монорепозиториями. Расширяет Angular CLI, помогает генерировать код, настраивать тесты, линтеры и структуру.

Observable – объект из RxJS, который представляет поток значений во времени. Например, события кликов или ответы сервера.

OnPush – стратегия change detection в Angular, при которой фреймворк проверяет не всё дерево компонентов, а только нужные ветки при определённых условиях.

Opinionated framework – фреймворк с выраженным мнением о том, как надо строить приложение. Он даёт правила и ограничивает хаос.

Pipe / пайп – инструмент Angular для форматирования данных в шаблоне: даты, валюты, текста и других значений.

Playground – интерактивная среда в браузере, где можно писать и запускать код без локальной установки проекта.

Production / продакшен – реальная среда, где приложением пользуются настоящие пользователи.

Promise / промис – способ работать с асинхронным результатом в JavaScript: запрос отправлен сейчас, результат придёт позже.

Race condition – ситуация, когда результат зависит от порядка выполнения асинхронных операций. Если порядок меняется, появляются ошибки.

React – популярная библиотека для создания пользовательских интерфейсов. Даёт больше свободы выбора, но требует дисциплины в архитектуре.

RxJS – библиотека реактивного программирования для JavaScript. Позволяет работать с потоками событий и данных.

Server-side rendering / SSR – серверный рендеринг. Страница сначала собирается на сервере, а затем отправляется пользователю уже в виде готового HTML.

Shared module – старый распространённый подход в Angular, когда общие компоненты и зависимости складывали в один модуль и импортировали в разные части приложения.

Single-page application / SPA – одностраничное приложение. Пользователь работает в одном веб-приложении, а переходы между экранами происходят без полной перезагрузки страницы.

Standalone-компоненты – современный подход Angular, при котором компонент может использоваться без обязательного объявления в NgModule.

State management – управление состоянием приложения: где хранить данные интерфейса, как обновлять их и как синхронизировать разные части приложения.

Tree-shaking – удаление неиспользуемого кода из итоговой сборки, чтобы приложение было легче и быстрее загружалось.

TypeScript – надстройка над JavaScript с типами. Помогает заранее находить ошибки и делает код более предсказуемым.

UI-kit – набор готовых интерфейсных компонентов: кнопки, формы, модальные окна, таблицы, селекты и другие элементы.

Vibe coding / вайбкодинг – подход, при котором человек слабо понимает программирование и просит нейросеть «сделать приложение». Может быть полезен для MVP, но опасен для больших проектов.

Vite – современный инструмент сборки и разработки фронтенда, который ускоряет запуск и обновление проекта.

Vue – фронтенд-фреймворк, альтернативный Angular и React.

Zone.js – библиотека, которая раньше помогала Angular понимать, когда нужно запускать проверку изменений. С развитием сигналов её роль уменьшается.