Когда речь идет о веб-разработке, а именно — о разработке форм, можно встретить множество мнений о том, «на чем» лучше делать проект. Очень часто React и Angular Framework рассматриваются как альтернативы друг другу. При этом выбор фреймворка — критически важный этап, который определяет дальнейшую разработку и особенности развития технологического стека компании.
В этой статье я хочу рассмотреть плюсы и минусы каждого из подходов и предлагаю подискутировать о том, каким должен быть «идеальный» фреймворк для разработки веб-интерфейсов, который поможет повысить скорость разработки проектов, сохранить или увеличить качество кода при этом сэкономить финансы предприятия.
Привет, Хабр! Меня зовут Сергей Лапин, я — ведущий разработчик в Cloud X. И чтобы подойти к теме веб-разработки, начну немного издалека. Не смотря на широкий спектр моих увлечений в области ПО и аппаратного обеспечения, основной вектор направления моей профессиональной деятельности — это web разработка во всех возможных ее смыслах и ипостасях. И я с уверенностью могу сказать, перефразируя старую русскую пословицу: «Сколько веб не программируй, формы делать все равно придется».
Моя практика разработки форм начиналась в банках и финансовых организациях. Так уж исторически сложилось, что в подавляющем большинстве случаев в финансовом секторе клиентская часть сервисов разрабатывается с использованием популярного фреймворка Angular. Давайте разберемся почему же это так. Для этого предлагаю обратить внимание на сильные стороны Angular Framework.
Модульная архитектура, которая позволяет эффективно управлять кодовой базой и масштабировать приложение;
Двусторонняя привязка данных, позволяющая автоматически синхронизировать данные между моделью и представлением;
Реализация паттерна MVC, которая делает возможным отделение бизнес-логики приложений от UI слоя;
Широкий спектр API включающий в себя богатый набор функций, начиная от управления событиями CSS анимации, заканчивая обработкой и контролем HTTP траффика.
Но не смотря на все очевидные преимущества, у Angular есть и существенные недостатки:
Высокий порог входа. Для работы с Angular требуется глубокое изучение всех библиотек, входящих в фреймворк и высокой степени профессиональной подготовки, желательно уровня senior;
Увеличение стоимости разработки. Нехватка специалистов на рынке в совокупности с квалификационными требованиями повышают стоимость специалиста, также повышается нагрузка на HR персонал при поиске и закрытии позиций.
А что насчет React?
В прикладных сферах web-разработки сейчас безусловно доминирует библиотека React. Причины популярности этой библиотеки кроются в ее преимуществах:
Гибкость: Нет привязки к архитектуре, единственное требование – оформление UI элементов в виде отдельных компонентов;
Поддержка популярных UI систем. Ant Design, Material UI, Radix UI, Chakra UI и прочие;
Низкий порог входа. Для успешного старта достаточно уровня подготовки уровня продвинутого junior;
Сниженный уровень затрат на разработку. Благодаря невысокому порогу входа рынок насыщен специалистами, что при правильном подходе позволяет гибко управлять затратами.
С сильными сторонами определились, теперь перейдем к недостаткам (куда ж без них?):
Речь идет только про UI-слой. Библиотека решает задачи только организации графического интерфейса;
Односторонняя привязка данных. Изменения UI компонентов в React не отражается на модели;
Высокий риск издержек. Исходя из того, что React не реализует комплексных архитектурных решений, есть высокий риск ошибки с выбором исходной архитектуры приложения, что может повлечь за собой рост технического долга с неизбежными затратами на его устранение.
Как бы это странно не звучало, но реализация только UI слоя является одновременно как сильной, так слабой стороной библиотеки React. В случае с библиотекой React мы имеем полную свободу выбора, создавать ли свои собственные библиотеки UI компонентов (мы в компании пошли по этому пути) или использовать готовые компоненты с возможностью гибкой кастомизации.
Что там с кадрами?
С качественными показателями разобрались, но сегодня нельзя планировать проект без учета популярности фреймворка среди программистов и доступности специалистов. Поэтому давайте посмотрим на количественные характеристики.
React | Angular | |
Популярность (Github Stars, %) | 220 000 | 95 000 |
Количество открытых вакансий (по данным hh.ru) | 120 000 | 50 000 |
Зарплата (Россия/СНГ, Senior) | 350 000 | 380 000 |
Насыщенность рынка (% на 1000 соискателей) | 75 | 25 |
Данные из открытых источников, цифры актуальны на конец 2025 года.
Чтобы сравнить показатели, лучше всего нормализовать значения в пределах 100% и построить диаграмму. Что же, если прагматично рассматривать ситуацию, React выигрывает по всем показателям.
Проект мечты
А теперь давайте пофантазируем и попробуем собрать себе «проект мечты», который обеспечит максимальное качество результата с минимальными затратами. Что же возьму себе я?! От React, в первую очередь, я возьму гибкость, поддержку популярных UI систем, сниженный уровень затрат на разработку и низкий порог входа, а от Angular я бы хотел взять реализацию паттерна MVC, модульную архитектуру и конечно же широкий спектр API с двухсторонней привязкой данных.
Очень хорошо, когда наши желания совпадают с нашими возможностями, но это случается крайне редко. Но, как это часто бывает, в нашем вопросе можно вполне небольшими усилиями «дотянуть» реальность до нужного уровня.
Библиотека | Ожидания | Реальность (реализация) |
React | Гибкость | Выбрать готовый или разработать свою UI систему |
поддержку популярных UI систем | ||
Низкий порог входа | Оставить как есть | |
Сниженный уровень затрат на разработку | ||
Angular | Реализация паттерна MVC | Успешно заменяется на MVVM |
Широкий спектр API и двусторонняя привязка данных | ||
Модульная архитектура | Реализуется следованием правилам структурирования React компонентов, заложенных разработчиками в совокупности с общими правилами организации MobX сторов. |
Таблица желаний и возможностей
Как показывает таблица, все желания выполняются практически стандартными средствами, но вы же успели заметить, что одна ячейка осталась пустая. Дело в том, что за реактивность модели данных в Angular отвечает библиотека RxJS. Но так исторически сложилось, что в React проектах за реактивность отвечает библиотека MobX. И связка React+MobX хорошо себя зарекомендовала, и две эти библиотеки уже много лет идут рука об руку и почти стали синонимами.
Вот об этом недостающем куске паззла, без которого наша идеальная картина мира имеет мало шансов сложиться, и пойдет речь в следующей статье. Я расскажу о том, как была создана библиотека, которая средствами MobX реализует структуру хранения данных, методы манипуляций данными и точки отслеживания изменений. И все это для того, чтобы удачными архитектурными решениями, заложенными в конкурирующий фреймворке, можно воспользоваться в любом React-проекте без существенных доработок.
