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

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

Разделение ответственности и файловая структура

Главный сдвиг в голове при переходе с React — смена подхода, где компоненты несут всю нагрузку, на архитектуру, построенную на классах и ООП. В React привыкаешь думать компонентами: каждый кусок интерфейса представляет собой функцию, которая принимает пропсы и возвращает разметку. Вся логика и JSX-шаблон живут в одном файле, всё плоское и перед глазами. В Angular приходится перестраиваться и думать объектами и иерархиями.

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

Проект в Angular организуется по строгой структуре: сначала выделяются библиотеки (libs), внутри них — фичи (features), и только внутри фич живут компоненты. В React всё обычно проще и ограничивается папками с компонентами, которые используют друг друга.

От функций и хуков к ООП и наследованию

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

Архитектура строится вокруг базовых классов с общими методами и свойствами, от которых наследуются конкретные сущности. Если создать базовый класс Animal, дочерние классы Cat, Duck или Elephant получат его функциональность и добавят собственные уникальные атрибуты, не затрагивая родительский код. Когда нужно исправить или обновить базовую логику, нужно только внести изменения в одном месте, и они автоматически разойдутся по всей иерархии.

Асинхронные данные и реактивные потоки RxJS

Больше всего при переходе на Angular пугает RxJS. В React мы привыкли явно запрашивать данные и ждать ответа, а здесь приходится подписываться на поток и реагировать на каждое его изменение. Данные идут сами и непрерывно, а главная задача разработчика — правильно их направить: отфильтровать лишнее, объединить несколько потоков в один и вовремя отписаться, чтобы избежать утечек памяти.

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

На адаптацию уходит время: сначала приходишь в документацию за каждым оператором, а затем вырабатывается инстинкт. Начинаешь сразу видеть, где применить switchMap, а где добавить takeUntilDestroyed для автоматической очистки ресурсов. Это похоже на изучение иностранного языка — сначала переводишь каждое слово, а потом начинаешь думать на нем.

Встроенный tooling: формы, CLI и декораторы

Когда от стадии “отрицания” переходишь к “принятию” подхода, начинаешь замечать вещи, за которые Angular хочется любить. Первое, что бросается в глаза после React, — работа с формами. В React каждый раз приходится выбирать между React Hook Form, Formik и другими решениями, разбираясь в новой библиотеке на каждом проекте. В Angular работы с формами встроена в сам фреймворк: есть задокументированные Template-driven и Reactive Forms. Реактивные формы позволяют прописать объект FormGroup и всю валидацию прямо в TypeScript. В сложных конструкторах с вложенной логикой и зависимыми полями это полностью закрывает задачи без поиска сторонних пакетов на npm.

Следом привыкаешь к CLI, который буквально не даёт сделать что-то неправильно. Для нового компонента достаточно выполнить ng generate component auth-form — инструмент сам создаст файлы и зарегистрирует компонент в модуле. Точно так же одной командой генерируются сервисы и модули с маршрутизацией. Инструмент выполняет рутину по единственному правильному шаблону, который при необходимости можно настроить под проект.

Приятно удивляет и декоратор @HostBinding. Если в React для добавления CSS-класса по условию приходится писать логику в JSX или выносить её в отдельную функцию, то в Angular достаточно повесить одну строчку над свойством класса. Класс сам появляется или исчезает на хост-элементе в зависимости от значения, не создавая лишнего шума в шаблоне.

Диагностика циклических зависимостей

Самая противная проблема в Angular — циклические зависимости. Это ситуация, когда Сервис А зависит от Сервиса Б, а Сервис Б где-то дальше по цепочке ссылается на Сервис А. Фреймворк далеко не всегда ясно указывает на место ошибки: приложение может просто упасть при старте или вывести в консоль сбой, указывающий совсем не на ту причину.

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

Для выхода из этой ситуации есть инструмент Nx и команда nx dep-graph (или nx graph). Она визуализирует интерактивную карту проекта прямо в браузере, рисуя дерево связей между всеми библиотеками. Если в проекте появился закольцованный цикл, команда автоматически подсвечивает его красным цветом.

Критерии выбора стека под задачи

Angular точно не подходит на роль первого фреймворка для новичка. Это логичный следующий шаг, если хочется развиваться в сторону фуллстека или бэкенда: Java и Go тоже используют классы, объекты и dependency injection как стандартную практику. Год работы с Angular помогает легче понимать паттерны того же Spring Boot, потому что основные концепции уже отработаны на фронтенде.

Если задача — быстро собрать MVP, стартап, лендинг или небольшое приложение, объективно проще взять React. Там меньше формальностей и ниже порог входа на старте. Когда же предстоит развивать сложную долгоживущую систему с крупной командой, Angular оказывается практичнее: через год любой новый разработчик сразу поймёт структуру без дополнительных объяснений.

По этой причине Angular часто выбирают для разработки крупных распределённых платформ и корпоративных экосистем — например, в Centicore Group, где есть сложные стандарты архитектуры и строгая типизация, чтобы поддерживать порядок в масштабных проектах.

Итого

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

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

Для меня этот опыт стал крутым шагом вперед. Ты перестраиваешь мышление с коротких функций на нормальное ООП, начинаешь нативно понимать архитектурные паттерны и уже без страха смотришь в сторону того же бэкенда. Так что если представится шанс пощупать Angular на реальном проекте — не бойтесь, оно того стоит.

Если вы фронтенд-разработчик или только планируете им стать, эта публикация поможет вам сориентироваться в текущей ситуации:

• Узнаете, какие крупные изменения произошли в React, Vue и Angular за последние 5-10 лет.
• Поймёте, стоит ли учить новые фреймворки без виртуального DOM или лучше углубиться в проверенные решения.
• Разберётесь, почему компании продолжают требовать знание React, хотя Solid.js работает быстрее.

Тимлид и разработчики рассказали, как они видят будущее профессии. Объяснили, почему джуну недостаточно знать только JS, какие навыки помогут вам зарабатывать больше и оставаться востребованным специалистом.

ℹ️ После прочтения вы сможете принять взвешенное решение: продолжать углубляться в текущий стек, осваивать новые инструменты или развивать смежные навыки.

Как изменились React, Vue и Angular за последние 5-10 лет?

React

До 2019 года разработчики писали объёмные классы с методами жизненного цикла. Они управляли состоянием через setState и передавали данные через пропсы. Потом появились хуки — с тех пор логику помещают в функции, состоянием управляют через useState и useReducer, побочные эффекты контролируют через useEffect.

Серверные компоненты решили проблему первой загрузки. Тяжёлые части приложения обрабатывает сервер и отправляет клиенту уже готовыми. Конкурентный режим разбивает отрисовку на части и расставляет приоритеты для обновлений — интерфейс не виснет, когда нагрузка возрастает.

Vue

Composition API сделал организацию кода более гибкой. Логику теперь группируют по функциональности, а не по типам опций. Ещё реактивность переписали с нуля на прокси-объектах, что ускорило отслеживание изменений.

Компилятор научился оптимизировать шаблоны на этапе сборки. Телепорты решили проблему с модальными окнами и всплывающими подсказками — компоненты отрисовываются в нужном месте DOM-дерева независимо от родителя.

В какую сторону развивается Vue и есть ли ему современные альтернативы

Angular

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

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

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

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

Фронтенд-фреймворки кажутся избыточными — возвращаемся к ванильному JS?

Тот, кто попробовал фреймворки, никогда не вернется к чистому ванильному JS 🙂 Меняются и развиваются сами фреймворки, но тренда на отказ от них точно нет.

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

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

Фреймворки — это ещё и способ стандартизации разработки в командах.

Фреймворки никогда не будут избыточными. Один из первых вопросов на собеседовании — инструмент, с которым ты умеешь работать. Больший пласт знаний сегодня — это фреймворк. Остальное, чаще всего, бизнес-логика того или иного проекта.

Из-за критики традиционных фреймворков появился новый класс решений. Больше всего ругают VDOM и гидратацию, хотя они считались неотъемлемой частью современных SPA.

Стоит ли переходить на фреймворки без VDOM и гидратации?

Solid.js и Svelte уже несколько лет развивают концепцию тонкой реактивности. В 2021 году появился Qwik, который вообще отказался от гидратации.

SolidJS хорош для аналогов десктопных приложений в браузере — Figma, Miro. Здесь приложение загружается один раз, а потом работает долго и должно быть максимально отзывчивым. Qwik отлично подойдёт, если вы создаёте сайт, куда пользователь приходит за контентом, и важно показать ему этот контент мгновенно.

При этом массового перехода на новые фреймворки пока не происходит. Компании продолжают искать React и Vue разработчиков — проекты на Solid.js и Qwik остаются экспериментальными.

Сами по себе фреймворки мало значат для коммерческой разработки без сторонних библиотек вокруг них. Вот когда критическая масса разработчиков популярных библиотек мигрирует на Qwik, а вместе с ними и сообщество, что-то сдвигается.

Проблема новых фреймворков — это отсутствие экосистемы. React и Vue окружены тысячами готовых библиотек для любых задач. На Solid.js и Qwik большинство решений придётся писать самостоятельно.

Без поддержки сообщества пользователей ни один инструмент не сможет стать массовым. Даже если работаешь в заказной разработке и есть возможность расширить кругозор команды, сомнительно брать на тест инструмент, под который придётся писать до 30% базового функционала.

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

У новых фреймворков высокий порог входа: вас ждёт переобучение команды и сложности ручной оптимизации.

Технологии развиваются циклично. То, что сейчас кажется инновацией, переосмысливает старые подходы.

Во времена DDR/DDR2 было сложно выполнять клиентский рендеринг, а вот серверам ресурсов хватало. Разработчики как могли воплощали подход, который сейчас называется SSR, и возвращали на клиент готовую разметку для компонентов. И никакого тебе VDOM.

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

Как изменится роль фронтенд-разработчика в 2026 году?

В 2020 году джуниор находил работу, если знал HTML, CSS и основы JS. Сегодня работодатели требуют от новичков React или Vue, TypeScript, системы сборки — и это не конец списка. Ещё и вакансий на всех начинающих не хватает, компании сразу ищут мидлов.

Инструменты с искусственным интеллектом — Copilot, ChatGPT, Cursor — ускоряют работу. Они же повышают планку: если джун с помощью ИИ работает как мидл, то мидл должен демонстрировать более глубокие знания. Работодатели стали больше ценить тех, кто понимает принципы работы кода, а не просто копирует готовые решения.

