Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

Angular 4+. Можно ли сказать что поддержка проектов с ним в среднем проще чем React?

Раньше работал с React/Redux. Сейчас руководство дает возможность освоить и выбрать фреймворк для след. проекта.
Понимаю вопрос очень субъективен, но у меня серьезного опыта с Angular нет и очень важен ваш.

Angular 4+ кажется сложнее в изучении, но проще в поддержке.

Причины по которым у меня сложилось такое мнение:
Проекты с React собираются как конструктор и каждый его собирает очень по-своему.
Например знаешь Redux, но на проекте его используют через Ramda — и код с первого взгляда будет казаться иероглифами.
Вместо Redux может быть MobX или Cerebral. Они хороши каждый для своей задачи — но это опять таки время для освоения, которого в запарке может не быть.
Angular все таки фреймворк — а значит поступающие проекты должны использовать общепринятые инструменты.

Angular использует TypeScript
Что в теории должно облегчать рефакторинг, исправление багов, добавление фич.
У React для этого есть flow, но у него кривая обучения выше и он не обязателен, а значит шанс получить проект с ним меньше. Для Angular — TS это почти стандарт.

«API у Angular 4-5-6 не меняется радикально»
У React 16.3 большие обновления, которые могут радикально изменить способ построения приложения. Google вроде выучила уроки перехода с AngularJS и больше не меняет API радикально. По отзывам.

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

Но повторюсь, серьезного опыта с Angular у меня нет. Очень ценна конкретика из вашего опыта.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Один из самых больших минусов Angular — очень большой размер bundle (сейчас 3 мегабайта и объем растет с каждой новой версией). Положение должен улучшить ivy renderer, который разрабатывается с января и по идее должен был войти в Angular 6, но так и не вошел и видно, что и не войдет. Прогресс по нему уже давно на уровне 60-65% и ситуация не меняется последние 3 месяца.
Но если его доделают, то размер должен уменьшится раза в 4 минимум.

с Angular будь готов воевать с фрейворком и бороться с косяками их архитектуры

Спасибо за ответ. Можно конкретику пожалуйста?

их принцип что Ангуляр это платформа — то есть если логически что-то должно работать то там не факт (в основном это относится к АОТ), а косяков в архитектуре валом, в целом они не очень критичны но когда наступаешь то очень больно и не приятно (отсюда философский вопрос — может ли изменится то что никогда не существовало, подсказка по версии ангуляра — ДА, и особенности с двойным transclusion)

Так и не увидели мы конкретики)

как попробуешь сделать accessible combobox который нормально генерится при помощи компонентов, инжектит опционально валидацию, а потом завернешь его в несколько стейтфулл компонент (бо так удобнее) — тогда и будет конкретика

или когда ты напишешь декоратор который мутирует компоненты добавляя/врапая lifycicle методы (ибо это очень удобно), и в jit все будет работать, а вот aot все похерит с аргументацией — ангуляр это платформа, делаем что хотим

или когда захочется сделать график с красивой анимацией, и решишь интегрировать d3.js (так как на нем это очень легко сделать) и вдруг окажется что ngOnChange вызывается перед ngOnInit — что наталкивает на мысль что у авторов ангуляра мозг отсутствовал

а может ктото вкинит в app module стратегию реюзания компонент, и вдруг целый роутинг не работает как в доке, а по магическим правилам которые непонятно откуда берутся

а есть еще классный вариант, когда врапаешь проекцию чтобы спроецировать снова это не работает, и инфа о том как это сдлеать (ngProjectAs) есть только в баге на гитхабе а в оф доке шиш

а еще ты захочешь заюзать ресолвинг в роутах (ведь выглядит удобно), а если там вернется реджектед промис или обзрервабл с еррором — то весь роутинг стреляет еррором — и весь контекст юзера теряется — вообще сказка с точки зрения юкс, но ты не такой, ты можешь пойти целиком в redux (только скорее всего на твоем проекте это будет overhead который кроме увеличения complexity не приносит value)

а, ну и конечно скорость билдов просто великолепна — можно пойти сделать себе кофе когда небольшой проектик билдится — удобно, че там, а еще лучше с тестами на TestBed запускать — тогда еще перекусить можно

а так то супер фреймворк — можешь юзать DI — только не можешь ссылаться как белые люди на интерфейс когда нужна зависимость ибо в TS это compile-time only

