Angular vs React

AngularVsReact.md

На случай важных переговоров

[11.01.18 18:47] [Forwarded from Алексей Охрименко]

1. Google, Microsoft
2. Typescript из коробки
3. Единственный вреймворк с Dependency Injection из коробки
4. Не нужно ничего React-ить и AngularJS-ифаить. Больше никаких оберток. jQuery плагины и D3 можно использовать на прямую
5. Более современный фреймворк
6. Большое мягкое и пушистое комьюнити =^.^=

[11.01.18 18:47] [Forwarded from Алексей Охрименко]

1. Выше порог вхождения из-за Observable (RxJs) и Dependency Injeciton
2. Не так много готовых компонентов конкретно под Angular (невелируется jquery и webcomponents)
3. Чтобы все работало хорошо и быстро нужно тратить время (он не супер быстрый по умолчанию - но быстрее AngularJS)
4. Нет архитектуры из коробки - нужно добавлять Redux, MVVM, CQRS/CQS или другой стейт менеджер чтобы потом не сломать себе мозг
5. Angular-Univesal имеет много подводных камней

[03.08.18 10:34] [Forwarded from Иван]

1. на реакте писать больно, слишком много примитивных вещей надо делать руками
2. нет стандартов, все собирают проекты и говна и палок, или из реп с 2-3 звёздами на гитхабе
3. быстрое изучение реакта карается годами заучивания инфраструктуры, которой нет, и которая собирается из говна и палок
4. большая часть реакт проектов направлена на то, чтобы смягчить или исправить косяки самого реакта
5. каждая обезьяна пишет во что горазд и думает что чем больше написать руками - тем пизже, в итоге переход с проекта на проект - это мука

[18.04.19 18:06] [Forwarded from Andrey Listochkin] в эту тему. я ж слава богу умудрялся обходить эту чуму стороной все эти годы. А тут попал в компанию, где таки Реакт. Кода дофига, куча проектов, и я за полгода повидал много всякого:

• реакт с редаксом
• реакт с мобиксом
• реакт с хуками
• реакт с JS
• реакт с TypeScript
• реакт полностью по TDD с энзимом
• реакт без тестов

И с одной стороны, полгода - это немного. С другой - это по 8 часов день за днем неделя за неделей. Я столько всего на нем поделал, и еще больше успел чужого посмотреть.

Так вот. Какой же Реакт херовый 🤦‍♂️

Я уважаю труд тех, кто его пишет, кто пишет к нему куски, тулы и прочее. Но из песен слов не выкинешь.

И при этом объяснить чем именно. Артикулировать свою точку зрения мне тяжело. Поэтому остается что-то в стиле "я загланул на полгодика, сказал Говно, не разобравшись"

Так что я молчу

[09.04.18 09:43] [Forwarded from Георгий]

Я согласен с тем, что Реакт решает многие проблемы. Но он именно библиотека, а Ангуляр это фрейм полноценный, он структурированный и в нем предопределенны многие вещи, которые облегчают разработку, позволяя неявно что-либо включать или определять. Я не говорю что Реакт плохой, просто он подобен либе и на мой взгляд для серьезных проектов лучше юзать ангуляр. Чистое ИМХО

[12.03.18 17:11] [Forwarded from Vladimir Milenko]

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

За ангуляр:

• Мощный роутер
• Работа с CSS гораздо лучше
• Работа с формами проще
• Легкая работа с изменениями, знаем какой инпут изменился, не нужно делать кучу проверок
• Навороченные анимации гораздо проще делать
• JSX - костыль
• Two-way data binding, который можно и не использовать

За реакт:

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

Из плюсов Angular сейчас только DI, но как говорится есть НО - переезд на StaticInjector оборачивается новой болью - раньше можно было инжектить сервисы в зависимости от рута аля /v1-api V1DataService /v2-api V2DataService через один интерфейс DataService - теперь даже это стало болью
А остальное что писали выше

