Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

В чем преимущества React над Angular?

С моей точки зрения технологии практически идентичны. Angular даже несколько выигрывает по возможностям. Если смотреть на рынок, то соотношение примерно 60 к 30 в пользу React. Чем вызвана такая популярность React?

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

Ангуляр слишком сложный, в нем много багов и запутаного поведения.

Если смотреть на рынок, то соотношение примерно 60 к 30 в пользу React. Чем вызвана такая популярность React?

Років так із 8 тому, ще до появи цих самих Реакта із Ангуларом, було мега багато згадок у вакансіях за jQuery. Чого? — Бо легко вчиться, легко використовується, хороша документація, може завантажуватись із CDN...

І знаєте що із ним сталось, де він зараз? Еволюційні зміни у світі веб-розробки породили поняття Single Page Application. Зараз вже не достатньо прикрутити кастомний віджетик погоди, чи поле вводу із автокомплітом, зараз вже створюються цілі applications на frontend. jQuery віджив своє зіркове життя десь за 10 років з моменту появи.

Кажуть, що React теж легше вчиться, ніж Angular, має кращу документацію, простіший, краще дебажиться... Але таки на скільки React легший за Angular, мабуть на стільки ж і менш функціональніший.

P.S. Сам не писав на React, але періодично почитую свіжі порівняння із Angular.

jQuery все ще згадується в деяких вакансіях:
jobs.dou.ua/...​es/?search=jQuery&descr=1

Само-собою, далеко не усім проектам потрібен Angular чи React. Але його «зірковий час» таки вже минув...

P.S. Сам не писав на React, але періодично почитую свіжі порівняння із Angular.

Выделил главную часть, остальное можно не читать

Преимущество React в том, что он подразумевает использование Redux, навязывая таким образом качественную архитектуру приложения. В Angular приложениях использования фреймворка ngrx для реализации похожей архитектуры менее распространено, да и сам ngrx появился позже.

В жодному разі використання реакт не має на увазі використання редакс. Не вводьте людей в оману. Необхідно 100 раз обміркувати, чи вам дійсно необхідне його використання у вашому проекті, часто можна обійтись або звичайними стейтами, або React context API, або використати альтернативи типу mobx.

как вы определили что на React больше спрос? есть мнение что все совершенно наоборот

мне особенно нравится количество тех, кто юзал Ангулар и не планирует больше юзать. Говорящая стата :)