Из вышеприведенного больше видно твое отношение к данной технологии, а не реальные «косяки архитектуры» как ты написал. У каждой «платформы» есть плюсы, минусы ограничения и методы обходов этих ограничений.
По lifycile, опять же твое отношение к этому, и не понятно почему «вдруг» все ж описано))
В следующих двух пунктах тоже не видать дыр в архитектуре? О резолверах в доках не так порасписано, ну так статеек хватает.
Скорость билдов особо не с чем сравнить, но может пора тачку апдейтить раз успеваешь кофе заварить?

Ясен пень что у меня плохое отношение, но все что я описал реальные проблемы.
Если гавно задокументировать оно все равно остаётся гавном. То что я привёл то лишь часть говна, просто сходу все не вспомнишь.
А насчёт скорости билда есть с чем сравнивать, и комп и так не слабенький проблемы были на проекте всего в 30к линий кода (то есть даже не средний) с минимум зависимостей (насколько это было возможно)

Честно говоря я — совсем новичок, но я светло верю в Ангуляр из основного минуса вижу: скорость первичной загрузки, но вот в конце этого года должна выйти 7я версия (и как писал ранее — верю что они будут это дело улучшать). Для «больших» проектов — мастхев.

P.S Вот ссылка на чатик Ангуляра лучше там еще спросить (t.me/angular_ru).

А что вы подразумеваете под

скорость первичной загрузки

? Если я правильно понял о чем вы — не вижу в чем проблема?

Мне вот интересно, по факту в Angular на обычном проекте реально получить бандл не размеров 3 МБ? Вот эти вот Ivy ..

А який середній розмір проекта на Янгулярі? А на Реякті? Хочеться статистику зібрати. В мене на власному фреймворку менше 200 кілобайт gzipped контенту (html+js+css).

Я тут пробовал писать на hyperapp. Вот это фреймворк.

JSX в JS вообщето. Это типа реакта, каким он возможно должен был быть, без всякой чуши.

В пічку його, в пічку! © Професор Преображенський.

Next-generation HTML Templates in JavaScript

Та така сама срака, як й JSX. Мені от цікаво, скільки людей мусить пройти шлях болі та страждання, щоб зрозуміти, що ідея генерації HTML через JS безглузда по суті. Це боляче в будь-якому разі.

Треба відрізняти динаміку на сторінці (яка може бути частково організована за рахунок CSS, частково за рахунок JS), процес генерації DOM дерева та декларацію генерації. Звісно ж DOM без JS неможливо поміняти. Але декларацію темплейта не обов’язково робити в JS. Її там роблять тому, що була задача навішати обробники та прив’язати якусь логіку до коду. Фактично в сучасних фреймворках HTML розглядається майже завжди як результат роботи JS. Тому початок роботи над проектом йде з JS (JS first), а не з HTML. Знання про якісь дані знову ж таки розташовані в JS, хоча DOM може впоратися з цією задачею не гірше, а в деяких моментах й краще, тому що на допомогу приходять оптимізації двигунів браузерів. Логіка виноситься в JS, хоча вона в більшості випадків є наслідком постійної трансформації даних, та може бути описана в інший спосіб, декларативно, а не імперативно, як всі звикли. От всі й живуть в світі дивних франкенштейнів, які переписують щороку кардинально, бо попередні версії не живуть без чарівних пєндєлєй.

Це шлях нескінченного страждання. Немає сенсу переносити багато в JS. Навіть логіку можна по максимуму звідти винести. Якщо розбиратися, яка логіка зараз в фреймворках, то в більшості випадків це тупняк: трансформація структури даних з «A» в «B», нескінченні запити до сервера, валідація даних, банальні статистичні операції.

Базис — структури даних. Але їх підтримка зазвичай настільки дорога, що мама не горюй! Чому? Бо структуру даних на UI треба якось відображати. В одному місці в один спосіб, в іншому — якось інакше. Модель даних починає впливати на темплейтинг. Тобто замість модулярізації по UI компонентах, фреймворк стимулює модулярізацію по типах/сетах даних. Майже ніхто зараз не оперує такими компонентами як «табулятор», «перелік з іконками», «пейджер», «бокс», «лейаут», які природні для побудови UI. Всі будують «перелік користувачів», «фільтр користувачів», «каталог товарів», тощо. Тому повторне використання коду не просто низьке, а супернизьке. Окей, ладно, вирішили ми перейти на UI-модулі/компоненти. А тут виникає наступна проблема, треба трансформувати дані в іншу презентацію, щоб універсальні UI-компоненти могли відображати дані як з переліку користувачів, так й з переліку новин, компаній, товарів, тощо. З першого погляду задача елементарна. Але не з інструментарієм JS (точніше не з поточними підходами).

