Что побудило нас выбрать Angular 2+ в качестве внешнего фреймворка?
Мы прошли довольно долгий путь с тех пор, как впервые начали работать над justasking.io в начале мая 2017 года. Мы решили создать доступное решение для опроса в реальном времени и решили, что используя Angular для наших передок был хорошим началом. Angular 4 был только что из духовки, и Angular Material медленно, но верно готовился к работе. Мы хотели создать что-то с использованием новейших технологий и были готовы рисковать, в конце концов, если это не сработало, мы всегда могли переключиться на что-то другое, например Vue или React.
У меня был некоторый опыт работы с Angular 1, но я никогда не чувствовал себя слишком комфортно с его циклом дайджеста, его контроллерами и фабриками. Однако Angular 2 с Typescript оказался совсем другим. Он был больше похож на код .NET, который вам покажется знакомым, если вы работали с .NET MVC или .NET Web API. Создание каркаса для приложения стало более естественным, и с появлением angular-cli стало проще создавать модули, компоненты, службы и почти все, что может предложить Angular.
Мы сосредоточились на том, что для нас было важно.
Поскольку наша цель - действовать быстро и обеспечить максимальную ценность за короткий период времени, это казалось несложным. Angular и его инструмент cli помогли нам быстро освоить прототип. Это позволило нам получить доказательство концепции в течение пары недель и принять решение о том, хотим ли мы двигаться вперед с Angular для интерфейса. Переход от POC к реальному веб-приложению был непростой задачей, мы хотели использовать такие функции, как отложенная загрузка модулей, прогрессивные улучшения и модульное тестирование.
Когда у вас есть функции, которые вы хотите построить, последнее, о чем вы хотите беспокоиться, - это сантехника. Например, маршрутизация в приложении должна быть интуитивно понятной и простой в реализации. Учитывая, насколько сильно мы полагаемся на маршруты и шаблоны, мы были очень довольны тем, насколько легко Angular позволяет настроить маршрутизацию на модульном уровне, чтобы вы могли лениво загружать модуль вместе со всеми его маршрутами. Ваши пользователи будут загружать только те ресурсы, которые необходимы в данный момент. Это значительно сокращает время начальной загрузки. Тратить меньше времени на настройку и больше времени на добавление функций - большое преимущество, которое мы обнаружили с помощью Angular.
Это не для всех.
Мы не забываем о негативных аспектах Angular, и я не хочу вводить вас в заблуждение. Angular не является легким, в нашем случае большая часть размера JavaScript приложения идет на Angular, а не на наш код. Angular универсален, это обоюдоострый меч, нужно время, чтобы овладеть им, и еще больше времени, чтобы овладеть им ... я дам вам знать, когда я доберусь до него, не задерживайте дыхание. У него крутая кривая обучения. Мы готовы пойти на эти риски и уважать недостатки структуры из-за множества преимуществ, связанных с нашим процессом разработки.
Пока что у нас это работает, и наша кодовая база неплохо масштабируется.