На 10% больше тех, кто юзал и хочет использвать и в дальнейшем =D
Хуже дела только у Кордовы, где тех, кто не будет больше использовать вдвое больше тех, кто использовал и будет еще.
ПС Я сам кордову поддерживаю и это боль =(

Реакт это про spa и только. Использовать его на сайте в связке с шаблонизатором фреймворка адекватно не получится.

vue.js в этом плане наоборот заточен под сайты: js компоненты раскидать по шаболону, кое-где с сео подружить

angular — универсал, и в целом из этих трех самый навороченный зверь. и эта навороченность с одной стороны плюс, тк все из коробки есть и не нужно ничего колхозить или докачивать чужие компоненты, но с другой стороны минус тк от этой навороченности страдает скорость инициализации, размеры загружаемых js файлов.

тут уже постили картинку с разного вида какашками?

да, кто-то твое фото рядом с Жуком постил

Аксиома эскобара.

Сначала я выбирал AngularJS vs Knockout.js. Потом Angular vs React. Потом забил и взял Polymer. Говорят, еще Vue.js очень норм.

Расскажите об опыте с Polymer, плз.

Мне с ним довольно приятно работать. Особенно после того, как они переехали на npm. Недавно зарелизили lit-html и новый базовый элемент, но я пока на него не переехал — другие приоритеты. Удобно, что есть много готовых компонентов и свои не сложно реализовывать. Начал использовать его в связке redux-saga для управления состоянием. So far so good.

Angular — в основном для enterprise приложений. Он более сложен и больше порог вхождения (плюс нужно еще выучить TypeScript). А TypeScript — это ООП и типизация, что опять же сложнее для изучения по сравнению с plain vanilla JavaScript

А TypeScript — это ООП

Возможно, Angular диктует ООП стиль разработки, но сам TypeScript никоим образом не заставляет этого делать.

А зачем использовать TypeScript без ООП? Какие преимущества в этом?

А зачем использовать реакт без ООП? Вы утвержадете, будто Angular = ООП, но это не так (хотя, конечно, без ООП там делать нечего, ну так и в реакте каждый компонент, по сути, класс)

Как минимум, строгая типизация с проверкой на этапе транспайлинга в JS, плюс более выразительные средства языка для описания предметной области (например, перечисления и алгебраические типы).

Если интересно, подробнее здесь: www.typescriptlang.org/...​dbook/advanced-types.html

React с TypeScript это тоже must have даже для не enterprise.

Чем вызвана такая популярность React?

Вероятно тем, что пока ангуляр переползал из стремной первой версии во вменяемую вторую, реакт уже был вполне production ready. А так они просто для разных задач имхо.

просто для разных задач

Принципальных отличий я не вижу. Дело вкуса.

Чем вызвана такая популярность React?

— Реакт подкупает простотой, его легче изучить, разобраться с нюансами (по крайней мере мне).
— Превосходное комьюнити, например вышло обновление, самому разбираться лень или некогда, через неделю-две выходит огромное количество статей, видео с примерами как его лучше применить на практике.

В Реакте правильные вещи сделать проще, чем неправильные. В частности, Реакт построен на максимальной изолированности частей приложения. Что в практическом плане выливается в то, что джуны не часто и не сильно портят код. Что опять же позволяет выключить компутер и уйти домой без единой тревожной мысли.
В Реакте очень быстро все скатывается к клонированию уже имеющихся решений (см. пункт 1). Скорость разработки возростает, кол-во ошибок уменьшается.
В Реакте есть точка А и точка В. Все, что между ними, может быть приготовлено каким угодно способом — никакие предрассудки архитекторов Гугла никогда не помешают. Из В выйдет ожидаемая величина, в А уйдет тоже ожидаемая. Приложение живет. Возможно, пострадает производительность, но єто другая история, т.к. любой бизнес предпочтет работающее приложение быстрому, но глючному.
Поиск бага (почти всегда — косячные данные) при помощи браузерных консольных утилит — минутное дело. Я не припомню, чтобы у нас было нечто подобное многочасовым поискам в Ангуларе с логированием всего, что только можно.

В Реакте правильные вещи сделать проще, чем неправильные.

на этом Swing погорел — там легко всё испортить,
но и можно сделать круто.

В Реакте правильные вещи сделать проще, чем неправильные. В частности, Реакт построен на максимальной изолированности частей приложения.

Што? Можете навести конкретний приклад на React «максимальной изолированности частей приложения» і порівняти це із прикладом на Angular?

Конкретний приклад: жоден компонет в реакті немає жодного уявлення про оточення та «сервіси». Якщо потрібно використати контекст, це робиться з допомогою «зайвих зусиль» і тими, хто розуміється на HoC, або на контекстах (було старе апі — таке собі, зараз нове — легке, і це не дуже добре). Якщо такого девелопера намає, рішення буде простим, але працюватиме, та нічого не завалить. Тобто мало шансів, що джун перетворить апликацію в дику суміш сервісів, декораторів, та контроллерів.
Я Вам це кажу з 4 річного досвіду з Ангуляром та 2 річного з Реактом.

жоден компонет в реакті немає жодного уявлення про оточення та «сервіси». Якщо потрібно використати контекст, це робиться з допомогою «зайвих зусиль» і тими, хто розуміється на HoC, або на новітніх хуках.

Дайте вгадаю: компонент в React не знає нічого про сервіси й оточення, бо йому видаються вже готові дані. Так? Реальна «кілер-фіча», нічого не скажеш =)... Навіть не уявляю як можна заплутатись у використанні сервісів в компоненті, і як така «неізольованість» негативно впливає на побудову application.