От й бігають всі навколо цих проблем, намагаючись хоч якось собі зменшити рівень попоболі. То MVC прикрутять, то реактивний підхід... Переписують постійно свої поробки, а полегшення не настає.

Функціональність не сильно важлива, будемо вважати, що проекти стиглі, сталі, ентерпрайз левела як мінімум. Цікавить тільки розмір html+css+js.

У нас бандл на Angular 6 в проде до gzip 2.5Мб, после 500 кб )

RxJS может и не самый простой для понимания, но в случае освоения становится достаточно мощным инструментом управления событиями.

В целом, не было никаких проблем ни с поддержкой ангулар 4, ни с вхождением в проект новых людей.

но в случае освоения становится достаточно мощным инструментом управления событиями.

Та нічого там потужного немає. Поки ви формуєте ланцюг виконання власноруч, ви будете страждати, страждати та ще раз страждати.

Angular использует TypeScript

К новому проекту на React TypeScript подключить стоит примерно 1 час.

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

не понимаю. я думал, вы выбираете технологию.
в существующих проектах технология уже выбрана.
не вами и давно.

тогда к чему беспокойство по поводу Typescript в отрыве от фреймворка?

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

Мне например что ангулар что реакт один фиг, потому что я с ними не работал. Зато много работал с ember и на нем мне конечно проще разобраться. Но и тут не всё так однозначно — костыли все равно у каждого разработчика свои; а если поддерживать версии ещё до ember-cli — то ещё разбираться чем проект собирался и что где лежит.

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

Основное (и, я считаю, единственное) преимущество React над Angular 2+ — в том, что на React значительно проще найти разработчиков. Как мне кажется, в основном засчёт Typescript, который по большому счёт похож больше на C#, чем на Javascript. И ещё засчёт печального наследия AngularJS (первой версии), который был не очень хорош и который всё ещё много где испоьзуется. Люди месяцами не могут найти вменяемого Angular 2+ разработчика, поэтому делается выбор в пользу React вплоть до переписывания.

Если же просто сравнивать технологии как они есть, то я бы сказал, что Angular 2+ лучше. Не только из-за поддержки, но и на этапе разработки, по большому количеству причин.

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

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

по большому количеству причин

Не могли бы назвать их. Кроме тайпскрипта.

1. В первую очередь, это подход к структуре проекта. Конечно, будет неверно говорить, что Angular 2+ — это MVC фреймворк, потому что таковым был AngularJS, а 2+ — морская свинка (и не MVC, и не фреймворк). Тем не менее, он полностью сохранил MVC-подобный подход: компоненты отдельно, шаблон отдельно, модели отдельно, сервисы отдельно. А в React что? Компонент — это логика, перемешанная с покорёженным html-кодом, в лучшем случае сервис лежит отдельно с набором фетчей.
2. Раз уж зашла речь о html-коде. Возможности по шаблонизации в Angular гораздо гибче и «нативнее». В определённом смысле можно сказать, что возможности, предоставляемые Angular — это следующий шаг развития классического инструментария, такого как Smarty и Twig. В React таких возможностей нет в принципе.
3. Компонент в Angular — это по-настоящему вещь в себе. Нужно тебе прокинуть что-то внутрь или наружу — прокидывай через цепочку событий. Органично и логично. Или через сервис. Никаких костылей типа state и props (с помощью @Input, если надо, можно как через props и сразу в поле класса), все нужные данные инкапсулированы и хранятся в компоненте как в классе.
4. Two-way binding из коробки. Хочешь используй одно из направление, хочешь — два.
5. Как следствие из предыдущих двух пунктов: Angular для полноценной работы не нужны такие вещи как Redux и аналогичные инструменты. Создавать вырвиглазную обёртку для экспорта модуля, привязываться к событиям отдельных элементов, маппить их к props, а потом отдельно в switch/case обрабатывать... ORLY? По-моему, весь Redux — это смачный такой костыль для React, а не архитектурное решение. В принципе ничего не имею против идеологии Flux, но блин не в такой реализации.
6. Вышеупомянутая Rx.js и Observable коллекции делают процесс взаимодействия супер бесшовным и прозрачным. К данным всегда можно органично подлезть для воплощения самых неприличных фантазий.
7. Как сказал комментатор ниже, Angular отошёл от DOM как такового, и это правильно. У нас больше не связка html+css+js, а полноценный консистентный проект. На практике конечно бывает так, что надо обратиться к DOM средствами Javascript. Но это почти всегда костыль и сигнал о кривых архитектурных решениях (ваших или поставщика компонента), и тем не менее — это можно сделать.
8. До недавнего времени у React были проблемы с лицензированием.
9. Между AngularJS и Angular 2+ была полностью разорвана совместимость, можно сказать, что это два совершенно разных инструмента, причём первая версия до недавнего времени развивалась (сейчас переведена на LTS). Однако, между версиями Angular 2 и выше сохраняется совместимость и миграцию можно сделать достаточно бесшовно. В то время как между версиями React несовместимостей много: жизненный цикл компонента неоднократно меняют, роутер перепилили полностью (между 3 и 4 нет совместимости).
10. Последнее, но не менее важное. Уровень компаний, развивающих эти инструменты, хоть и сопоставим, но всё же сильно различается. Их ревенью отличается в разы. Количество и уровень проектов несопоставимы, как и возможности по поддержке внутренних разработок. Недавний инцидент с Facebook показал, как легко может быть подорвано доверие к этой компании, в то время как Google до сих пор даже GWT поддерживает. С инструментарием от Google я чувствую себя всё же несколько спокойнее, чем с инструментарием от Facebook.

