Розбий моноліт! Kuberton — хакатон для DevOps-ів & Python, Java, Ruby, GO розробників. 1-2 Dec
×Закрыть

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 прикрутять, то реактивний підхід... Переписують постійно свої поробки, а полегшення не настає.

у нас на реакте с кучей разного функционала и не оптимизированного кода в рабочем проекте — бандл 2.6Мб в прод версии и 9Мб в фуллдев
и растет =)))

Чуть позже будем думать по поводу лейзи лоад загрузки, а пока что не особо парит

ну и все зависит от обьема функционала, если уж меряться бандлами!)

это с tree-shaking webpack’a?

судя по всему — без, но с минимайзером аглифай

„sideEffects”: false,

new UglifyJsPlugin({
uglifyOptions: {
mangle: true
}
}

Функціональність не сильно важлива, будемо вважати, що проекти стиглі, сталі, ентерпрайз левела як мінімум. Цікавить тільки розмір 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 отличается, нужно быть внимательным при использовании, а может лучше вообще не использовать.

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