чим більше простині з коду — тим більше вакансій ¯\_(ツ)_/¯

Angular на мелких/средних проектов особого смысла использовать нет, имхо. Плюс с ним в связке сразу идут typescript и rxjs. Первое норм и круто, второе просто круто, но нужно привыкнуть. Некоторых отпугивает. Ну и di. React, заметили ниже, ближе к нативке.

Плюс когда я только начинал учить второй, реакт существенно выигрывал в производительности. Хотя теперь понимаю, что многое зависит от того как готовить.

Angular на мелких/средних проектов особого смысла использовать нет, имхо.

На чистом React проще написать что-то совсем небольшое и никому ненужное. Без DI в реальных проектах не обойтись, если нужно пробросить состояние в различные компоненты. Следовательно к React придется уже прикручивать упомянутый Inversify или иметь дело с контейнерами состояния, что не добавляет простоты.

DI в классическом, интервьюшном виде — зло. Все в пропсах приходит. Свежее и актуальное. Для тестов готовятся моки в любом случае. Вы их в инжектор суете, мы — прямо в require

Angular DI треба пробувати на практиці, а не в теорії.

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

Все в пропсах приходит

В яких пропсах, і що саме приходить?

Для тестов готовятся моки в любом случае. Вы их в инжектор суете, мы — прямо в require

Тобто щоб протестувати конкретний клас, вам треба змінювати файл, де він знаходиться?

Тобто щоб протестувати конкретний клас, вам треба змінювати файл, де він знаходиться?

Реакт ближче до джаваскрипту, ніж Ангулар, де Ви дуже обмежені з тим, що Вам пропонує Гугл.
Ми пишемо:
jest .unmock('react-router-dom') .mock('react-router-dom', () => {...}
якій всередині використовує require таким чином, що замість файлу, як Ви кажете, спрацьовуэ колбек

В яких пропсах, і що саме приходить?

Я мав на увазі те, що для підтримки stateless компонентів, ніякіх ініціализацій в конструкторах. Всіляки «залежності» — це import (див. пункт про require). Все інше — це саме дані, які потрібно відрендерети. Якщо якійсь компонент ззовні вирішіть, він може або відрендерити інший компонент, або відправити відповідні інші дані в пропсах.
Дані визначають структуру, а не структура намагається підлаштуватися під дані.

Якщо якійсь компонент ззовні вирішіть, він може або відрендерити інший компонент, або відправити відповідні інші дані в пропсах.

Іншими словами, якщо у вас є батьківський компонент, в якому є 5 дочірніх компонентів, то у батьківському компоненті ви повинні знати про усі сервіси, необхідні для цих 5 дочірніх компонентів, також ви повинні знати як викликати ці сервіси, хто і від чого має залежності..?

Ще одна «кілер-фіча» від React, тільки так це можна назвати =).

Звичайно, якщо Ви вживаєте тег А, то повинні вказати необхідні атрибути для цього тегу. В дереві реакту все так само. Компонент не зі стелі бере ці «5 компонентів». Батьківські компоненти завжди трошки «розумніші». Якщо внутрішній компонент відправляє якісь команди, батьківський мусить або відправити цю команду до редьюсеру, або змінити свій стейт, або комусь нагору — нехай той компонент розбирається. Це призводить до легкого дебагінгу, та до більшого розуміння архітектури додатку. Погодьтеся, набагато складніше, коли якійсь дуже внутрішній компонент лізе за даними казнакуди, які «хтось десь» йому віддає.

Погодьтеся, набагато складніше, коли якійсь дуже внутрішній компонент лізе за даними казнакуди, які «хтось десь» йому віддає.