1. Google и экосистема angular/components#5648 2года прошло - до сих пор ждем
2. RxJs - очень удобно для обертки инпутов - очень ужасно для всего остального, особенно когда начинаются какие нибудь Observable который эмитит Observable и это нужно обработать) дебагать такое просто боль
3. Build libs через ng-packagr а старт дев сервера webpackом приводит иногда к неожиданным багам, ну и собственно вообще сборка либ сейчас это боль
4. Динамические элементы( К примеру если нужно будет что то рендерить за пределами вашей либы, то придется конкретно постараться

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

Angular vs React это как сравнивать кривой стул и палку. Да, кривой стул можно сразу использовать - садиться, вставать, ставить на него что-то. Но как бы вы его не улучшали или пытались добавить что-то новое это всегда останется кривой стул. В итоге вам придется его выкинуть или страдать. Причем когда вы выкинете стул все ваши навороты и улучшения тоже придется выкинуть по большей части.

Реакт представляет собой часть стула, которую можно использовать как душе угодно. Подстраивать под пожелания проекта/заказчика. Но если попробовать сесть или встать на эту палку то вас ждет неудача. Более того, никто не обещает, что когда вы соберете свой стул, то он будет лучше или менее кривой чем из примера выше. Скорее всего будет, но вы точно знаете какие части можно заменить без боли. Какие улучшения применить и т.д. В том числе и сам реакт. Можно выкинуть эту одну палку и поставить туда что угодно. По факту любую библиотеку для рендера вью. И в этом основное преимущество реакта и минус ангуляра (лично для меня).

Очень некорректно сравнивать Angular vs React. Они просто решают разные задачи. Ангуляр будет развиваться и возможно и в итоге станет менее кривым. Реакт же просто всегда останется палкой которой можно заткнуть разные места и он просто делает свою работу.

Отдельно скажу, что есть разработчики которые привыкли писать в ООП стили. Другим больше нравиться функциональный стиль. Это нормально, но тогда у вас не остается выбора, тут вступают личные предпочтения которые не имеют ничего общего с качеством/удобством того или иного фреймворка или библиотеки.

Не смог удержаться, хоть по ангулару я и не компетентен (пару недель ковыряния дома и изучения медиазоны), но уже сложилось следующее мнение:

1. Есть паттерны проектирования, при том им стараются следовать
2. Есть нормальный change-detector, который все равно придется руками допиливать для норм перфоманса. Но, как минимум, оно по дефолту не сломается и не начнет перерисовывать все дерево элементов, когда юзер нажмет вон ту кнопочку
3. Зоны и дебаггинг. Nuff said
4. Есть обожемой нормальный CLI
5. Есть френдли комьюнити из суровых ангуларщиков

По реакту за почти три года:

1. Каждый пишет что во что горазд, хотя "на бумажке" те же самые паттерны проектирования есть, но они просто малоприменимы
2. Редакс. Как много уже было сказано об этой недоделке. Кто жалуется на ngrx / vuex тот просто не писал на редаксе, который по умолчанию не способен на stand-alone работу, ему нужно 2000 мидлварей и конфигов, и все это вы будете делать ручками. А еще реселекты и прочие замечательные вещи, чтобы эта хрень не убила ваше приложение.
3. Фейсбук. Фейсбук делает реакт под себя, поэтому однажды вы просыпаетесь и понимаете, что все вокруг ринулись переписывать все на хуки. Никакой backwards compactibility тут и не пахнет, офк, вы либо замораживаете все версии, либо скрепя зубами совокупляете ежа с ужом (как это сделали ребята из mobx-react, и ребенок их в виде v6 получился не очень умным, так сказать)
4. Перфоманс. К сожалению, перформить реакт может только в ОЧЕНЬ ОПРЕДЕЛЕННЫХ условиях о чем уже записана сотня видео на ютубов и сделана сотня выступлений на различного рода конференциях
5. Коммьюнити хайпожоров (ничего личного, но вы видели тот же реакт-чатик в телеграме?)

Отдельно скажу, что Реакт портят ровно две вещи:

• Фейсбук, которые делают его под себя, и чхать они хотели на коммьюнити
• Редакс. Абсолютно продакшн анреди фиговина сделанная на коленке в стиле "эй, чуваки, я Дэн, у меня клевые очки и борода, еще я работаю в Фейсбуке, смарите че сделал вчера после пьянки"
  И если с первым можно мириться (их продукт, все-таки), то редакс достоен смерти и захоронения на биологическом кладбище.

Запасся попкорном 🍿🍿🍿🍿🍿

Забыл прикрепить

https://www.madewithangular.com/categories/angular/

https://railsware.com/blog/react-vs-angular-battle-for-the-front-end/

Angular Platform Ecosystem

Desprit > https://habr.com/ru/post/481100/#comment_21032856
Перешел в новых проектах с Vue на Angular и перевел несколько старых проектов. Поддержка typescript лучше, rxjs — очень мощная и удобная штука когда разберешься. Четкие гайды по структурированию проекта. Разобраться в Vue было значительно проще изначально, но на этом плюсы закончились.
Я все еще очень жду Vue 3 и несомненно буду пробовать.

Больше всего Angular понравился тем что он не ломает HTML. Поэтому переход от легаси стека php/jquery к "что-угодно-API"/angular был для меня гораздо проще чем попытки освоится в Vue и упаси господи в React (который орал на мои шаблоны, валидные для HTML но неприемлемые для вредной JS либы). Так вот, возможность писать обычный HTML/CSS меня очаровала, а когда подразобрался с тонкостями .ts вообще песня пошла...

Больше всего Angular понравился тем что он не ломает HTML.

Нуууу... нельзя просто так взять и создать компонент тега которого не будет в DOM, что создаёт проблемы с тем же бутрапом.

Вообще, после более 2 лет плотной работы казалось бы должно быть "чем больше работаешь, тем проще" (порог вхождения и вот это всё), но всё равно чем сложнее формы в проекте тем больше времени уходит на костыли и гугл. И там вон выше пишут "Google, Microsoft", так вот, это скорее плохо чем хорошо - проект спонсирует вне зависимости от его кривости - тот же ivy пилили 2 года, по сути полностью забив на все остальные проблемы (которых уже ~2900), оно конечно нужно (но не жизненно необходимо), но со стороны разработчика, которому нужно выполнять задачи для бизнеса, хотелось бы немного другого. Например, хотелось бы чтобы те вещи что должны быть из коробки, не приходилось реализовывать самостоятельно с помощью различных костылей:

• Хочешь обернуть контрол в кастомный компонент? Пососи в смысле, будь добр реализуй враппер самостоятельно. Реализовал? Круто, а про touched не забыл? А мы забыли.... (последнее из совсем свежего так сказать https://habr.com/ru/post/481424/#comment_21084232).
• Вывести в форме ошибки с бекенда? Бгггг. Забудь. Особенно если форма многоуровневая с кастомными контролами.
• Несколько ущербный di что рождает баги подобные angular/angular#26273
• Material отдельная головная боль, которая сразу умножает все проблемы на 2 (чего только стоит невозможность использовать NG_VALUE_ACCESSOR вместе с MatFormFieldControl, но это ладно, а слабо добавить еще и NG_VALIDATORS? ...)
• etc etc etc

Хочешь обернуть контрол в кастомный компонент? Пососи в смысле, будь добр реализуй враппер самостоятельно. Реализовал? Круто, а про touched не забыл? А мы забыли.... (последнее из совсем свежего так сказать https://habr.com/ru/post/481424/#comment_21084232).

Ну сложно забыть это если готовить его правильно, ведь в интерфейсе он обязателен

export interface ControlValueAccessor {
 registerOnTouched(fn: any): void;

• https://blog.thoughtram.io/angular/2016/07/27/custom-form-controls-in-angular-2.html
  и это же в переводе: https://medium.com/@maks.zhitlov/custom-form-controls-in-angular-4c69a94d5de6
• для материала https://material.angular.io/guide/creating-a-custom-form-field-control
• ну и вроде известная проблема: angular/angular#26273 и там есть объяснение почему так.
• ну наверно еще про это нужно: https://stackoverflow.com/questions/44730711/how-do-i-know-when-custom-form-control-is-marked-as-pristine-in-angular
• еще как вариант статейка https://blog.angulartraining.com/tutorial-custom-form-controls-with-angular-22fc31c8c4cc

Вывести в форме ошибки с бекенда? Бгггг. Забудь. Особенно если форма многоуровневая с кастомными контролами.

• скорее всего вы знаете про async validators, возможно и этого хватит
• из control.errors всегда можно забрать то что в него вы засунете, и тут нет разницы с многоуровневая ли она или простая, главное как вы организовали структуру вашего проекта, ну а это уже далеко за рамками Angular.

Material отдельная головная боль, которая сразу умножает все проблемы на 2 (чего только стоит невозможность использовать NG_VALUE_ACCESSOR вместе с MatFormFieldControl, но это ладно, а слабо добавить еще и NG_VALIDATORS? ...)

Наверно вопрос про это: angular/components#8158

в целом вопрос скорее про сам MatFormFieldControl, не все компоненты могут уметь mat-form-field, скорее конкретно проблема в этом, и компоненты не могут заточены под один механизм. Но в целом согласен что в angular material хватает не очевидных вещей, которые кстати хорошо описаны в самих исходниках

etc etc etc

всегда можно пойти в чатик за ответами https://t.me/angular_ru

там есть объяснение почему так.

Нету там. Реальная проблема в том что нет возможности указать контекст для <ng-content>, поэтому он всегда вызывается в том контексте где был объявлен, а не в том где вызван.

Ну сложно забыть это если готовить его правильно, ведь в интерфейсе он обязателен

А вы комментарий по ссылке читали? :) Проблема не "ребенок -> родитель", а в обратном направлении "родитель -> ребенок". Оно сейчас решается только через DoCheck.

скорее всего вы

Вот вы попробуйте сделайте что-то типа:

• FormGroup
  • FromControl
  • ContolValueAccessor (реальный пример когда это нужно: в зависимости от чекбокса значение может быть или null или {...})
    • FormGroup
      • FormControl 1
      • FormControl 2

И обломаетесь, потому что вызов FormGroup.setErrors() (после вызова бэкенда) нифига не передаст ошибки внутрь, кастомные валидаторы тут тоже ничем не помогут (async разве что, но дергать бэкенд для каждого поля это немного .... мммм .... странно) - костыли наше всё ("Monkey-patching the markAsPristine()" прекрасный пример)... Это ведь простейшая ситуация по сути, почему я должен реализовывать это всё руками? А еще приколов хотите?

1. Кастомные ошибки установленные через FormControl.setErrors() живут до первой валидации - если где-то там внутри кто-то дернет onValidatorChange то оно всё похерится, отлаживать это всё очень здорово (сарказм).
2. Если сделаете FormControl.setErrors({...}) то FormControl.parent.errors будет пустым

Поэтому делать сколь нибудь сложные формы это, к сожалению, реально больно :(

Можно кстати еще упоминуть про роутер, который, например, по дефолту из коробки с 2016 года (!) некорректно обрабатывает + - angular/angular#11058 ... Да, оно решаемо, но блин... У меня просто накипело (уже неделю пытаюсь заставить работать форму...), не знаю как там в реакте или vue, ибо перешел с angular js (там не было столько проблем), но делать новые проекты на текущей версии angular-а желания совсем не испытываю. Надеюсь что после релиза ivy они наконец займутся реальными проблемами.

А вы комментарий по ссылке читали? :) Проблема не "ребенок -> родитель", а в обратном направлении "родитель -> ребенок". Оно сейчас решается только через DoCheck.

Почитал коммент, я думаю вы полагали что будет все автоматом, но здесь как раз это не бага а фича, ввиду того что этот компонент может и вовсе не быть каким мы его ожидали, действительным ControlValueAccessor, поэтому для сложных случаев сложная реализация. И это правильно что нужна в DoCheck, даже взять тот же Select материаловский, https://github.com/angular/components/blob/master/src/material/select/select.ts#L572

И кстати вместо Input control можно просто заюзать:
@Self() @Optional() private control: NgControl
а там и ссылка на parent если что есть.

Вот вы попробуйте сделайте что-то типа:

По моему тут подменяются понятия, между состоянием контролов и настоящим состоянием валидности, тогда как реально состояние вычисляется на бэкенде. Я бы возможно отделил 2 разных этих понятия и для каждой группы перевалидировал его каждый раз когда состояние валидности поменялось, и отбросить предыдущее состояние, потому как оно в действительности не имеет отношения к текущим данным. Думаю нужно отноститься так данные формы !== текущее состояние. С таким примерно подходом работает ngrx-forms , где формы пляшут от стейта.

Возможно это попытка передать всю ответственность ангуляр формам, но не бывает так чтобы вот на все случаи жизни, как говориться PR welcome.

Можно кстати еще упоминуть про роутер,

Ну тут как оно есть, да. Важно помнить что текущая реализация роутера - это то что предложило сообщество, а не core team. А именно про конкретную проблему - хз, можно было бы под флаг на краиний случай, но так как это не критичный функционал, за него и не берутся.

Почитал коммент, я думаю вы полагали что будет все автоматом

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

@self() @optional() private control: NgControl

Лучше так не делать, оно даёт cyclic dependency при использовании с provide: NG_VALUE_ACCESSOR/NG_VALIDATORS, и если NG_VALUE_ACCESSOR решаемо через явное присвоение (this.ngControl.valueAccessor = this;), то NG_VALIDATORS уже нет, потому что нормально добавить валидатор в компонент нельзя, да и validate() для кастомных контролов почти всегда удобнее. Наговнокодить конечно можно, но потом это еще и поддерживать придется... В данный момент самая нормальная реализиция, имхо, это

с использовование proxy директивы

// Вся фишка в этом куске - если не нужен ngControl то и проблем с cyclic dependency нету
export type FormFieldControl = Omit<MatFormFieldControl<any>, 'ngControl' | 'errorState'>;

@Injectable()
export abstract class FormFieldControlImpl<V> implements ControlValueAccessor, FormFieldControl {
    // сюда пихаем реализацию
}

@Directive({
    selector:  '[appFormFieldControl]',
    exportAs:  'appFormFieldControl',
    providers: [
        {
            provide:     MatFormFieldControl,
            useExisting: FormFieldControlDirective,
        },
    ],
})
export class FormFieldControlDirective<V> extends MatInputMixinBase implements MatFormFieldControl<V | null>, OnInit, DoCheck {
    // тут просто проксируем все вызовы на FormFieldControlImpl не зыбывая 
    // подписаться на его `stateChanges` и поставить костыль для `updateErrorState()` 
    // в `DoCheck`
}

// Теперь можно обойтись без костылей ^_^
@Component({
    selector:        'app-control-custom',
    templateUrl:     './control-custom.component.html',
    changeDetection: ChangeDetectionStrategy.OnPush,
    providers:       [
        {
            provide:     NG_VALUE_ACCESSOR,
            useExisting: CustomControlComponent,
            multi:       true,
        },
        {
            provide:     NG_VALIDATORS,
            useExisting: CustomControlComponent,
            multi:       true,
        },
        {
            provide:     FormFieldControlImpl,
            useExisting: CustomControlComponent,
        },
    ],
})
export class CustomControlComponent extends FormFieldControlImpl<CustomValue> {
    // реализовываем то что надо
}

<app-control-custom appFormFieldControl [formControl]="form.get('custom')"></app-control-custom>

однако, как всегда в ангуляре, есть ложка говна: добавить к компоненту директиву в самом компоненте нельзя, поэтому придется везде добавлять её явно, но плюсы подхода перевешивают. Почему этого нет в документации? 🤷‍♂️

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

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

Важно помнить что текущая реализация роутера - это то что предложило сообщество, а не core team

Предыдущая вроде была еще более ущербной)

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

Это понятно, и моя притензия скорее в том что за ширмой распиаренного framework-а слишком много концептуальных проблем , которые никто не хочет исправлять и которые постоянно вылазят в процессе разработки и из-за которых что-то прогнозировать (по срокам) крайне сложно, потомучто всегда можно найти новые грабли и потратить пару-тройку дней на их подскостылевание.

DoCheck это костыль, по хорошему его не должно быть.

Как и OnPush стратегии собственно, всё же должен фреймворк решить?)

Это понятно, и моя притензия скорее в том что за ширмой распиаренного framework-а слишком много

Ну тут уже ближе к рассуждению про "идеальный" фреймворк. С такими не очевидными, как мне кажется, проблемами я сталкиваюсь очень редко. Предлагаю вам создать gist с проблемами которыми столкнулись и как его решили/ не решили. Ну и соответственно обсудим там является ли это проблемой фреймворка или проблемой пользователя :)