Зная JavaScript и любой инструмент даже не из большой тройки, с использованием AI можно быстро погрузиться в другой нужный инструмент.

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

Какие навыки развивать разработчику, чтобы оставаться востребованным?

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

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

По мне так лучше быть фреймворк-агностиком, нежели фанатом одного, которого легко чем-то обидеть.

Архитектурное мышление отличает «сильного» разработчика:

• Как организовать код, чтобы его легко поддерживать?
• Как спроектировать API, чтобы оно не ломалось при изменениях?
• Как построить систему, которая выдержит рост нагрузки?

Те, кто решают эти вопросы, получают офферы с космическими зарплатами.

Софт-скиллы тоже влияют на карьерный рост:

• Объясните техническую проблему менеджеру простыми словами.
• Проводите код-ревью так, чтобы не обидеть коллегу, но улучшить код.
• Оценивайте сроки и управляйте ожиданиями.
• Аргументируйте выбор технологии.

Когда вы понимаете бизнес, вы становитесь партнёром. Почему мы делаем эту фичу? Как она повлияет на метрики? Какие есть альтернативы? Разработчик, который мыслит категориями бизнеса, становится незаменимым.

Рынок вынуждает постоянно учиться, потому что индустрия меняется каждый год. Кто застревает в зоне комфорта — отстаёт.

Как ChatGPT повлиял на ценность вашего труда? Успеваете подстраиваться под требования рынка, параллельно работать и пробовать новые технологии? Делитесь в комментариях.

Последний рубеж React и Vue

Согласны, что VDOM превратился в бюрократическую прослойку? Изменили состояние в одном месте — получите полный пересчёт дерева компонентов. Фреймворки заставляют загружать всё сразу, тащат багаж служебного кода. И пока этот код не загрузится, пользователь смотрит на белый экран.

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

Потом JS наконец подгружается и начинает гидратацию. По сути, он заново создаёт в памяти то же дерево компонентов, которое сервер уже отрендерил в HTML. Выполняется двойная работа. Кстати, в это время пользователь тыкает неработающие кнопки — дотерпит ли он до полной загрузки?

Системные проблемы не исправить очередным хуком или новой версией фреймворка, поэтому появление SolidJS и Qwik — было вопросом времени.

Поиск новых решений — здоровый признак развития фронтенда. В конце концов, и Vue был создан потому, что Эвану Ю не хватало облегченной альтернативы AngularJS. Большая тройка фреймворков решает огромный спектр задач, имеет колоссальную поддержку сообщества, но их нельзя назвать идеальным инструментом на все случаи жизни.

Обзор SolidJS

SolidJS во многом похож на React. Самое интересное — его подход к обновлению интерфейса:

• Отсутствие виртуального DOM — Solid напрямую обновляет только те DOM-узлы, которые действительно изменились.
• Компоненты как функции инициализации — каждый компонент вызывается только один раз для настройки реактивности.
• Сигналы вместо хуков — состояние управляется через createSignal(), который возвращает геттер/сеттер пару.

Например, когда срабатывает счётчик, Solid не перерисовывает весь компонент. Он точечно обновляет только текст внутри <p>, где используется count():

Преимущества SolidJS

👍 Производительность и размер бандла

Благодаря отсутствию виртуального DOM и мелкозернистым обновлениям, приложения работают быстрее аналогов на React.

👍 Простота освоения

Синтаксис SolidJS похож на React. Функциональные компоненты, JSX, концепции вроде Suspense и Error Boundaries — всё это есть в Solid. Изучение основ займёт 1-2 дня, если есть опыт с MobX/effector/RxJS.

👍 Стабильность

Фреймворк находится на стабильной версии 1.x. Это означает отсутствие кардинальных изменений API, в отличие, например, от ситуации со Svelte, где сосуществуют версии 4 и 5 с разными подходами.

👍 Совместимость с React

SolidJS совместим с экосистемой React. Можно переиспользовать дизайн-системы и компоненты в legacy-приложениях.

👍 Удобное управление состоянием

Функционал сигналов и сторов покрывают 90% потребностей в управлении состоянием без необходимости подключать внешние библиотеки.

Минусы SolidJS

👎 Ограниченная экосистема

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

👎 Кривая обучения

Несмотря на знакомый синтаксис, модель реактивности SolidJS отличается от React. Разработчики должны усвоить следующие принципы:

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

👎 Проблемы с инструментарием

Возникают сложности с настройкой компилятора в нестандартных окружениях — монорепозиториях, при запуске тестов или интеграции с другими инструментами. DevTools не дотягивает до аналога у React.

👎 SolidStart всё ещё развивается

SSR-решение SolidStart пока не достигло зрелости Next.js или Nuxt. Разработчики сообщают о проблемах с гидратацией и других сложностях при работе с серверным рендерингом.

Обзор Qwik

Qwik — это проект Мишко Хевери (создателя Angular). Идея фреймворка заключается в возможности возобновить работу приложения на клиенте без повторного выполнения кода, который уже был выполнен на сервере.

В Qwik радикально решили проблему гидратации — полностью отказались от неё. Время до интерактивности (TTI) падает в разы. Пользователь может кликать на кнопки сразу после загрузки HTML, без ожидания разогрева всего приложения.

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

Плюсы Qwik

👍 Мгновенная загрузка

Практически нулевой JavaScript при первоначальной загрузке, следовательно отличные показатели Core Web Vitals.

👍 Автоматическая оптимизация

Оптимизация на уровне компилятора, умная предзагрузка критических ресурсов. Не нужно думать о разделении кода — Qwik делает это автоматически.

👍 Знакомый синтаксис

👍 Спасибо за SEO

Быстрая загрузка улучшает ранжирование за счёт полноценного SSR из коробки.

Минусы Qwik

👎 Молодая экосистема

Ограниченное количество библиотек, мало готовых решений и компонентов. Небольшое сообщество разработчиков (если сравнивать с React/Vue).

👎 Кривая обучения

Придётся изучать новые концепции. Из-за ленивой загрузки усложняется отладка.

Qwik — это радикально новая ментальная модель. У фреймворка высокий порог входа: вас ждёт переобучение команды и сложности ручной оптимизации. Чтобы Qwik работал идеально, разработчик должен вручную указывать, что можно лениво загружать, а что нет.

👎 Сложность интеграции

Трудно интегрировать существующие React/Vue компоненты и ограниченная поддержка сторонних библиотек. Скорее всего, придётся с нуля переписывать код существующего проекта.

Экосистема и готовность к продакшену

Если сравнивать с React, то экосистема — самое слабое место обоих фреймворков.

SolidJS имеет SolidStart — метафреймворк с роутингом, SSR и серверными функциями. Документация качественная, сообщество активное. Большинство React-библиотек можно адаптировать без особых проблем, для популярных UI-китов есть готовые порты.

Qwik развивается в связке с Qwik City, который покрывает типовые задачи веб-разработки. Builder.io активно инвестирует в экосистему, регулярно выходят обновления и новые интеграции.

Риски есть, но они управляемые. Меньший размер сообщества означает меньше готовых решений и ответов на Stack Overflow. Если не боитесь изучать новое, то выигрыш в производительности перевесит неудобства.

Сравнение SolidJS и Qwik

SolidJS повышает производительность обновлений. Если данные меняются часто и непредсказуемо — графики, мониторинги, редакторы — Solid даст максимальную отзывчивость.

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

Медиа, блоги с жёсткими требованиями к TTFB/TTI/INP будут лучше работать на Qwik. Пользователи смогут читать и скроллить без задержки. Интерактив добавляется дозированно — это лучшая стартовая стоимость.

E-commerce, каталоги с SEO и карточками рекомендуется разрабатывать на Qwik. Особенно если на главной тяжёлые модули, а клиенты приходят с поисковиков. Вы выигрываете у конкурентов буквально на первом взаимодействии.

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

Solid хорош для аналогов десктопных приложений в браузере — Figma, Miro. Здесь приложение загружается один раз, а потом работает долго и должно быть максимально отзывчивым. Также Solid будет хорош там, где важна плавность анимаций.

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

Оба фреймворка умеют SSR/SSG и стриминг. Solid снижает стоимость обновлений, Qwik — стоимость старта. Для LCP/TTI/INP в контентных сценариях выигрывает Qwik. Для интенсивных интерактивных сценариев Solid удерживает FPS и снижает CPU.

Оба дружат с серверными платформами. SolidStart имеет адаптеры для Vercel/Netlify, Qwik City — тоже.

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

Немного выводов:

• Solidjs быстрее Qwik при рендеринге. Qwik быстрее Solidjs при загрузке страниц.
• У Solidjs документация лучше, чем у Qwik.
• С нуля код на Qwik писать проще и быстрее, чем на SolidJS.
• Typescript в SolidJS может быть головной болью, в Qwik об этом можно не беспокоиться.

Практические рекомендации по переходу на SolidJS и Qwik

1. Начните с аудита текущих проблем. Посмотрите метрики сайта: сколько времени занимает гидратация? Тормозят ли обновления интерфейса? Где именно проблема — на старте или в процессе работы?
2. Выберите изолированную часть проекта. Возьмите один виджет, одну страницу, один компонент и реализуйте его на новом фреймворке. Измерьте разницу в производительности и удобстве разработки.
3. Если проблема в медленной загрузке — попробуйте Qwik. Соберите прототип лендинга или каталога, включите SSG с resumability и протестируйте на медленном соединении.
4. Если проблема в тормозах интерфейса — попробуйте Solid. Перепишите самый страдальный компонент с частыми обновлениями, уберите мемоизации и посмотрите на результат.

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

Тенденция отказа от React/Vue

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

А вы что думаете? Готовы попробовать модные фреймворки SolidJS и Qwik в следующем проекте?

Недавно я столкнулся с одной проблемой на реальном проекте. У меня есть сайт: бэкенд написан на Spring, а фронтенд — на Angular. Я добавлял новую форму для отправки отзыва пользователя и, в спешке, забыл добавить валидацию на одно из полей формы на фронтенде.

Я хотел, чтобы поле «комментарий» было обязательным и имело длину от 1 до 100 символов. На бэкенде использовал аннотацию @Size(min = 1, max = 100) к обязательным полям, например для поля `comment` в моем DTO имеет такой вид:

