Почему, будучи полноприличным разработчиком, я полюбил Angular.

Это первая часть из двух частей, в которых рассматриваются точки зрения автора на Angular. Вторая часть уже в пути.

Недавно я прочитал историю, опубликованную явно разочарованным разработчиком из команды Whiteboard Dynamics. Эта история получила изрядное количество лайков, и мне было грустно видеть, что фреймворк, с которым мне действительно нравилось работать, подвергся критике. Я хотел бы сделать шаг назад и попытаться пройти по пунктам рецензии автора и попытаться сделать две вещи:

  1. Объясните с точки зрения разработчика, почему Angular делает то, что делает.
  2. Выявите основную неясность и потенциально предложите решение в случае, если что-то явно неясно и вызывает разочарование.

Примечание автора: очевидно, я предвзято отношусь к фреймворку. Я использую его каждый день, и мне очень нравится с ним работать. Обратите внимание: я НЕ работаю в Google и в настоящее время никоим образом не связан с Google. Я внес свой вклад в @ angular / material, но это все.

Сверху

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

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

  1. Они оказали ng-packagr поддержку @angular/cli
  2. Они добавили схемы для улучшения рабочего процесса обновления внешних угловых зависимостей.
  3. Они добавили поддержку библиотеки в основной рабочий процесс разработчика при использовании @angular/cli

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

Именование

Тирада автора продолжается, говоря, что Angular трудно произносить. Это банально, безвкусно и на самом деле не заслуживает ответа, но я, по крайней мере, обращусь к нему. Если вы утверждаете, что способность произносить слово влияет на его полезность, я бы попросил вас произнести слово Linux, Windows или Apple вслух и как-то попытаться вывести что-нибудь о «полезности». Я думаю, вам будет трудно утверждать, что любой из них имеет less полезности из-за того, как он назван.

Документация

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

Есть четыре основных типа документации, и позвольте мне сказать вам, есть ли у Angular они:

  1. Документы API
  2. Учебники
  3. "Образец кода"
  4. Руководства пользователя

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

Если вы не можете найти документацию, я бы сказал, что это скорее проблема RTFM, чем проблема Angular. Ответ, который вы ищете, есть, вы просто не смотрите.

В качестве дополнительного бонуса к уже известной документации команда @angular/core предоставляет бесконечные часы помощи и рекомендаций через gitter.im. Более того, если основной команды нет рядом, кто-то из сообщества почти всегда готов помочь.

Angular против AngularJS

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

Angular, также известный как «Angular 2+», похож на скальпель для масляного ножа AngularJS. У этих двух фреймворков есть сильные параллели, и переведенные концепции можно легко найти, но если разработчик жалуется, потому что вы не можете скопировать / вставить код из-за переполнения стека, я бы сказал, что это не вина Angular, это вина разработчика, который отказался думать. Чтобы еще больше развить эту точку зрения, псевдокод автора признает тот факт, что все, что он хочет сделать, - это найти решение, допускающее копирование / вставку, которое мне неприятно читать. Я прошу автора помнить, что работа разработчика состоит в том, чтобы понимать и расширять, а не копировать и вставлять из StackOverflow.

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

Фактическая критика

Вы объявили EntryComponent в модуле, в который он предназначен для ленивой загрузки, а не в корневой модуль Module, где он теряет все преимущества отложенной загрузки? Nein! Вы пытались использовать Two-Way Data Binding ™, а не загадочную цепочку последовательностей `EventEmitter`s и` Subscription`s и `Service`s? Verboten!

Я не совсем уверен, что понимаю проблему с EntryComponents здесь, я бы попросил автора немного прояснить это, чтобы я мог лучше ответить.

Что касается последнего пункта, касающегося двусторонней привязки данных, генераторов событий, служб и подписок, я чувствую, что автор не понимает, что на самом деле скрывается за Angular. Похоже, они пытаются заставить Angular делать то, чего на самом деле не должно быть. Эти вопросы обычно вращаются вокруг концепции «государственного управления».

Вообще говоря, Angular следует рассматривать как четыре вещи:

  1. Механизм рендеринга
  2. Контейнер Inversion of Control (IoC), который добавляет внедрение зависимостей
  3. Платформа дочерних модулей, которые можно добавлять по мере необходимости для достижения целей вашего проекта.
  4. Самоуверенный процесс разработки, предназначенный для повышения качества и скорости разработки.

Если вы жалуетесь, что Angular плохо справляется с управлением состоянием, это потому, что он не предназначен. Хотя это МОЖЕТ, вы действительно не должны позволять этому. Вот почему библиотеки, такие как Redux и Flux, так широко используются во фронтенд-разработке. И тем из вас, кто думает, что Redux можно использовать только с React, я хотел бы попросить вас проверить ngrx / platform.

Вы на полной скорости врезаетесь в кирпичную стену достаточное количество раз, и в конце концов вы научитесь ползать со скоростью улитки, жалко выискивая любые произвольные препятствия, которые РАМКА может создать на вашем пути.

Я задам один-единственный вопрос: вы когда-нибудь пытались написать приложение jQuery из 3000+ строк? Если нет, напишите следующее приложение на необработанном javascript или jQuery. Чтобы было ясно, под этим я подразумеваю не маркетинговый сайт, не мини-сайт. Приложение. Хотя вы можете найти лучшие ответы на копипаст из StackOverflow, я готов поспорить, что к строке 500 вы будете меньше грустить о «TypeErrors», «Subscriptions» и «EventEmitters», чем о запутанном беспорядке «it». работает, не трогайте его », который вы только что создали и боитесь прикоснуться к нему снова.

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

Далее я обращусь к критике автора архитектуры и повседневного опыта разработки.

Продолжение следует…