«Хтось десь» так можна описувати той «максимально ізольований компонент в React», що нічого не знає про сервіси, не знає про змінні оточення, про що ви тут говорили. В Angular чітко видно в конструкторі які йому сервіси потрібні, що за конфіги він імпортує.

На скільки я пам’ятаю з попередніх наших з вами дискусій, більшість, якщо не увесь, ваш досвід стосується першої версії AngularJS. Його не можна взагалі порівнювати з Angular v2+.

В реакт чётко видно, какие свойства компонент ожидает принять. Какие-то глобальные сервисы это или инлайн функция в шаблоне родительского компонента ему без разницы. Ну, как в html+js элементу button без разницы что попало в onclick свойство, он просто вызовет это значение как функцию, передав в неё аргументом событие.

redux, mobx. Держишь состояние в единственном источнике правды, пробрасываешь что надо и куда надо без проблем.
Если не хочешь пользоваться ими — используй обычные props и пробрасывай сверху вниз

даже несколько выигрывает по возможностям

В этом и проблема. React — это не фреймворк, а просто библиотека для рендеринга. Angular — фреймворк, вместе с которым из коробки идет куча всего: DI, сервисы, и т.д. Они совсем не идентичны.

В случае с React’ом, ты сам решаешь, как строить архитектуру приложения, можешь использовать MobX или Redux для управления состоянием, или вообще управлять состоянием целиком через Apollo (GraphQL). Можешь прикрутить удобный для себя DI, например Inversify.
+ React проще, не нужно учить отдельный синтаксис для рендеринга, достаточно знать JS.

Ну и React Native со своим большим комьюнити.

Они совсем не идентичны.

И там, и там есть компоненты. То что получаешь от Angular из коробки, в React проект нужно добавлять извне. Плюс в Angular есть вещи, аналогов которым просто нет. Я имею в виду директивы, пайпы, ленивую загрузку, роут резольверы

То что получаешь от Angular из коробки, в React проект нужно добавлять извне

Правильно. Потому что React не фреймворк!!111

Если устраивает то, что Angular дает из коробки, или есть острая необходимость использовать что-либо из этого — отлично, используйте на здоровье. Не всем нужен швейцарский нож :)

По поводу аналогов — React Router + React Loadable и роутер с ленивой загрузкой готов. React компоненты отлично работают с асинхронностью через состояние, поэтому резольверы не нужны.

Правильно. Потому что React не фреймворк!!111

а JavaScript не язык программирования :-)))

а ваш комментарий не ложная аналогия ;)

Компоненты реакта — єто и есть директивы ангулара с намного более простым жизненным циклом, биндингом и рендерингом. Мало того — некоторые в свое ангулар приложение вкручивают компоненті реакта именно как директивы. Сам с таким работал.
Но вы в ангуларе не можете все сделать на директивах потому, что єто будет боль, потому что синтаксис деректив калечный, потому что тестировать хуже, потому что там єтот ваш прибабаханый DI, потому что у вас «целый фреймворк» от самого Гугла. И приходится тратить время на весь ангуларовский зоопарк, вместо того, чтобы собрать страничку из одних директив.
Зачем реакту роут резолвер? Запрос данных должен біть явным, а не размазанным по роутам, сервисам, контроллерам и директивам (єто же может біть теоретически? может. Значит, когда-то будет, когда лид не уследит)

Зачем реакту роут резолвер

А что отображать, когда данные не пришли?

та ну, роут резолвер ортогонален fallback view
даже если вместо "когда"(ну, ошибка получения данных) поставить "пока«(ожидание запроса), роут резолвер не снимет с нас необходимости что-то там дизейблить, затенять, показывать прогрессбар

ps для «пока»-варианта уже скоро должна стабилизироваться Suspense/Lazy фича прямо в ядре

Да хоть другой компонент. В реакте и есть рамки и одновременно — полная свобода.

слышал что люди жаловались на брейкинг чейнджи в ангуляр

Ну фактически Angular 2 — это одна breaking change. А потом с этим попроще стало

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