Тест с пустой строкой {"comment": ""} был корректно отклонён. Однако, когда я отправил запрос без поля "comment" вообще ( {} ), валидация прошла успешно, и поле «comment» пришло как null. Это была серьёзная ошибка — поле, которое по логике было обязательным, могло быть пропущено. Т.е. могли потеряться важные для меня данные.

Почему так происходит?

Причина кроется в спецификации JSR-303 (Bean Validation). Документация (Javadoc) для аннотации @Size прямо указывает: «null elements are considered valid». Это означает, что если значение поля null, валидатор @Size считает его валидным и не выполняет проверку длины.

Это поведение подтверждается и в исходном коде валидатора. Метод, отвечающий за проверку строки, сначала проверяет значение на null, и если оно null, сразу возвращает true, не переходя к проверке размера. Это стандартное поведение для многих аннотаций валидации, таких как @Min, @Max, @Pattern и т.д. Они проверяют качество значения, но не его наличие.

Предлагаемое решение

Чтобы поле было действительно обязательным (не null и не пустое), необходимо использовать аннотации, которые проверяют наличие значения - это @NotNull, @NotEmpty, @NotBlank . Для строк лучшим выбором является комбинация:

Понимание разницы между этими аннотациями критически важно:

• @NotNull: Гарантирует, что значение поля не является null. Однако оно не проверяет пустые строки или строки из пробелов и будут считаться валидными.

• @NotEmpty: Гарантирует, что значение не null и не пустое (для строки длина > 0). Это означает, что "" будет отклонено, но строка из одних пробелов " " пройдёт валидацию, так как её длина больше 0.

• @NotBlank: Предназначена исключительно для String. Гарантирует, что строка не null, не пустая и после удаления пробелов с начала и конца (trim) имеет длину больше 0. Это означает, что null, "" и " " будут отклонены. Именно это поведение обычно ожидается от "обязательного текстового поля".

Красивое возвращение ошибок

Для того чтобы клиент (в моём случае, Angular-приложение) получал понятные сообщения об ошибках валидации, я настроил глобальный обработчик исключений с помощью @ControllerAdvice. Когда валидация не проходит, Spring выбрасывает MethodArgumentNotValidException. Далее, я его перехватываю и возвращаю структурированный ответ.

Angular-приложение может легко обработать этот JSON и отобразить пользователю понятное сообщение об ошибке.

Выводы

Аннотация @Size сама по себе не делает поле обязательным. Она проверяет только длину, если значение не null. Для обязательных строковых полей всегда используйте @NotBlank. Для других типов данных используйте @NotNull.

Не полагайтесь на @Size(min = 1) как на замену проверки на null или пустую строку. Эта ловушка, в которую я сам попался, может привести к консистентным данным в вашей системе и потенциальным уязвимостям, если бэкенд будет работать с неожиданными null значениями. Всегда явно указывайте, что поле является обязательным, с помощью соответствующих аннотаций.

Этот материал — не открытие века, а скорее напоминание как себе, так и коллегам. Даже опытные разработчики иногда могут упустить из виду такие нюансы. Я столкнулся с этой проблемой на проекте, и она стоила мне времени на отладку и тестирование.

Монолитная архитектура

Исходная схема:

• Backend: Spring Boot
• Frontend: Angular

Так как у меня уже был арендованный VDS, я зарегистрировал домен у одного известного провайдера, а хостил сайт уже на VDS сервере. Для простоты интегрировал Angular-сборку в Spring Boot как статику через frontend-maven-plugin. Всё собиралось в один JAR. Почему так? Ранее уже был такой опыт, и я решил пойти этим путем.

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

• Отсутствие SSR в Angular негативно влияло на SEO;
• Ошибка в Angular ломала Maven-сборку;
• Сложно поддерживать и масштабировать.

Переход на микросервисы

Было принято решение разделить фронтенд и бэкенд на отдельные сервисы и использовать микросервисный подход с SSR для Angular:

Новая структура:

• Backend: Spring Boot
• Frontend: Angular Universal (SSR)
• Инфраструктура: Docker Compose, Nginx, HTTPS

Docker, Nginx и запуск

Создана базовая структура docker-compose.yml:

И соответствующий Nginx:

После запуска проект открывался по IP, но появилось множество проблем:

• Дублирование API-префиксов: /api/api/endpoint → Решение: корректировка proxy_pass и URL в Angular
• Редиректы на POST: Spring добавлял лишние слеши → Решение: правильные аннотации и настройка Nginx
• 405 Method Not Allowed → Решение: использовать @PostMapping
• Docker-сети → Решение: задать общую сеть в docker-compose.yml

Безопасность: HTTPS, SSL, CORS