Спасибо за содержательный ответ

Во многом согласен, но все же хочу возразить по нескольким пунктам.

1. Реакт — view library. Angular — opinionated framework. Это как сравнивать лопату и гараж. Реакт дает больше свободы, что во многих ситуациях нежелательно (например, когда нет опытных разработчиков), но в крупных проектах есть возможность подстроить процесс разработки более гибко под свои нужды.
2. JSX не зря считается одним из крутейших преимуществ Реакта. В первую очередь, он хорош тем, что имеем минимум library-specific синтаксиса, декларативен и читаем. Темплейты обычно имеют более высокий порог вхождения из-за специфичных для конкретной имплементации конструкций. Хотя, тут на вкус на и цвет.
3. Компонент в Реакте — это чистая функция отображения от данных. Если не нравится функциональщина и больше по душе ванильный ООП, это личные предпочтения, а не аргумент. А все данные точно также инкапсулированы внутри компонента. Если можете, то покажите код где нарушается изоляция — возможно, это просто неправильно написанный пример.
4. Controlled components.
5. Реакт дает больше свободы — хочешь Редакс прикрути, хочешь MobX / rxjs, хочешь свое что-то. Ну а со свободой приходит обязанность писать некий бойлерплейт, который более полный фреймворк инкапсулирует. Тут уж от проекта зависит что лучше.
6. Redux + Reselect = reusable state selectors + memoization, и доставай не хочу.
7. Same in React.
8. Были.
9. Роутер не часть Реакта, а сторонняя либа стороннего вендора. Не вижу причем тут FB. Тем более, если предлагают лучшее и дают пользоваться старым — в чем проблема? Breaking changes в Реакте — только после перехода на Fiber. И то, процесс миграции супер простой. Опять же, если либа стала лучше и мощнее — почему бы и не перейти?
10. Сложно дискутировать. Кладбище технологий Гугла, однако, на дает такого большого перевеса, как вы описали. Одно дело поддержка — другое развитие.

В общем, я бы советовал Реакт в те команды, где есть люди, которые умеют его правильно готовить. Если стоит выбор перед командой, которая не умеет ни в Ангулар, ни в Реакт — берите Ангулар.

П.С. Тайпскрипт таки хорош.

Неверное предположение. Поддержка — єто фикс багов и прикручивание новых фич. Что с первым, что со вторым в Реакте проще в несколько раз. От прикручивания новой фичи в 95% случаев ничего не отвалится «где-то там». А найти источник бага — пятиминутное дело.

+ к недостаткам:
новая концепция, которая не матчится на уже существующий опыт: RxJS, @Output/Input, вот эти все pipe’ы.
ни к AngularJS, ни к Browser Object Model, ни к JS вообще никакого отношения не имеет

если у вас звучит про «запарку», то с нуля вход в Реакт будет намного менее болезненным