И возможно перенесем всю ветку общения туда, потому как это уже давно вышло за рамки Angular Vs React

Как и OnPush стратегии собственно, всё же должен фреймворк решить?

Он должен предоставить удобный способ работы со всем этим, а сейчас есть OnPush, но, например, нет (нормального) способа обновить все дочерние компоненты принудительно. Есть ControlValueAccessor, но коммуникация "родитель -> ребенок" невозможна. И вот так тут везде, вроде есть, но не полноценно.

Предлагаю вам создать gist с проблемами которыми столкнулись и как его решили/ не решили.

Не, времени нету, да и оно обычно гуглиться вместе с решениями костылями для исправления, поэтому по сути бессмысленно, ну и вон ссылка на репо есть - там прямо списку почти всё довольно актуально (а про формы вообще большая таска).

И возможно перенесем всю ветку общения туда, потому как это уже давно вышло за рамки Angular Vs React

Да, есть немного, в целом мои комменты можно удалить, оставив первый комментарий и про "ширму распиаренного framework-а")

Пока отходил такое началось :)

Нуууу... нельзя просто так взять и создать компонент тега которого не будет в DOM

Наверное потому что каждому по потребностям. У меня ни разу не возникало желания написать что-то чего нет в DOM. Я понимаю о чем вы и понимаю что у кого-то может возникнуть такая задача, но вот за плечами два сложных проекта для логистов на angular и там этого не требовалось.