Чтобы сайт открывался по имени с панели провайдера для моего домена, значения DNS-сервера оставил без изменений (провайдер предоставляет их бесплатно), а для ресурсной записи @ и www указал ip адрес своего хостинга. Так как провайдер домена бесплатно предоставил SSL-сертификаты (Let's Encrypt), то как я их интегрировал:

Скачал с панели провайдера и перенес на хостинг такие файлы:

domain.crt — сертификат

domain.key — приватный ключ

ca_bundle.crt — цепочка доверия

Добавил в Nginx такую запись для HTTPS:

Но при обращении к сайту по https конечно же возникли ошибки. А именно: в логах Nginx были ошибки на SSL_CTX_use_PrivateKey_file. Оказалось формат был PKCS#7, а требовался PEM. Конвертировал через OpenSSL:

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

К тому же всегда следует проверять логи Nginx (error.log), там могут находится ответы на вопросы, почему сайт не работает.

На стороне Spring Boot были CORS-проблемы, решено так:

Атаки ботов и защита

После запуска сайта в логах Nginx стали появляться тысячи запросов от ботов, ищущих уязвимости WordPress, PHPMyAdmin и других популярных утилит, хотя мой сайт работает на Java/Angular. Пример лога:

45.155.205.213 - - [01/Jan/2023:04:12:11 +0000] "GET /wp-login.php HTTP/1.1" 404 153

Добавлен фильтр в nginx.conf:

Финальная конфигурация

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

docker-compose.yml

nginx.conf

Dockerfile backend

Dockerfile frontend

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

Vue создан более 10 лет назад. Для IT-продукта это большой срок, достаточный для завершения полного эволюционного цикла. Однако фреймворк продолжает развиваться и остается востребованным инструментом для создания интерфейсов, веб-приложений и инфраструктуры.

Узнаем, есть ли альтернативы у фреймворка Vue, каковы его особенности и преимущества и как использовать Vue.js с максимальной эффективностью.

Что такое Vue.js и зачем он нужен

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

Vue создан программистом из Google Эваном Ю в 2012 году — это был его пет-проект, то есть продукт для личного пользования, которым он занимался в свободное от основной работы время. Доступной для широкой публики технология стала только в 2015 году.

Эван Ю решил разработать этот фреймворк после того, как попытался поработать с Backbone.js и Angular — инструментами аналогичного назначения. Их функциональные возможности показались программисту недостаточными.

Когда коллега Эвана по ИТ-отрасли Тейлор Отвелл, создатель другого популярного продукта Laravel, заявил в соцсети, что изучает Vue, считая его более удобным, чем другие инструменты, популярность фреймворка кратно возросла. Другие разработчики стали активно использовать Vue.js для разработки пользовательских интерфейсов.

Интересный факт. Название фреймворка происходит от английского слова «view» в переводе на французский язык, что указывает на связь модели и отображения.

Это бесплатный опенсорс-проект (с открытым кодом), которым могут пользоваться все желающие. Улучшением и доработкой компонентов Vue занимаются программисты всего мира — у фреймворка очень обширное и доброжелательное сообщество. Несколько лет подряд Vue.js даже держался в топе на GitHub по количеству звезд. И в 2025 году популярность фреймворка все еще остается высокой.

Сферы применения Vue

Востребованность Vue.js объясняется его широкой сферой применения. Фреймворк используется для разработки:

• быстрых сайтов и веб-приложений;
• веб-ресурсов с повышенной нагрузкой — онлайн-магазинов, информационных порталов;
• лендингов — одностраничных сайтов с интерактивным содержанием;
• социальных сетей, сервисов CMS и других;
• адаптивных интерфейсов;
• личных кабинетов и страниц пользователей;
• интерфейсов для авторизации, интерактивных чатов, форм заявки и прочих функциональных блоков.

Vue пользуется популярностью не только в среде рядовых пользователей, но и в профессиональном сообществе. Продуктом пользуются такие компании, как Alibaba, EuroNews, Zoom, Ozon, Xiaomi и многие другие. Фреймворк считается одним из самых перспективных и адаптивных — новые версии выходят регулярно.

Многие компании используют Vue.js в своих внутренних проектах. Например, такие гиганты индустрии как Apple и Google в качестве основных инструментов разработки применяют другие фреймворки, но периодически привлекают и разработчиков на Vue.js. Компания Яндекс в основном пользуется React, но проект «Едадил» полностью сделан на Vue.

Основные преимущества Vue

Список плюсов у фреймворка довольно внушительный.

Реактивность

У разработчиков на Vue есть набор готовых шаблонов и возможность вносить изменения в реальном времени, не обновляя страницы. Такое свойство ускоряет разработку, повышает скорость загрузки и делает управление состоянием любой системы интуитивно понятным. Отслеживание и срабатывание происходит в процессе выполнения кода непосредственно в браузере, то есть сборка при такой схеме работы не требуется.

Декларативность

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

Низкий порог входа

Если вы знакомы с JavaScript, знаете основы CSS и HTML, вы без труда освоите Vue. Концепции фреймворка просты для понимания: программисты пишут код уже на первых неделях освоения.

Подробная документация

Эксперты называют доки Vue эталонными — работать с таким сопровождением одно удовольствие. По сути для обучения достаточно документации с подробным описанием основных библиотек и инструментов.

Обширное сообщество

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

Небольшой вес

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

Простое внедрение

Фреймворк используют для модульной интеграции — не обязательно создавать всё приложение, можно обойтись его ключевыми элементами. Например, разработать на фреймворке только интерфейс для интерактивного чата или личный кабинет. При этом элементы на Vue беспрепятственно взаимодействуют с частями, сделанными на других библиотеках.

Более того, ядро на Vue.js можно без труда внедрить в действующий проект, созданный на другом фреймворке. Сайт продолжит работу, а его модули можно переписывать постепенно без остановки проекта.

Минусы

Несмотря на многочисленные плюсы, Vue.js, как и любая другая технология, несовершенна. Опытные разработчики выделяют следующие недостатки.

Сложности в освоении при углубленном изучении

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

Производительность

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

Совместимость

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

Как развивается Vue

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

Эксперты выделяют ряд трендов в развитии фреймворка:

• Дальнейшая поддержка TypeScript. Этот язык программирования был создан с целью расширить возможности Java. Интеграция с Vue.js открывает новые перспективы для разработчиков.
• Оптимизация производительности. Ведутся работы по ускорению приложений на фреймворке и повышению эффективности, что крайне важно для пользовательского опыта.
• Работа над API. Предложены более гибкие варианты организации кода, что облегчает его сопровождение и повторное применение.
• Расширение экосистемы. Библиотека плагинов пополняется новыми продуктами и инструментами — участники сообщества постоянно работают над обогащением ресурсной базы разработчиков.
• Ориентация на инновации. Используются новейшие решения для работы над сложными проблемами.

Сейчас разработчики применяют версии Vue 3.0 и 3.5. Эти продукты по ряду параметров превосходят предыдущие итерации:

• Улучшенная реактивность. Фреймворки нового поколения внедряются в действующие проекты еще быстрее и потребляют меньше ресурсов.
• Упор на Composition API. Инновационный подход к организации компонентов фреймворка — отличный способ распространять логику приложения на другие продукты. Такая схема существенно упрощает повторное использование кода.
• Применение Vue CLI — полноценной системы для ускорения разработки. Обеспечивает бесперебойную работу компонентов сборки, отвечает за настройку приложения и быстрое прототипирование.
• Быстрота и мощность. Новые версии проще использовать для нативных приложений за счет модульности и оптимизации библиотек (автоматического удаления лишнего кода).
• Повышенная производительность рендеринга — преобразования трехмерных образов из программ в изображения, которые видит пользователь.
• Более эргономичный синтаксис. Экономия ресурсов и времени, потраченного на разработку.
• Внедрены новые алгоритмы для сравнения виртуального DOM с «настоящим», что ускоряет рабочие процессы.

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

Альтернативы и конкуренты: сравнение Vue с другими фреймворками

Ближайшие конкуренты Vue — это React, Angular, Svelte. Рассмотрим альтернативные фреймворки в сравнении с Vue.js.

Vue.js vs React

Библиотека с открытым кодом React — не менее популярный инструмент для разработки, чем Vue. Технически ее нельзя назвать полноценным фреймворком, при этом выбор решений для создания сайтов и веб-приложений довольно обширный.

Спор о том, что лучше, Vue или React, ведется уже несколько лет — стороны до сих пор не пришли к консенсусу. Оба инструмента обладают гибкой архитектурой, высокой производительностью, обширным функционалом. У каждого обширное сообщество пользователей, готовых привести сотни аргументов в защиту своего выбора.

Однако руководствоваться стоит исключительно объективными различиями:

• Изучение React занимает больше времени. Это факт, с которым согласны обе стороны. Если вы новичок в разработке, вам больше подойдет Vue — он проще по синтаксису, его концепция более понятна.
• Различный подход к реактивности. В React такие сайты создаются через виртуальный DOM — это усложняет изменение исходного хода. В Vue программист может работать с DOM напрямую, что ускоряет процесс изменений и упрощает работу программиста.
• Vue лучше взаимодействует со сложно-синхронизированной анимацией. Это фреймворк более удобен для дизайнеров, которые могут виртуально представить шаблон. В React это реализуется только через JSX. Но зато такой код короче, что в некоторых ситуациях тоже важно.
• Документация. У Vue она более подробная, со множеством ответов на сложные вопросы. Однако React компенсирует этот недостаток за счет более обширного сообщества, в котором можно найти ответ на любой вопрос.

В числе преимуществ React — наличие совместимой с библиотекой платформы React Native, которая позволяет создавать кроссплатформенный мобильный софт на Android и iOS. В экосистеме Vue специальных продуктов для разработки приложений для смартфонов нет.

Vue.js vs Angular

Разработка компании Google для одностраничных веб-приложений Angular работает на Java, TypeScript, Dart. Как и Vue.js, это фреймворк с открытым исходным кодом с репозиторием на GitHub.

Ключевые отличия Angular и Vue.js:

• С помощью Angular пишут код, который можно легко адаптировать под другие среды — например, для мобильных ОС. В Vue такие задачи реализовать гораздо сложнее.
• При этом Vue.js более гибок в применении. Его можно использовать как дополнительный инструмент для создания отдельных модулей. Angular потребуется внедрять целиком в весь проект.
• Как и в случае с React, обучение на Vue проще. Angular требует более глубоких познаний в программировании, сам процесс освоения и внедрения в практику занимает больше времени.
• Angular использует ajax — встроенную технологию взаимодействия с сервером без необходимости перезагружать страницу. Это упрощает передачу и получение данных. Реализован и механизм маршрутизации. В Vue эти функции реализуются только через сторонние библиотеки.
• Vue больше подходит для динамических веб-продуктов, ориентированных на UI/UX и пользовательские интерфейсы.

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

Vue.js vs Svelte

Фреймворк Svelte использует иной подход к разработке веб-интерфейсов, нежели React и Vue. У него другая организация кода и свой алгоритм реализации проектов.

Ключевые отличия Vue.js и Svelte:

• Реактивность в Svelte стала частью языка. С этим фреймворком обновлять контент при изменении состояния гораздо проще.
• Svelte превосходит другие фреймворки по скорости и легкости. Поскольку логика обновлений полностью перемещена в код, нет необходимости использовать Virtual DOM, что делает приложения более быстрыми.
• Сообщество Svelte не такое обширное, поэтому у малоопытных прогеров могут возникнуть проблемы с решением необычных задач.
• Документация у Vue.js тоже более подробная. У Svelte доки лаконичные и содержат только основную информацию о функционале.

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

Итоги

Главные плюсы Vue — простота, доступность и возможность точечного применения. Поскольку у фреймворка низкий порог входа, он часто становится инструментом первого проекта у начинающих разработчиков. Достаточно нескольких недель, чтобы начать использовать Vue.js.

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

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

Frontend фреймворки

React

Это самый популярный фреймворк для создания веб-приложений. React используется в лендингах, динамических веб-приложениях и даже мобильных приложениях (React Native).

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

React обращается к DOM только для обновления изменившихся компонентов. За счет этого повышается производительность приложения.

Пример простого React компонента:

Преимущества фреймворка:

• Облегчает повторное использование кода и поддержку приложений;
• Имеет множество дополнительных библиотек и инструментов;
• Виртуальный DOM снижает прямые манипуляции с DOM и повышает производительность приложения;
• Фреймворк пользуется популярностью в сообществе. Как результат  —  множество учебников, разборов документации и сторонних библиотек.

Недостатки фреймворка:

• Концепции JSX и управления состоянием могут быть сложны для новичков;
• Плохая кроссбраузерная поддержка;
• Требует дополнительных библиотек для маршрутизации и управления состоянием.

Vue.js

Vue используется для разработки простых лендингов и комплексных веб-приложений. Это гибкое решение, которое можно интегрировать в проекты постепенно.

Преимущество Vue в его простоте и низком пороге входа. При этом фреймворк сохраняет статус мощного инструмента для разработки сложных веб-приложений.

Vue автоматически отслеживает зависимости между блоками и обновляет DOM при их изменении, как React.

Компонентная архитектура Vue позволяет разбивать UI на переиспользуемые части. Разметка, стили и логика разделяются «оболочкой», а это облегчает поддержку и масштабирование приложения.

Пример простого компонента Vue:

Экосистема Vue включает множество библиотек и плагинов, расширяющих возможности фреймворка. Например, Vuex для управления состоянием, Vue Router, Nuxt.js и другие.

Преимущества фреймворка:

• Понятный синтаксис и подробная документация;
• Может использоваться как библиотека или цельный фреймворк в зависимости от проекта;
• Есть поддержка серверного рендера;
• Автоматически обновляет интерфейс при изменении данных;
• Имеет небольшой вес файлов.

Недостатки фреймворка:

• Меньше ресурсов и сторонних библиотек по сравнению с React и Angular;
• Неполная документация на русском языке.

Angular

С помощью Angular разрабатывают клиентские части веб-приложений. Этот фреймворк сложнее Vue и React.

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

По аналогии с Vue и React, фреймворк разбивает приложение на независимые, переиспользуемые блоки кода. Компоненты: шаблон; класс, описывающий поведение; стили.

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

Пример простого Angular-компонента:

Преимущества фреймворка:

• Богатый выбор инструментов, шаблонов, которые сокращают сроки реализации сложных приложений;
• Angular CLI расширяется за счет shematics, поэтому его легко доработать под конкретные задачи;
• Есть поддержка TypeScript: статическая типизация улучшает качество кода;
• Встроенная утилита для обновления проекта при переходе на новую версию Angular.

Недостатки фреймворка:

• Ангуляр сложнее, чем Вью и Реакт. Его изучение занимает больше времени, если это первый фреймворк в карьере разработчика.

Backend фреймворки

Django (Python)

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

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

Django следует архитектурному шаблону Model-View-Controller (MVC). Модели определяют структуру данных, представления обрабатывают логику и взаимодействие с моделями, а шаблоны отвечают за представление данных пользователю.

Сильная сторона Django — его ORM (Object-Relational Mapping). Интерфейс для работы с базой данных на Python используется для написания сырых SQL-запросов. Django поддерживает PostgreSQL, MySQL, SQLite, Oracle.

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

Пример модели Django:

В примере определяем модель Article с полями title, content и published_at. Метод __str__ возвращает строковое представление объекта:

Представление article_list получает объекты Article из базы данных и передает их в шаблон для отображения.

Преимущества фреймворка:

• Широкий набор инструментов: включает ORM, аутентификацию и админ-панель;
• Фреймворк задаёт структуру проекта — помогает разработчикам понимать, как и где добавлять новую функцию;
• Защищен от SQL-инъекции и подделки межсайтовых запросов;
• Подходит для высоконагруженных приложений.

Недостатки фреймворка:

• Django ORM уступает последней SQLAlchemy.

Ruby on Rails (Ruby)

Rails подходит для быстрого прототипирования и проектов, ориентированных на работу с базами данных. Его используют для SaaS-платформ, CRM-систем, CMS, маркетплейсов и многого другого.

Rails применяет архитектурный паттерн MVC (Model-View-Controller). Фреймворк хорош с точки зрения бизнес-логики и взаимодействует с базой данных с помощью ActiveRecord ORM.

Rails поставляется со встроенными инструментами и библиотеками. Например, ActiveRecord для работы с базами данных, ActiveStorage для управления файлами, ActionMailer для отправки email.

В сообществе Rails огромное количество гемов (библиотек), расширяющих функциональность фреймворка.

Пример модели Rails (с использованием ActiveRecord):

Пример контроллера Rails:

В примере определяем модель Article с валидациями и связями. Контроллер ArticlesController содержит экшены для списка статей, отображения отдельной статьи, создания новой статьи. Приватный метод article_params используется для фильтрации параметров.

Преимущества фреймворка:

• Продуманная структура, которая продвигает стандарты качества и лучшие практики веб-разработки;
• Active Record ORM упрощает взаимодействие с базой данных;
• Vue, Angular.js и React легко интегрируются с Ruby on Rails.

Недостатки фреймворка:

• Ruby on Rails js медленнее Django и Node.js.

Node.js с Express (JavaScript)

Express — фреймворк Node.js с набором функций для разработки веб-приложений и API. В нем реализован простой интерфейс для HTTP-запросов и маршрутизации.

Node.js + Express используется для сервисов, серверных приложений (например, чатов или игр).

Преимущество Node.js и Express состоит в возможности писать на JavaScript как клиентскую, так и серверную сторону. Можно вести разработку на одном языке и делиться кодом с фронтендом и бэкендом.

Пример простого приложения на Express:

Преимущества фреймворка:

• JavaScript на всем стеке — один язык для фронтенда и бэкенда;
• Имеет минимальные ограничения, можно строить архитектуру как удобно.

Недостатки фреймворка:

• Отсутствуют встроенные компоненты, требуются дополнительные настройки для безопасности и работы с базами данных;
• Управление обратными вызовами усложняет код и его поддержку.

Full-Stack фреймворки

Laravel (PHP)

Laravel — фреймворк для веб-разработки на PHP. Он использует архитектуру MVC: разделяет логику приложения и улучшает организацию кода.

Laravel выбирают для разработки CMS, SaaS-платформ, электронной коммерции и др. Встроенные библиотеки ускоряют работу.

В фреймворке реализована:

• Система миграций для управления структурой базы данных;
• Eloquent ORM для работы с данными;
• Система шаблонизации Blade;
• Встроенная поддержка аутентификации и авторизации;
• Очередь заданий и планировщик для выполнения асинхронных задач.

Пример определения маршрута в Laravel:

Пример контроллера Laravel:

Пример модели Eloquent:

В примерах выше определяем маршрут, который принимает id и возвращает строку с идентификатором. Контроллер UserController методом show получает пользователя из базы данных по id и передает его в представление user.profile. Модель User представляет таблицу пользователей в базе данных и определяет заполняемые атрибуты.

Преимущества фреймворка:

• Шаблонизатор Blade упрощает создание представлений;
• ORM Eloquent облегчает работу с базами данных;
• Есть автоматизация задач с помощью встроенных инструментов и командной строки.

Недостатки:

• Сложности с долгосрочной поддержкой версий.

Spring Boot (Java)

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

Фреймворк имеет встроенный контейнер сервлетов (Tomcat, Jetty), чтобы запускать приложение как автономный JAR-файл без развертывания на внешнем сервере.

Фреймворк также предлагает:

• Автоконфигурацию библиотек (JPA, JDBC);
• Встроенные метрики мониторинга;
• Поддержку внешней конфигурации;
• Интеграцию с базами данных.

Преимущества фреймворка:

• Есть встроенные серверы Tomcat, Jetty и Undertow;
• Облегчает управление зависимостями с помощью стартовых пакетов;
• Оснащен встроенным контейнером сервлетов;
• Автоматическая конфигурация экономит время на старте проекта.

Недостатки:

• Spring Boot создает множество неиспользуемых зависимостей и увеличивает размер файла развертывания.

Meteor (JavaScript)

Особенность Meteor в том, что он синхронизирует данные в реальном времени. Фреймворк автоматически обновляет пользовательский интерфейс при изменении данных на сервере. Это возможно благодаря протоколу DDP (Distributed Data Protocol) и реактивным источникам данных, таких как MongoDB.

На JS + Meteor можно писать код, который работает как на клиенте, так и на сервере. Фреймворк также предоставляет интегрированную систему сборки, которая автоматически объединяет ресурсы приложения.

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

Преимущества фреймворка:

• Архитектура и синтаксис с понятным кодом упрощают обучение новичков и повышают производительность команды;
• Есть мгновенная синхронизация данных между клиентом и сервером;
• Возможна интеграция базы данных MongoDB.

Недостатки фреймворка:

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

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

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

Чтотакое фреймворк и чем он отличается от библиотеки

Фреймворк — каркас программы, как готовое тесто для пиццы. Вам не нужно покупать яйца, муку и молоко, замешивать тесто, ждать несколько часов. Достаточно выбрать любимый соус и начинку — и отправить всё в духовку.

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

Часто фреймворки путают с библиотеками.

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

Работая с фреймворком, вы можете использовать много разных библиотек. Во фронтенде это jQuery, Lodash, Moment.js, D3.js и другие.

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

Популярные JS-фреймворки

Чтобы выбрать фреймворки для этой статьи, мы заглянули на HeadHunter и проанализировали, какие технологии наиболее востребованы у работодателей.

На первом месте с 3 371 результатом оказался React, на втором — Angular (1 361 вакансия), на третьем — Vue.js с 1 161 упоминанием. Поэтому о них сегодня и пойдёт речь.

React

React — фреймворк/библиотека JavaScript для разработки пользовательских интерфейсов. Это универсальное решение для создания небольших приложений.

Преимущества React:

• синтаксис JSX (JavaScript XML) делает код более читаемым и понятным
• виртуальный DOM повышает скорость отрисовки компонентов
• удобно создавать отдельные компоненты и переиспользовать их в других частях программы
• используется направленный поток данных (дочерние элементы не влияют на родительские), за счёт чего в коде реже возникают баги

Недостатки React:

• может показаться сложным для новичков, которые не знакомы с синтаксисом JSX
• для создания сложных приложений необходимо использовать дополнительные библиотеки, что может усложнить поддержку проекта
• для оптимальной работы с фреймворком надо знать такие инструменты, как Babel, Webpack, Redux

Как выглядит программа Hello, world! на React:

Angular

Angular — фреймворк от компании Google для работы с интерфейсами.

Его первая версия AngularJS увидела свет в 2010 году, но после выхода React стали хорошо видны её недостатки, поэтому в компании решили переработать фреймворк. Так, в 2016 году появился Angular, который сейчас применяют во многих крупных компаниях для создания сложных корпоративных приложений.

Преимущества Angular:

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

Недостатки Angular:

• сложность освоения TypeScript для новичков в программировании, из-за этого высокий порог входа во фреймворк
• не подходит для небольших приложений, так как весит 550-600 Кб
• предлагает только один способ построения архитектуры ПО

Как выглядит программа Hello, world! на Angular:

Vue.js

Vue.js — фреймворк для создания интерактивных пользовательских интерфейсов от разработчика Эвана Ю, более простая и лёгкая альтернатива другим фреймворкам и библиотекам.

Преимущества Vue.js:

• обладает интуитивно понятным синтаксисом, что делает его лёгким в освоении даже для новичков в веб-разработке
• компонентная архитектура способствует переиспользованию кода, модульности и упрощает разработку
• небольшой размер библиотеки (для архивированной версии — до 20 Кб), что обеспечивает быструю загрузку и меньшие требования к пропускной способности сети
• подробная и понятная документация, в том числе на русском языке

Недостатки Vue.js:

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

Как выглядит программа Hello, world! на Vue.js:

Какой фреймворк подойдёт вам

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

Так вы сможете понять, что же вам ближе: React, Angular или Vue.js. Но не спешите и помните про базу — прежде чем переходить на фреймворки, хорошо разберитесь в работе JavaScript. Эти знания и умение гуглить правильные вопросы помогут разобраться в любой технологии.

Вот, о чём идёт речь в видео:

1. Последняя версия Angular включает улучшения такие как управление потоком, отложенные представления и более быструю сборку.
2. На мероприятии для разработчиков Angular V17 был представлен новый сайт Angular.dev, который станет будущим домом для разработчиков Angular.
3. Angular.dev предлагает обновленную документацию, новую систему учебных пособий в браузере и площадку для кодирования, где можно изучать Angular, работая в браузере.
4. Angular обновил свою визуальную идентичность и логотип, отражающий текущие усилия и приоритеты в будущем.
5. Гидратация (hydration) в Angular, представленная в предварительной версии в v16, теперь стабильна и готова к использованию в производственных приложениях.
6. Введены важные обновления для гибридного рендеринга в Angular, позволяющие рендерить приложения на стороне клиента, сервера или предварительно рендерить их (SSG).
7. С версии v17 можно создавать приложения с гибридным рендерингом с помощью команды ng new и нового флага SSR.
8. Поддержка ESM для серверных сборок, ускорение сборок для серверных пакетов и улучшения для сервера разработки SSR.
9. Новый синтаксис управления потоком в шаблонах находится в предварительном просмотре и позволяет использовать встроенные конструкции if, for и switch.
10. Использование нового синтаксиса for может значительно увеличить производительность, в некоторых случаях до 90% быстрее.
11. Выпущены новые миграции для облегчения перехода на новый синтаксис.
12. Приложения, созданные с помощью CLI, по умолчанию будут независимыми, без необходимости использования флага.
13. ESBuild и Vite теперь включены по умолчанию, что обеспечивает улучшение производительности ‘из коробки’ для новых приложений.
14. Некоторые партнеры сообщили об улучшении времени сборки на 67%.
15. Сочетание SSR и SSG может привести к улучшению скорости сборки ngBuild на 87% и ускорению цикла редактирования-обновления для ngServe на 80%.
16. DevTools получили долгожданную функцию – возможность проверки графа внедрения зависимостей.
17. Теперь можно выполнять пользовательские преобразования ввода, а также доступны некоторые встроенные преобразования, такие как Boolean attribute и number attributes.
18. Добавлены новые свойства styles и styleUrls для принятия строк, так как разработчики редко используют более одного стилевого файла.
19. Для получения дополнительной информации можно обратиться к заметкам о выпуске и блогу Angular на blog.angular.io.
20. Команда Angular призывает разработчиков оценить новые функции и поделиться своими отзывами.

Ниже представлен транскрибированный перевод ролика на русский язык.

Подождите, что? Управление потоком, виды, отложенные представления, быстрые сборки. Я не могу поверить, я не могу поверить, что вы получаете все это и еще намного больше в последней версии Angular.

Новый сайт для Angular

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

Теперь, что если я вам скажу, что есть еще? Надеюсь, вы мне поверите, потому что, ну, Angular стремительно развивался за последние несколько лет, и мы решили отразить это современным визуальным стилем и логотипом. Теперь этот новый четкий логотип отражает наши текущие усилия и будущие приоритеты. Чтобы узнать больше, зайдите на angular.dev, но, слушайте, не трогайте стены.

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

Гибридный рендеринг Angular 17

Но подождите, вот что действительно потрясающе. Мы также внесли важные обновления в опыт гибридного рендеринга Angular. Гибридный рендеринг позволяет вам рендерить ваши приложения на стороне клиента, рендерить их на сервере или предварительно рендерить. Это также известно как SSG. Начиная с v17, вы можете создавать приложения с гибридным рендерингом с самого начала, используя ng new и новый флаг SSR.

Но мы не остановились на этом. Если вы забыли использовать флаг, не волнуйтесь, мы также обновили CLI, чтобы подсказать вам. Также добавлена поддержка ESM для серверных сборок. Сборки становятся быстрее для серверных пакетов, и мы не можем забыть, что мы даже проявили немного любви к dev-серверу для SSR.

Изменения в синтаксисе

Готовьтесь взять управление потоком в ваших шаблонах на новый уровень с новым синтаксисом управления потоком, который сейчас находится в режиме предварительной версии. Разработчики Angular теперь могут использовать встроенный синтаксис для if, for и switch. Хотя ничего не нужно импортировать, просто готово к использованию в ваших шаблонах. Теперь, что здесь еще потрясающе, это то, что использование нового синтаксиса for может значительно увеличить производительность, серьезно, до 90% быстрее в определенных случаях. Мы также выпустили новые миграции, чтобы облегчить ваш путь к использованию этого нового синтаксиса.

Запустите ng generate в angular forward slash core colon control dash flow. Подождите, что? Есть еще. Есть еще функции, о которых нужно рассказать.

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

Прочие улучшения

Не требуется флаг. ESBuild и Vite теперь включены по умолчанию, так что вы сразу получаете преимущества производительности для ваших новых приложений. Некоторые корпоративные партнеры сообщили о 67% улучшении времени сборки. Это действительно потрясающе, верно?

Я тоже так думаю. Но подождите, в сочетании с SSR и SSG, вы можете получить до 87% улучшения скорости в ngBuild и 80% более быстрый цикл редактирования и обновления для ngServe.

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

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

Мы добавили новое свойство styles и style URL для принятия строк, потому что, ну, разработчики редко используют более одной таблицы стилей. Но мы сохраняем оба формата на всякий случай, если вам понадобится.

Вот, о чём идёт речь в видео:

1. Даниэль обсуждает выбор между фреймворками Angular и Vue для разработки пользовательских интерфейсов.
2. Angular, созданный Google в 2010 году, предпочтителен для корпоративных проектов, имеет встроенные инструменты и библиотеки, а также поддерживает динамическую и двустороннюю привязку данных.
3. Angular использует TypeScript, обеспечивает высокую производительность благодаря иерархической инъекции зависимостей и другим функциям, поддерживается Google и легко интегрируется с сторонними приложениями.
4. Vue, созданный на основе вдохновения от Angular, отличается простотой и элегантностью, предлагает гибкость и прогрессивное развитие, позволяя легко добавлять пользовательские модули и компоненты.
5. Vue обеспечивает гибкость интеграции, простоту использования и функциональное расширение с помощью мощных API.
6. Angular и Vue имеют схожие черты: компонентно-ориентированную архитектуру, реактивную привязку данных и декларативный стиль программирования, а также большие сообщества разработчиков.
7. Основные различия между Angular и Vue включают архитектуру (Angular – MVVM, Vue – только ViewModel), реактивность, обработку ошибок, встроенные функции и производительность.
8. Выбор между Angular и Vue зависит от конкретных потребностей проекта и целей разработки.
9. Vue лучше подходит для динамических приложений, проектов, ориентированных на UI/UX, портфолио и одностраничных приложений.
10. Angular лучше подходит для кроссплатформенной и гибридной веб-разработки, крупных проектов и предприятий, требующих серверной отрисовки.
11. Angular и Vue обеспечивают высокооплачиваемые рабочие места, с зарплатами до $125,000 и $156,000 в год соответственно, а также возможности для фриланса.

Ниже представлен транскрибированный перевод видео на русский язык.

Вы наверняка слышали о Angular и Vue. Это два суперпопулярных фреймворка, которые разработчики используют для создания полноценных пользовательских интерфейсов.

Но вам, как разработчику, может прийтись принять непростое решение. Какую из этих двух технологий использовать в конкретном проекте? Меня зовут Даниэль, и сегодня мы поговорим о противостоянии Angular и Vue. Мы изучим их плюсы и минусы, сходства и различия. Мы постараемся понять, какой из этих фреймворков лучше подходит для различных типов проектов.

Преимущества Angular

Итак, приступим. Vue против Angular, но для чего они хороши? Ребята, прежде чем мы начнем сравнивать эти два фреймворка, давайте обсудим, для чего они были созданы. Как вы знаете, каждая технология создается с определенной целью.

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

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

TypeScript, надмножество JavaScript, улучшает качество кода с помощью надежной навигации, рефакторинга и функций автодополнения, что уменьшает ошибки в масштабных приложениях. Поддерживается Google. Еще одно преимущество заключается в том, что фреймворк поддерживается Google. Это включает в себя подробную документацию и возможности для будущего расширения фреймворка. Следующее – высокая производительность. Благодаря иерархической инъекции зависимостей, IV-рендерингу, AOT-компилятору, дифференциальной загрузке и поддержке Angular Universal, производительность фреймворка выдающаяся.

Обновленное руководство. Angular CLI предлагает своевременные рекомендации по зависимостям, загрузчикам и плагинам. Благодаря этому разработчики остаются в курсе последних рекомендаций. Бесшовные интеграции. Angular позволяет легко интегрировать сторонние приложения. Это дает разработчикам гибкость и множество инструментов для упрощенной разработки. Наконец, возможность настройки. Разработчики могут интегрировать элементы и модули из других фреймворков, адаптируя их под свои потребности. Дело в том, что элементы HTML Angular могут быть легко повторно использованы и управляемы путем обертывания их в качестве элементов DOM.

Преимущества Vue

Итак, как вы видите, ребята, есть много преимуществ у Angular. Но теперь давайте посмотрим на Vue. Vue, также называемый Vue.js, это все о чистом и элегантном дизайне. Представьте себе фреймворк, который объединяет мощные веб-инструменты с простотой. Вот что такое Vue.

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

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

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

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

Эти функциональные возможности позволяют вам создавать гибкую и обширную логику компонентов. Так что, ребята, судя по всему, Vue не уступает Angular.

Сходства между Angular и Vue

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

И взамен я прошу просто лайкнуть это видео и подписаться на мой канал, если вам нравится контент, который я делаю. Вот и все. Люди, помните, что создатель Vue использовал Angular в качестве своего вдохновения. Это означает, что у этих двух фреймворков JavaScript много общего.

Итак, давайте поговорим о самых больших сходствах между ними. Архитектура на основе компонентов.

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

Различия между Angular и Vue

Хорошо, друзья. Vue.js и Angular – это оба инструмента для создания фронтенда приложений с использованием JavaScript. Однако во многих аспектах они отличаются. Эти области, например, включают основную архитектуру, производительность, реактивность и другие.

Но давайте поговорим об этом более подробно.

Архитектура. Angular похож на полноценного архитектора, модель MVVM. Отлично подходит для создания детальных и сложных приложений. Кроме того, он поддерживает все виды серверных языков. Это делает Angular универсальным. Vue похож на декоратор фронтенда, только модель Vue.

Он отлично улучшает внешний вид, но не является универсальным инструментом для всего процесса создания. Проще говоря, Angular – это все в одном. Vue – только для фронтенда. Реактивность. Angular полностью основан на JavaScript. Он отлично подходит для приложений в реальном времени. Vue также использует HTML и CSS и идеально подходит для создания одностраничных приложений.

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

Он идеально подходит для крупных проектов. Vue более легковесен и отлично подходит для одностраничных проектов. Производительность. Когда речь идет о скорости, Vue намного быстрее.

Почему? Дело в том, что Vue остается легким с акцентом на слое Vue. Vue также получает ускорение от виртуального DOM, обеспечивая дополнительную скорость на различных платформах. Angular с его многочисленными встроенными функциями немного тяжелее и требует больше времени на выполнение задач.

Хорошо, ребята, и теперь мы подходим к главному вопросу.

Какой фреймворк следует выбрать для вашего проекта? Vue или Angular?

Итак, принимая во внимание все вышесказанное, что лучше, Vue или Angular?

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

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

Конечно, есть еще один важный вопрос.

Поможет ли изучение этих технологий получить высокооплачиваемую работу?

Если вы планируете стать разработчиком на Angular или Vue, вам не о чем беспокоиться. Согласно недавнему опросу Stack Overflow, Angular входит в топ-5 самых популярных веб-фреймворков.

И Vue не сильно отстает. Это означает, что спрос на разработчиков Angular и Vue остается высоким. По данным Glassdoor, разработчики на Angular в Соединенных Штатах могут зарабатывать до $125,000 в год. В то же время разработчики на Vue могут зарабатывать до $156,000 в год. Фрилансеры на Angular зарабатывают от $16 до $30 в час. И фрилансеры на Vue зарабатывают около $19-35 в час.

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

https://www.youtube.com/@Daniel-Dan./videos

Предыстория

Проект начался в ИТ-отделе одного крупного риэлтерского агентства. На момент моего трудоустройства там уже существовала CRM-система. Она позволяла вести внутренний учет сотрудников, документооборот, базы сделок и клиентов и самое важное — вести базу объектов и автоматически выгружать их в рекламу на различные площадки. Система имела устаревший интерфейс на ExtJS, а бэкенд строился на связке PHP (Yii и значительная часть самописного legacy-кода), MySQL. В целом, проект устраивал руководство в техническом плане (за исключением интерфейса), но была серьезная проблема для бизнеса — многие объекты недвижимости не выходили в рекламу из-за ошибок программы. По этой причине компания теряла клиентов, а как следствие, прибыль.

Руководство поставило программистам четкие задачи:

• добиться качественного роста выхода рекламы объектов;
• получать обратную связь по ним от рекламных площадок и предоставлять ее агентам для исправления.

После исследования отчетов о выгрузках на рекламные площадки оказалось, что ситуация на самом деле плачевна — в рекламу выходило всего-лишь 20% всех объектов! Такие показатели возникли на фоне того, что разные рекламодатели предъявляли разные требования к полям и их структуре, содержимому и взаимосвязям.

Около года я работал над этой системой, и за это время ситуация кардинально изменилась — не выходило в рекламу уже всего лишь около 15% объектов, зачастую из-за невнимательности самих агентов. У компании увеличилось число закрываемых сделок, появились свободные средства для инвестиций в технологичность, и отсюда уже начинается история новой CRM. Набравшись экспертности в сфере риэлтинга и хорошо зарекомендовав себя, как разработчик, мне поручают заняться созданием новой CRM-системы.

Начало работы

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

Под наши задачи я выбрал архитектуру SPA (одностраничное приложение). То есть фронтенд подгружался при первом заходе, а дальше просто подгружал данные и позволял агенту с ними работать без перезагрузки страницы. Бэкенд же отвечал непосредственно за авторизацию, получение, изменение и выдачу данных, ничего не зная о шаблонах и представлении данных для пользователя. Такое разделение удобно тем, что при необходимости можно просто заменить любой из модулей (или же использовать уже готовый backend/API, например, для мобильного приложения), каждый модуль может писаться раздельно разными разработчиками и при этом они никак не будут друг другу мешать. Кроме того, JS-фреймворки (вроде AngularJS, React, VueJS) позволяют на порядок проще сделать фронтенд, чем в известных мне MVC-фреймворках на PHP.

Был выбран следующий стек:

• frontend на AngularJS;
• backend на легковесном PHP-фреймворке FlightPHP;
• отдельно был создан микросервис на Python, отслеживающий изменения в объектах и создающий файлы для автоматической выгрузки в API рекламных порталов;
• MariaDB.

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

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

Хранилища

Из-за некоторых бизнес-ограничений мы использовали только собственные серверы для хранения данных и развертки системы (из-за ограничений бизнес-стороны мы не могли использовать облачные файловые хранилища для загружаемых документов и фотографий).

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

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

Первая таблица с перечислением всех возможных прав (например, создавать/читать/обновлять/удалять объекты определенного типа, доступ к разделам и т.д., но позже там могли появляться и специфические права, которые вписываясь в архитектуру, не становились костылями). Вторая таблица была набором строк, в которых связывался идентификатор пользователя, группы (отделы) или роли (администратор, начальник отдела и т.д.), идентификатор права и к кому это право применяется (ко всему, к своему, или даже по идентификатору и типу). Таким образом, можно настроить любые права: понадобилось внутри отдела в обход начальника назначить человека, который может утверждать объекты для выхода в рекламу? Пожалуйста. Может быть какой-то из отделов хочет новую фичу? Без проблем. Еще в трех таблицах перечислялись те самые пользователи, роли и отделы — тут все стандартно. Также мы хранили фотографии и документы по сделкам. Файлы загружались на отдельный сервер, который просто подключался через символическую ссылку в директории проекта.

Интерфейс

AngularJS из коробки или с минимальными доработками предоставлял почти все необходимое: быстро появилась красивая архитектура, был прописан роутинг, создана авторизация через JWT-токены и поддержка прав пользователя, о которых рассказывалось выше. Сам UI создавали на основе Angular Material, что колоссально сэкономило время — был создан шаблон, куда постепенно включались все новые и новые разделы. Различные модули по возможности переиспользовали уже готовые представления.

Отдельное внимание уделю формам. Так как одна из основных задач — это дать агенту инструмент, при помощи которого он единожды опишет объект по всем параметрам и будет уверен, что он будет рекламироваться, то большое внимание было уделено именно этому, и снова AngularJS приятно удивил, буквально одним условием в атрибуте тэга проводилась валидация не только этого поля, но и других, выводились подсказки и ошибки, скрывались лишние опции в селектах, отображались и скрывались поля, которые актуальны именно для описываемого объекта — и все это в одной форме, разделенной для удобства на 3 экрана в слайдере. Забегая вперед, скажу, что такой подход полностью хоть и потребовал изрядно попотеть над документацией API рекламных площадок, совмещая различные описания полей, все же полностью себя окупил — после запуска новой CRM в продакшн были единичные случаи ошибок выгрузки, потому что агент уже на стадии заполнения вынужден был оформить все правильно. Немногочисленные ошибки касались в основном ситуаций, которые невозможно отловить программным путем: например, на фотографиях указывались контакты (что запрещено большинством площадок), в описании был какой-то фрагмент, приводящий к блокировке.

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

Backend

На фреймворке FlightPHP реализовали REST API с около сотни методов, осуществляющих CRUD-операции по всем сущностям, а также генерацию отчетов, PDF файлов с корпоративным оформлением т.д. Flight конечно не сравнится с Yii или Symfony в плане построения сложных систем. Простейший шаблонизатор и валидатор запросов, роутинг, работа с входящими данными, кэширование, вывод ошибок, триггеры позволили полностью покрыть задачи проекта. Кроме самого API к бэкенду можно отнести и микросервис по выгрузке в рекламу, задача которого в том, чтобы сформировать корректные XML-файлы, транслируя модель наших данных на модель данных конкретной площадки, а затем парсящий ответные отчеты от площадок и заносящий информацию об ошибках в систему.

Выводы

Если вам доведется создавать CRM, то постарайтесь на стадии проектирования пообщаться со всеми интересантами разрабатываемого продукта, выявить проблемы и пожелания. Изучите возможные инструменты, взвесьте их плюсы и минусы, оцените насколько они подойдут именно под ваши задачи. Постарайтесь предугадать развитие событий, что может понадобиться в будущем. Грамотное начало проекта окупится в дальнейшем, когда не придется переписывать компонент за компонентом, хаотично добавлять “временные” таблицы, новые столбцы и постоянно заниматься правками ошибок.

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

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

Вот примеры, которые браузер будет интерпретировать как скрипты с одинаковым origin’ом. Если на открытой вкладке присутствует 3 скрипта, origin’ы которых отличаются подобным образом, то браузер будет воспринимать их как скрипты с одним origin’ом:

А такие origin’ы будут считаться разными:

https://melicious-website/home

Важная особенность SOP: скрипт с одним origin’ом может посылать запросы на другой origin. Однако не сможет прочитать ответ на него. Чтение ответа будет заблокировано на уровне браузера. Если требуется заблокировать в том числе отправку запросов (скажем, вы не хотите, чтобы скрипты, загруженные на вашем сайте с других origin’ов, могли делать запрос на origin сайта), это тоже возможно реализовать посредством указания Content Security Policy. Но дефолтная политика (SOP) работает именно так.

XSS / JS-Injections

Наиболее часто встречающейся атакой является Cross-Site Scripting («Межсайтовый скриптинг»), или более удачное, на мой взгляд, название — JS-инъекции (по аналогии с SQL-инъекциями).  Если в html-документ вставить строку, в которой будут использоваться элементы, похожие на html-теги, то браузер будет интерпретировать их как валидный html-код и исполнять его. Например, можно прописать с пустым src и добавить onerror=“alert(‘hacked’)” (так как src пустой, то браузер сразу перейдет к вызову onerror), внутри которого выполнить любой JS-код (имея доступ к localStorage и так далее).  Также можно поместить вредоносный скрипт внутрь запроса query params в следующем виде:

Предотвращение JS-инъекций

В современных фреймворках (вроде Angular/React) изначально действует санитизация, которую в случае необходимости (если вы хотите запустить inline-скрипт из строки и уверены, что там не содержится ничего вредоносного) можно отключить. В React’е это делается посредством атрибута, подчеркивающего опасность вставки inline-скриптов: 

В Angular’е можно за’inject’ить санитайзер и выбрать тот уровень санитизации, который подходит под ситуацию. Например, можно разрешить чтение стилей, но при этом экранировать любые скрипты.

Выглядит это так:

Помимо санитизации существует Content Security Policy (CSP) Header. Через него можно явно задать, скрипты с каким origin’ом могут исполняться браузером на текущей странице. По дефолту Content Security Policy содержит значение *. То есть браузеру разрешено запускать скрипты с любым origin’ом, включая inline-скрипты без origin’а. Такие настройки считаются очень небезопасными, и рекомендуется всегда явно указывать, скрипты с каким origin’ом можно запустить на сайте.  Явное указание ограниченного набора origin’ов заодно предотвращает исполнение inline-скриптов. Чтобы разрешить их исполнение, требуется явно это прописывать.

Пример того, как может выглядеть CSP Header:

Такие настройки означают, что изображения могут подгружаться с любого источника (*), media только с двух источников (media1.com & media2.com). А скриптам позволено запускаться, если они имеют только один origin (userscripts.example.com). default-src ‘self’  позволяет запускать скрипты с текущего origin’а, но не его поддоменов.

Посредством CSP-заголовка можно очень тонко настраивать исполнение скриптов на сайте.

content-security-policy Header и access-control-allow-origin немного похожи. CSP позволяет обходить SOP, а access-control-allow-origin позволяет получать разрешение на CORS. То есть отвечать (response) на запросы скриптов с другим origin’ом.

В начале статьи я упоминал, что SOP позволяет скриптам с одним origin’ом делать запросы на другой origin, однако SOP заблокирует ответ. Посредством access-control-allow-origin можно получить доступ к этому ответу, если на сервере явно прописан origin, который имеет право получать ответы.

Если кратко и утрированно, то SCP — это про SOP и frontend-часть системы. А access-control-allow-otigin — про CORS и backend-часть.

CSRF (XSRF)

Второй по распространённости тип уязвимости — это Cross-Site Request Forgery («Межсетевая подделка запроса»). Этот вектор атаки использует склонность браузера неявно добавлять куки к любому запросу. Например, вы авторизовались на сайте, где используются куки, и в какой-то момент некий скрипт делает запрос на origin этого банка — то есть открыли почтовый клиент и перешли по вредоносной ссылке. Браузер автоматически добавит куки к запросу, даже если сам запрос происходит с другой вкладки.

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

Для предотвращения этой атаки в первую очередь рекомендуется использовать явные системы аутентификации. Например, session token / jwt в header или session token в body param. Также, если на сайте используется какая-то форма, то рекомендуется реализовывать anti-csrf token’ы. Их суть в том, что сервер в response отдаёт два случайных токена. Один предназначен для куков, другой прячется в скрытом поле формы. Когда клиент submit’ит форму, то должен отправить оба токена обратно на сервер. В случае, если они отличаются от того, что сервер выпустил изначально, сервер блокирует запрос.

Integrity

В контексте информационной безопасности существует понятие CIA triad, объединяющее три аспекта:

• конфиденциальность; доступ к информации должен иметь только тот, кому она предназначается;
• доступность: информация должна быть доступна в нужном объеме и в нужное время;
• связность: то, насколько части системы могут доверять передаваемым друг другу сообщениям, и не произошло ли в процессе передачи нарушения данных.

В web’е это можно представить в виде отношений между frontend’ом и backend’ом. В html есть специальный атрибут integrity, позволяющий запускать скрипт только в том случае, если он не отличается от того, что изначально подразумевали его разработчики.

Предположим, что вы используете cdn (content delivery network) для оптимизации скорости доставки приложения, однако вы хотите быть уверены, что приложение, которое вы сбилдили сами, и то, которое получаете из cdn, — одно и то же. В этом случае можно в процессе прод-билда приложения сгенерировать integrity-хеш, который указывается следующим образом:

И когда браузер попытается загрузить скрипт из cdn, то, используя указанный алгоритм (в данном примере sha384) сгенерирует новый хеш на основе загруженного скрипта, произведет сравнение и позволит его запустить только в том случае, если хеши не отличаются.

В случае Angular’а включить генерацию таких хешей можно с помощью флага

—subresource-integrity.

Для создания форм в Angular я рекомендую Reactive Forms. Так можно использовать реактивную парадигму программирования, что более естественно для языка.

Работа с реактивными формами

Кратко работу с реактивными формами можно описать так: вы явно описываете форму в контроллере, включая валидацию и маппите свою модель данных на модель формы. А все необходимые операции с данными производите явно через методы формы. Также можно зарефакторить переиспользуемую логику. Модель формы описывается отдельно, благодаря этому модель данных останется неизменной во время работы пользователей с формой.

Для наглядности возьмём пример по Template-Driven Form из туториала Tour of Hero и перепишем его на реактивные формы. В результате получим следующий код контроллера hero-form.component.ts:

Первое на что стоит обратить внимание: помимо модели данных, мы создали объект класса FormGroup. С ним мы сможем описать модель представления формы и затем передать ее непосредственно форме.

Из примера выше, можно заметить, что наша FormGroup создается через другой класс FormBuilder. По сути, это класс-помощник, позволяющий создать объекты формы: FormGroup, FormControl и FormArray. К тому же наша модель формы сейчас почти идентично повторяет модель данных model.

Операция маппинга модели данных на модель формы (и в последующем обратный маппинг) требует дополнительный код. Но несмотря на это нашего подхода есть один очень большой плюс. Модель данных на время работы с формой остаётся неизменной. Это позволяет сделать логику более гибкой. Плюс к вашему коду будет проще написать тесты. Замечу, что в своём примере, я пока намеренно не маппил модель данных на модель формы, чтобы осветить этот вопрос подробнее чуть ниже.

Примечание Несмотря на то, что в Template-Driven Form работа с формой происходит с директивой ngForm, «под капотом» она тоже неявно создаст объект FormGroup (советую для общего понимания ознакомится с исходниками).

Теперь рассмотрим код получившегося шаблона hero-form.component.html:

Первое, что замечаем — это передача нашей модели формы heroForm директиве [formGroup]. Angular для инициализации реактивной формы использует директивной подход с помощью селектора [formGroup], тем самым создавая объект FormGroupDirective c обязательным параметром типа FormGroup. Второе, на что стоит обратить внимание — мы подписываемся на событие ngSubmit, которое вызовется в случае сабмита формы (в нашем случае по нажатию по кнопке Submit).

Третий пункт нашей формы — это атрибуты formControlName, по которым сработает другая реактивная директива FormControlName. Она принимает в качестве параметра названия поля формы и создаёт объект FormControl. А также привязывает его к родительскому FormGroup и связывает контрол по указанному полю с html элементом.

Опционально можно описать для каждого из контролов элементы валидации. Так, в нашем примере в разметке пользователю мы показываем что поля Name и Power обязательные. Делается это довольно просто:

1. Получаем необходимый FormControl с помощью метода get формы;
2. Далее получаем стандартный набор состояний контрола: valid, invalid, pending, disabled, enabled, dirty, pristine, touched, untouched (см. более подробно официальное API);
3. Реализуем нужное поведение элемента валидации, поверяя необходимые свойства контрола.

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

Если запустить код проекта, мы увидим, что форма пустая. Дело как раз в том, что мы незамаппили нашу модель. Попробуем сделать это через метод setValue:

Вместо того, чтобы увидеть нашу форму в браузере, в консоли получим ошибку:

Проблема в том, что setValue ищет для каждого поля модели соответствующее поле в модели формы. Мы не описали поле id, так как оно излишне в  представлении. Есть три пути решения проблемы. Самый верный — вручную замаппить модель данных на модель формы:

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

Примечание resetForm сбросит все поля в дефолтные.

Наконец, можем воспользоваться методом patchValue, который для каждого найденного поля объекта в форме перепишет значение. А если не найдёт, то просто пропустит его. Это допустимо, если вы точно знаете, что модель данных всегда придёт со всеми необходимыми полями для формы:

Дочерние группы

Следующий пункт, который я хочу осветить — создание внутри объекта модели дочерние группы или одной FormGroup внутри другой. В реальных проектах это необходимо, потому что формы, как правило, составные. Рассмотрим добавление подгрупп на нашем примере. Сначала создадим класс Phone и добавим поле phone в нашу модель данных:

phone.ts:

hero.ts:

Теперь добавляем в модель формы поле phone:

В шаблоне добавляем разметку для отображения телефона:

Как видим, логика проставления здесь похожа, за исключением того, что мы связываем группу по директиве formGroupName. Остальное на себя возьмёт Angular, который свяжет её с родительской формой.

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

Строка viewProviders нужна  директиве FormGroupName, которая будет искать форму внутри host-элемента. В нашем случае у группы нет формы, и мы передаём провайдер, который найдёт родительскую форму. Если этого не сделать, мы получим ошибку:

Подводим итоги

Реактивные формы в Angular создаются так:

1. Создаём объект формы FormGroup, которая описывает вашу модель данных и правила валидации;
2. Маппим модель данных на модель формы;
3. Angular создаст реактивную форму, когда найдёт директиву [formGroup] с переданной ей моделью формы в шаблоне
4. Дочерние элементы формы в шаблоне связываются по следующим атрибутам formGroupName, formControlName и formAttayName ;
5. Объект формы FormGroup содержит все необходимые методы для того, чтобы получить отдельный контрол и проверить его состояние и состояние всей формы. А также для того, чтобы установить или обновить значение контролов формы. И ещё включает событие ngSubmit, чтобы отловить сабмит формы.

Рекомендуемые материалы

1. Исходный код проекта
2. Общее описание реализации форм с официального сайта Angular
3. Более подробное описание Reactive Forms с примерами на сайте Angular
4. Api по формам с сайта Angular
5. Исходники Angular, где вы можете более подробно изучить код форм

Начало работы с Angular 5 Material

Для начала необходимо установить Angular CLI глобально во всей системе. Для этого нужно выполнить следующую команду:

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

Создание проекта

В командной строке выполните следующую команду:

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

Установка Angular Material и Angular CDK

В командной строке введите команду для установки компонентов и их зависимостей:

Установка модуля Animations

Для работы с Angular Material нужно установить модуль Animations:

Теперь надо импортировать модули в файле app.module.ts:

Затем нужно добавить новый модуль, который будет отвечать за Angular Material Components. Для этого создется файл в src/app с именем ngmaterial.module.ts:

Теперь модуль MatButtonModule добавлен в приложение. Далее надо
зарегистрировать MaterialAppModule в app.module.ts:

Подключение тем оформления

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

Для примера будем использовать заранее подготовленную тему Angular Material Indigo-Pink. Подключим ее в приложение, добавив следующую строку в style.css:

Также подключим поддержку иконок в стиле material. Для этого добавим следующую строку в index.html:

Поддержка жестов

Некоторые элементы (mat-slide-toggle, mat-slider, matTooltip) используют HammerJS для обработки жестов. Для полной поддержки возможностей этих элементов надо подключить HammerJS в приложение.

Это можно сделать несколькими способами: через npm, с использованием CDN (например Google CDN) или же напрямую из приложения.

Рассмотрим способ подключения через npm. Для этого введем следующую команду:

После установки импортируем компонент в наше приложение, добавив следующие строки в src/main.ts:

Теперь, когда все модули подключены, добавим новый элемент в app.component.html:

Удалим лишний HTML-код и запустим приложение следующей командой:

Теперь приложение запущено и доступно по ссылке http://localhost:4200.

Если всё сделано правильно, то на странице отобразится кнопка, при нажатии на которую будет воспроизводиться анимация.

Добавление новых элементов интерфейса

На примере ToolBar разберемся, как добавлять новые элементы интерфейса в приложение. Для этого добавим следующие строки в app.component.html:

Также пропишем следующие строки и в ngmaterial.module.ts:

Таким образом мы добавили ToolBar в приложение.

Заключение

Мы рассмотрели построение простейших интерфейсов на Angular 5 Material. Если вы только начали знакомство с frontend, то вам стоит обратить внимание на наш материал для начинающих разработчиков.

Но вместо перехода на обновления 2 раза в год, как было обещано, корпорация решила пропустить версию 3.0 и выпустить сразу Angular 4.0.

Сотрудник Google Игорь Минар на конференции NG-BE 2016 рассказал, что всё дело в большем количестве изменений, чем планировалось, и новой системе роутинга.

«Впрочем, я вообще не советую говорить о версиях Angular. Не называйте это AngularJS, не называйте Angular 2. Зовите просто — Angular — ведь с выходом новых версий путаница будет становиться всё сильнее» — заявил Игорь.

Подробнее почитать о причинах такого версионирования можно в официальном блоге.