[Перевод] Пришло время избавиться от Angular и сэкономить миллиарды долларов
Я знаю, что эта статья вызовет поток гневных комментариев, но… так тому и быть. Кто-то должен наконец озвучить то, о чём уже некоторое время размышляют программисты, обладающие некоторым опытом.
Я занимаюсь программированием более 20 лет, работал в некоторых из самых приличных североамериканских компаний. Вот уже несколько лет я наблюдаю за тем, что происходит в сфере разработки интерфейсов. Ситуация здесь постоянно ухудшается. В частности, я говорю о «модных технологиях», о довольно крупных фрагментах JS- и CSS-кода, претендующих на остроумное исполнение, которые вроде как должны пользоваться неистовой популярностью у толп новичков. Теперь в эти толпы включают даже и опытных разработчиков, которым полагается что-то понимать в том, чем они пользуются.
Количество случаев практического применения фреймворков, выдающих подобный код, наподобие Angular, растёт как снежный ком. В результате разработчиков подхватила лавина, ввергнувшая их в настоящий «ад программного кода». При этом события развиваются по нарастающей. Сейчас нельзя заметить даже признаков того, что всё это безумие хотя бы выходит на какой-то постоянный уровень.
Каждый день мне на почту приходят вакансии. Компании всех размеров и мастей рыщут в поисках ОПЫТНЫХ Angular 4, 5, 6, 7, 8, 10, 12-разработчиков, которые как минимум 5 лет занимались разработкой и поддержкой того дурдома, который все называют «современнейшими пользовательскими интерфейсами».
Это — не нечто «современнейшее». Это — дурдом.
Несколько лет назад я был на собеседовании в EA (Electronic Arts). Там мне сказали, что компания избавляется от всех своих UI-фреймворков и возвращаются к написанию кода на чистом JavaScript (речь идёт о модулях, или о том, что тот, кто работает с jQuery, назвал бы JS-плагинами). Я был удивлён и заинтригован.
Теперь о причинах подобного хода знают не только в EA, но и во всех остальных компаниях.
KISS, но без «тупиц»
Мне не нравится обзывать людей «тупицами», как это делается в названии принципа KISS («Keep It Simple, Stupid» — «Делай проще, тупица»). Поэтому я немного переделал предложение, лежащее в основе акронима KISS. У меня получилось «Keep It Stupid-Simple» — «Делай предельно просто». KISS — хорошая штука, но этот принцип в последних версиях Angular совершенно потерян. Angular — это уже не просто UI-фреймворк. Это теперь ещё и бэкенд-сервис. А значит — разработчикам Angular-интерфейсов, вдобавок к их основным задачам, приходится решать ещё и задачу написания серверного кода, которая выходит за рамки написания HTML-шаблонов. Кто-то может сказать, что это хорошо. Но, на самом деле, это не так.
Конечно, в Angular имеются кое-какие «замечательные» возможности, но все они совершенно не нужны для того чтобы создавать эффективные и привлекательные интерфейсы, или чтобы обеспечивать сайтам UX профессионального уровня.
Время SPA (Single Page Application, одностраничное приложение) прошло. Их сложно поддерживать, они вредят аналитике и поисковым роботам, которые полагаются на то, что смена URL приводит к загрузке новой страницы.
Конечно, эти проблемы можно обойти. Но в том-то всё и дело! У того, кто занимает разработкой интерфейсов, не должно возникать необходимости в написании кода для обхода особенностей используемых им инструментов, не соответствующих принципам работы веба!
Просто скажем «нет» UI-компиляторам
Ещё одна «мода», которая существует уже какое-то время, и которой тоже надо бы уйти в прошлое — это мода на Sass и LESS. Если говорить честно, то мне нравится тот подход к организации кода, который предлагают эти CSS-инструменты. А вот что мне в них не нравится — так это «миксины», и то, что этот код, перед использованием на сайтах, надо компилировать.
Если говорить об удобстве, то я не знаю о том, почему разработчики браузеров до сих пор не добавили в них поддержку SCSS в виде стандартного механизма для работы с CSS-кодом, но это — отдельная тема.
В итоге о псевдо-языках, имеющих отношение к CSS, можно сказать, что их применение, на самом деле, не приводит к экономии времени. Изучать и использовать их не легче, чем обычный CSS. И, в конечном счёте, реальным результатом их использования является генерирование качественного CSS-кода, чётко ориентированного на стилизацию определённых элементов, такого кода, который любой веб-разработчик, в любом случае, должен уметь писать самостоятельно.
Если кто-то хочет применять Sass или LESS, используя результаты их предварительной компиляции в своём окружении разработки, я не вижу в этом проблемы. Но полагаю, что мы никогда не должны сталкиваться с проникновением этих материалов в CI/CD-цепочки для их компиляции в ходе развёртывания проектов.
То же самое касается и любых других JavaScript-библиотек или фреймворков, код которых, в итоге, тоже компилируется в обычный JavaScript.
Каждый дополнительный шаг, добавленный в CI/CD-цепочку, просто засоряет и неоправданно удлиняет процесс развёртывания проекта, который должен быть очень простым и быстрым. И разработчикам стоит искать пути сокращения количества шагов в этом процессе, а не добавлять в него что-то новое только из-за того, что нечто вроде Jenkins это позволяет.
Angular «раздувает» код интерфейсов
Можете называть меня «интерфейсным пуристом», но то, что происходит сегодня в сфере программирования интерфейсов, нельзя называть «передовым ИТ-достижением». Это скорее результат применения некоей «кучи технологий». Я понимаю, что программистам в Google скучно, что им надо что-то делать, но Angular и подобные ему фреймворки лишь усложняют код пользовательских интерфейсов, разрушая его «природную» простоту.
Смысл тут в том, что для написания чистого и аккуратного UI-кода, для создания эффективного UX, не нужен фреймворк, под завязку набитый сомнительными возможностями. Для этих целей можно пользоваться любым движком для работы с шаблонами, предоставляемым бэкендом, и при этом не перегружать фронтенд невразумительным скомпилированным JS-кодом, практически не поддающимся отладке.
Компании тратят на Angular миллиарды долларов
Цель применения любого фреймворка заключается в том, чтобы упростить, а не усложнить программирование. Предполагается, что переход на некий фреймворк должен помочь компании сэкономить за счёт упрощения работы, а не становиться причиной новых затрат.
Но в реальности оказывается, что переход на Angular не приводит к экономии.
К сожалению, Angular, да и другие UI-фреймворки, стоят компаниям больших денег. В частности, речь идёт о постоянном обучении и переобучении персонала в условиях, когда, можно сказать, ежегодно, выходят новые версии фреймворка. Конечно, теперь разработчики Angular обещают, что все его новые версии будут обратно совместимы со старыми, но, опять же, речь идёт о добавлении чего-то нового к и без того перегруженному возможностями инструменту, когда для обеспечения работы очередного нового «просто замечательного» компонента всё снова придётся менять.
И — Бог вам в помощь, если вы — подрядчик, работающий с несколькими организациями, использующими разные UI-фреймворки. Вам нужно будет знать не только 12 разновидностей Angular, но ещё и разные версии Vue и React, так как какой-то новичок «подсадил» некую компанию на нечто подобное 4 года назад, а теперь ушёл оттуда, чем разрушил чей-то технологический стек.
Пришло время отправить Angular и другие подобные разработки на свалку неудавшихся экспериментов, где им и место.
Чем заменить Angular?
Ответ на вопрос, вынесенный в заголовок этого раздела, очень прост: Angular не надо ничем заменять. От него надо полностью избавиться. Его надо выбросить и написать вместо него простые, лёгкие в использовании и понятные JavaScript-модули (или плагины — называть их можно по-разному).
Я не являюсь противником использования опенсорсных библиотек вроде jQuery, или других UI-компонентов, или CSS-фреймворков вроде Bootstrap. Их можно «включить» в состав проекта, написав буквально пару строк кода. И они по-настоящему серьёзно упрощают жизнь разработчиков.
Но если фреймворку, вроде Tailwind, нужна для работы платформа Node.js, или если нужно учить и переучивать персонал из-за того, что разработчики фреймворка каждый год его переделывают, то всё это выливается в серьёзные затраты. И за что приходится платить? Лишь за то, чтобы пользоваться чем-то «сверхсовременным»?
Суть тут в том, что Angular засоряет рабочие процессы. Его применение обходится компаниям в тысячи, а может — и в десятки тысяч долларов. А если говорить о компаниях из списка Fortune 1000, то речь уже может идти о миллионах, которые каждый год тратятся на поддержку проектов, на обновления ПО, на обучение программистов. К этому добавляются затраты времени на поиск опытных программистов, или хотя бы тех, кто готов пойти на поддержку существующих монструозных проектов.
Когда я вижу, что компания отчаянно ищет UI-программистов, она неизменно нуждается в специалистах, обладающих 3–5 годами опыта разработки на Angular. Это — абсурд. Я могу создать аккуратный, полнофункциональный интерфейс на обычном JS за меньшее время, чем это способен сделать Angular-разработчик. При этом мне не придётся сталкиваться со всеми фронтенд- и бэкенд-сложностями, характерными для Angular.
Узкоспециализированные JavaScript-модули отлично подходят для разработки современных интерфейсов, позволяя достигать баланса между сложностью этих интерфейсов и элегантной простотой лежащей в их основе DOM.
Если в продакшн-варианте проекта, основанного на чистом JavaScript, что-то «поломается», на поиск проблемы уйдут буквально секунды, а пользоваться при этом можно инструментами разработчика любого браузера. Для решения проблемы не придётся устанавливать нечто лишь для того, чтобы получить возможность отлаживать скомпилированный код.
Итоги
Святой Грааль написания кода, любого кода, заключается в простоте. Но мы, современные программисты, совершенно потеряли это из виду. Нас захватывают новые сверкающие технологии, которые выпускают технологические гиганты, мы считаем правильным и современным то, что нам, как данность, предлагают в учебных заведениях.
Но Google или некий университет не будут платить зарплату программистам. Поэтому техническим директорам компаний пора перетряхнуть используемые в них технологические стеки, убрать из них всякие «модные» вещи и вернуться к рационально обоснованным пользовательским интерфейсам, к интерфейсам простым, поддерживаемым и привлекательно выглядящим.
Как вы относитесь к использованию UI-фреймворков в веб-разработке?