что создаёт проблемы с тем же бутрапом.

Опять же использовал его всего пару раз в жизни, когда только начинал работать. После этого переключился UI фреймворки типа UIkit, у него тоже не было подобных проблем c angular. Конечно, опять же, я понимаю что большинство других разработчиков использует бутстрап. Мой восторг повторюсь основан только на том, что я взял index.html и style.css от пет проджекта, перенес в компонент на angular, запустил и оно просто заработало. Получился бы такой копипаст с JSX?

2020 год на дворе а реакт до сих пор взрывает пуканы.
Ничего не имею против реакта но программирование на нем оставляет только боль для меня.
Проекты обмазаны хуками, редаксами и прочими штуками которые превращают написание UI в написание бойлерплейта, коннекторы под редакс, саги, санки. В итоге когда ты все таки доделал фичу то уже не в состоянии точно сказать как это работает, от клика до отображения. Те библиотеки которые обещают сделать программирование на реакте простым и прозрачным делают только хуже например редакс. Тот же vuex после редакса кажется раем на земле. И без этих ваших санков и саг. Я хочу делать UI а не писать код ради кода.

реакт хорош, миллионы мух не могут ошибаться, садясь на него ежедневно

Владимир Большаков

Почему я выбрал Angular и не собираюсь от него отказываться