UPD текущая ситуация на основании активных вакансий:
с React в заголовке 147
с «Angular» (без «JS») 86
(с AngularJS в заголовке 7, «vue» 13)

понятно, есть куча вакансий «Frontend developer», но у меня нет оснований предполагать, что за общей формулировкой работа на Angular скрывается чаще, чем работа с React(стыдятся?)

Есть еще React Native, а Angular Native нет :)

есть ionic, если очень хочется

Для нативных приложение Гугл выбрал NativeScript

Я о том, что есть «React Native» слово «React» упоминается немного чаще, чем могло если бы.

а, не правильно понял.
не думаю, что есть смысл разделять: среда другая, либы другие(reacti navigation, native base для продвинутых компонентов, если не хватает базовых), но принципы те же.
redux, one-way data flow, ref, child props — ничего не меняется.

с колокольни своего небольшого опыта с react native, переход React for Web -> React Native проще, чем redux -> mobX

А не Flutter, который они сами и пилят?

Google предлагает альтернативы, Flutter используется для нативных приложений на языке Dart, для ангуляра они предлагают сторонний фреймфорк NativeScript, который не завязан на ангуляр, и делает нативные приложения на JS.

проблема с поиском по тексту, шо часто встречается в требованиях «имеет знакомство с одним из популярных фреймворков(Angular, React, Backbone)».
т.е. без осознанного чтения требований в попытке отсеять именно специализированный вакансии надо будет где-то 300 вакансий перелопатить :(
потому я и ориентировался только на заголовок вакансии

забавность.
свои числа получил так: отобразил все вакансии раздела Front-End, затем querySelectorAll(’.l-vacancy .title’)->innerText->filter(/React/i).length
но почему-то получил отличающиеся результаты(например, у меня показатели выше дляReact)

а вот, поиск по angular и angularjs вообще одинаковое количество возвращает :)

А как это запускается?

querySelectorAll('.l-vacancy .title')->innerText->filter(/React/i).length

Браузерная консоль вроде выдает ошибку.

DOU поиск для запроса React немного улучшил (добавил синоним ReactJS):
jobs.dou.ua/...​ry=Front End&search=react
теперь должно быть однаковее.

то псевдокод для передачи идеи.

Array.prototype.slice.call(document.querySelectorAll('.l-vacancy .title'))
    .map(x=> x.innerText)
    .filter(x=> x.match(/AngularJS/i))
    .length

Спасибо, так работает :) DOU-поиск по умолчанию ищет в заголовке, названии компании и городах вакансии, а по тексту вакансии ищет только если установлен соответствующий чекбокс.

Также учитываются синонимы, чтобы одинаково работало как
jobs.dou.ua/...​ont End&search=react киев
так и
jobs.dou.ua/...​ont End&search=реакт kyiv

: RxJS, @Output/Input, вот эти все pipe’ы.

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

сколько времени у вас займет, чтоб объяснить эти штуки новичку?

ни к AngularJS, ни к Browser Object Model, ни к JS вообще никакого отношения не имеет

Так в этом и есть основное преимущество Angular. То что он отказался и от своего собственного неудачного легаси, и от JS как такового в пользу более продвинутого языка. Как уже писал выше, Typescript больше похож на C#, чем на JS. И это очень хорошо, если конечно рассматривать технологию саму по себе, а не в контексте количества доступных на рынке специалистов — тогда наоборот.

если у вас звучит про «запарку», то с нуля вход в Реакт будет намного менее болезненным

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

А что в

16.3

радикально поменялось?

Например Context API который теперь может использоваться вместо Redux.

ну, они «официализировали» фичу, которая и раньше была. разве ж то breaking changes?

Не стоит, контекст не для этого существует

stackoverflow.com/...​hen-should-i-use-each-one

Нет там ничего радикального.
— Contex API стал более эффективным и проще в использовании (если не достаточно примеров из документации, на Medium десятки статей по этой теме, например: codeburst.io/...​me-switchers-9cfbc8e5ee5e)
-Немного усложнился механизм работы с ref, а именно React.forwardRef, нужно быть внимательным если применили forwardRef для компонента, и если добавили HOC, нужно добавить forwardRef и для HOC (этот нюанс хорошо документирован, нет проблем разобраться)
— Новые Lifecycles, реализация getDerivedStateFromProps в 16.3 и 16.4 отличается, нужно быть внимательным при использовании, а может лучше вообще не использовать.

Подписаться на комментарии