https://bolshakov.vladimir.ru/016-why-i-selected-angular

16.02.2022 Andrew:
А вообще

• самый важный пункт: наличие классических способов сделать одни и те же вещи (а-ля как в питоне, в противовес реактам вашим). все их делают одинаково, оттого всегда есть:
• отличная документация + гайды + куча стартер-паков и боилерплейтов даже чисто в качестве объяснения каких-то вещей
• поддержка комьюнити и мейнтейнеров
• вижен дальнейшего развития фреймворка
• официальный тулинг для разных классчических целей
• тайпскрипт из коробки, как следствие он всегда есть во всех зависимостях
• нормальная инкапсуляция, без протягивания всё через пропсы всех компонентов. в реакте это тоже антипаттерн канеш, но оч многие почему-то до сих пор не знают про хуки. инкапсуляция включает разделение по типам файлов, что лично мне оч нравится. отдельно вьюшка, отдельно стили, отдельно модуль для модуль федерейшена, отдельно логика. плюс ты контролируешь, насколько твой компонент реагирует на окружающую среду.
• rxjs. блин, стримы и есть стримы, хз чё тут объяснять.
• DI. сконфигурить можно вообще всё и влезть на любой шаг, если малясь почитать сорцы или доки.

главный минус - порог входа. много новых концепций. как следствие - количество народа на рынке, кто пройдёт собес крайне мало. а среди них ещё адеватных людей отбирать приходится.

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

@irustm, как смержить значения двух multi: true токенов из разных модулей? 🙄

Why I’ve Switched from React to Angular for My Projects
Alex Seifert

https://medium.com/@alexseifert/why-ive-switched-from-react-to-angular-for-my-projects-9838144f3732

Брал паузу от фронтенда на некоторое время (пилил бекэнд и пару директив поиска/сортировки для laravel и lighthouse). Сейчас вернулся и вижу что у Angular все чуть лучше стало:

0. (давно уже) можно использовать protected для полей внутри шаблона (т.е. теперь они не будут торчать наружу)
1. новый синтаксис (оно же control flow), тот же empty для циклов прям топчик
2. дефолтный шаблон для ng-content (angular/angular#12530 ¹)
3. standalone компоненты (больше не нужно распихивать их по модулям, да и сами модули по сути не нужны)
4. больше событий для форм (angular/angular#10887 ¹; надеюсь упростит жизнь)
5. сигналы (местами лучше чем то что было, в будущем похоже позволят отказаться и от zone.js и от onpush)

Why I’ve Switched from React to Angular for My Projects

Кмк, совершенно ни о чем (да сервис вовсе не обязан быть singleton-ом).

Footnotes

1. возможно еще не релизнуто ↩ ↩²