company_banner

Главные причины медленной работы Angular-приложений

Автор оригинала: Giancarlo Buomprisco
  • Перевод
Angular — это быстрый фреймворк. Он даёт разработчикам обширные возможности по улучшению производительности за счёт тонких настроек. Правда, программистам практически никогда не требуется делать что-то особенное для того, чтобы создавать чрезвычайно производительный код, работая над обычными приложениями.

Но оказывается, что в некоторых особенных случаях проблемы с производительностью Angular-приложений всё же могут возникнуть. Во-первых — при разработке приложений, которые должны быть чрезвычайно производительными. Во-вторых — если это приложения, работающие с большими объёмами сложного контента. В-третьих — в приложениях, содержимое которых очень часто обновляется.



По поводу улучшения производительности Angular-приложений написано уже очень много всего. В бесчисленных публикациях даётся масса советов. И хотя большинство из этих советов могут принести пользу тому, кто их применит, автор статьи, перевод которой мы сегодня публикуем, говорит, что те проблемы, с которыми он столкнулся, обсуждаются не особенно часто.

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

Имеют ли значение микрооптимизации?


Опыт подсказывает мне, что микрооптимизации — это тема, которую разработчики очень часто понимают неверно. Когда бы я ни пытался справиться с проблемами, касающимися производительности, многие мои коллеги указывали на код, который мог бы привести к этим проблемам. В качестве методики решения проблем мне предлагали микрооптимизации, которые могли бы помочь сэкономить лишь несколько миллисекунд и не более того.

Вот что мне доводилось слышать:

  • «Мы используем слишком много методов reduce, map и filter. Давайте заменим их все на циклы for!».
  • «Давайте, чтобы увеличить скорость доступа к данным, воспользуемся словарём!».
  • «Нам нужны битовые операторы!».

Я всегда думал, что дело вовсе не в этом.

Но всё вышесказанное, конечно, надо принимать во внимание при разработке высокопроизводительных приложений, фреймворков и библиотек. Первое, что разработчики обычно делают, пытаясь найти причины «тормозов», заключается в анализе производительности функций:

  • «Сколько времени займёт поиск элемента в этом списке [или, может быть, 300 элементов]?».
  • «Как долго будет выполняться сортировка [800 элементов]?».

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

  • Как много информации приложение обычно выводит на экран?
  • Как часто фреймворк выполняет повторный рендеринг компонентов?

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

Приложение слишком часто выполняет операции рендеринга


Начнём с одной весьма распространённой проблемы: приложение без необходимости выполняет повторный рендеринг компонентов, что делает проект медленнее, чем он мог бы быть. Эту проблему несложно решить, но и возникает она тоже без особых «усилий» со стороны разработчика.

▍Изменение способа обнаружения изменений


Установка настройки, отвечающей за стандартный механизм обнаружения изменений, в значение OnPush — это почти обязательный шаг, выполняемый в том случае, если приложение страдает от недостатка производительности, или в ситуации, когда нужно защититься от возникновения проблем с производительностью в будущем.

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

▍Асинхронные пайпы


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

Например, если сделать так, чтобы наблюдаемые объекты не выдавали бы данные без необходимости, это убережёт компоненты от повторного рендеринга. Тут можно воспользоваться такими RxJS-операторами, как filter и distinctUntilChanged для того, чтобы полностью избавиться от операций повторного рендеринга.

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

Если же выбрать весь объект из дерева состояния Redux, то селекторы будут реагировать на каждое изменение дерева. В результате будут вызываться обновления компонентов, которые, на деле, не затронуты этими изменениями.

Это небольшое, как может показаться, изменение позволило мне довести одно из моих приложений в IE 11 от состояния, когда им едва можно было пользоваться, до состояния, когда оно начало показывать довольно хорошую производительность. Вот один из моих материалов, посвящённых RxJS.

▍Обновления, выполняемые слишком часто


Очень частые обновления страниц — это не та область, в которой Angular показывает себя наилучшим образом. Вероятно, дело тут в библиотеке Zone.js, которая, кроме того, лежит в основе автоматического механизма обнаружения изменений Angular.

Zone.js выполняет обезьяньи патчи всех событий и планирует запуск обнаружения изменений на моменты возникновения этих событий. Это означает, что если приложение на высоких скоростях выдаёт в потоковом режиме события (события WebSocket или даже события DOM), то для каждого полученного события Zone.js запустит процесс обнаружения изменений. В подобных случаях перед нами, определённо, открываются возможности для улучшений производительности системы.

Вот мой материал, посвящённый повышению производительности Angular-приложений путём избавления от Zone.js.

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

  • Отключите компоненты, которые обновляются слишком часто, после чего, при поступлении уведомлений от подписок, обновляйте их, обращая внимание на каждую деталь.
  • Используйте ngZone.runOutsideAngular(callback) для вызова коллбэка за пределами системы обнаружения изменений Angular.
  • И последнее средство — исключите события из состава тех, для которых Zone.js создаёт обезьяньи патчи.

Приложение рендерит слишком много компонентов


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

Даже если на вашем Macbook Pro это и не очень заметно, на более медленных машинах подобное может проявиться весьма ярко. Разработчику стоит учитывать то, что не все его пользователи сидят на мощном «железе».

Очень важно так построить приложение, чтобы даже компоненты, выводящие множество элементов (например — компоненты-списки), были определённым образом оптимизированы.

Как решить эту проблему?

▍Использование ключей


Использование ключей — это самая простая и, возможно, самая известная методика ускорения рендеринга списков, которая применяется в большинстве библиотек. В основе этой методики лежит простая идея: мы назначаем каждому элементу списка ключ, а библиотека выполняет повторный рендеринг элемента только в том случае, если его ключ изменился.

Этот подход к оптимизации рендеринга отлично показывает себя при вставке и удалении элементов списков, или тогда, когда число изменённых элементов ограничено. Но он не решает проблем с производительностью в случаях, когда нужно в один момент вывести огромное количество элементов. Например — если мы рендерим очень длинный список при загрузке страницы.

▍Виртуальный скроллинг


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

У этого подхода к оптимизации рендеринга есть особенности, которые нужно учитывать для обеспечения доступности данных и удобства работы с ними. Но это — один из лучших методов улучшения воспринимаемой пользователем производительности страниц. Он помогает избежать «заморозки» страниц на чрезмерно большие периоды времени. Время «заморозки», которое плохо влияет на её восприятие пользователем, меньше, чем можно подумать.

Виртуальный скроллинг весьма легко реализуем. Соответствующие инструкции и инструменты можно найти в документации к Angular CDK.

▍Асинхронный рендеринг


Это — довольно старая методика оптимизации рендеринга, хотя я предпочёл бы ей виртуальный скроллинг. Но это — всё же лучше, чем одновременный рендеринг 1000 элементов. Кроме того, асинхронный рендеринг очень легко реализовать. Для этого не придётся писать больших объёмов кода.

В основе асинхронного рендеринга лежит следующая идея: нужно начать рендеринг ограниченного количества элементов (например, если в списке 500 элементов — начать рендерить 50). Затем надо запланировать рендеринг следующих 50 элементов, используя setTimeout(0). Планировать рендеринг очередных порций элементов нужно до тех пор, пока они все не будут выведены. Это — простая методика оптимизации, но благодаря её использованию браузер не окажется «замороженным» на сотни миллисекунд во время вывода страницы.

▍Ленивый рендеринг


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

Однажды я попал в ситуацию, в которой мне это пригодилось. Я тогда работал над страницей, которая использовала множество экземпляров Quill — знаменитой WYSIWYG-библиотеки.

Quill — это отличный, но довольно «тяжёлый» инструмент. Создание экземпляра одного из его компонентов занимает 20-30 мс, а на странице мне нужны были сотни таких компонентов. Мой Macbook Pro с этой задачей не справился.

Попытка за один заход создать все эти компоненты была довольно-таки глупой затеей. Ключ к решению проблемы заключался в том, что WYSIWYG-область, когда с ней не взаимодействуют, могла бы представлять собой простой фрагмент HTML-разметки. Я мог создать экземпляр компонента тогда, когда он понадобится пользователю, то есть, например, когда на соответствующую область страницы наводили указатель мыши, или тогда, когда по ней щёлкали. После того, как я применил в этом проекте методику ленивого рендеринга, все проблемы с производительностью исчезли.

▍Ленивые прослушиватели событий


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

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

  • Если у вас имеется большой список элементов с обработчиками событий DOM, сделайте так, чтобы подписка на события оформлялась бы только для видимых элементов (тут вам на помощь может прийти виртуальный скроллинг).
  • Иногда лучше создать только одно глобальное событие в пределах сервиса, вместо того, чтобы подписываться на событие в каждой директиве или в каждом компоненте.

Какой-то код… просто может быть медленным


Если вы исследовали приложение и выяснили, что оно не рендерит слишком много компонентов и не обновляет их слишком часто, это значит, что сам ваш код может быть достаточно медленным. Возможно, это связано с какими-нибудь тяжёлыми вычислениями и вообще не имеет отношения к DOM.

Но это — не повод для уныния. Это даже хорошо, так как в наши дни существуют эффективные инструменты для решения подобных проблем:

  • Используйте веб-воркеры. Их, кстати, можно очень быстро создавать с помощью Angular CLI. Когда можно применить такой подход к решению проблемы «тяжёлого» кода? Тут всё очень просто: использовать веб-воркеры стоит тогда, когда код не взаимодействует с DOM, и когда на его выполнение уходит некоторое время. Обычно в таком коде выполняются какие-то расчёты, обработка данных и прочее подобное. Может показаться, что веб-воркеры должны хорошо сочетаться с Redux, но пока ещё время их совместного использования не пришло.
  • Применяйте WebAssembly. Например — посредством AssemblyScript. Подробнее эта идея освещена здесь.

Если эта пара идей вам не нравится, или они просто не способны решить вашу проблему, это значит, что пришло время микрооптимизаций и анализа того, как они могут улучшить производительность системы:

  • Реализуйте собственный IterableDiffer.
  • Избавьтесь от filter, reduce и map, переведите всё на циклы for. В циклах, для уменьшения количества итераций, используйте break и continue.
  • Следите за тем, чтобы ваши объекты имели бы правильную форму. Тут вам будет полезно посмотреть это видео, в котором речь идёт о том, почему Angular так быстр.

Итоги


Мы обсудили различные подходы к ускорению Angular-приложений. Подведём итоги:

  • Отойдите от стандартных настроек фреймворка: применяйте стратегию обнаружения изменений ChangeDetection.OnPush и используйте trackBy при работе с массивами.
  • Постарайтесь, чтобы операции рендеринга выполнялись бы не так часто, как обычно, ответственно подойдя к запуску операций по обнаружению изменений. Если нужно — выполняйте код за пределами воздействия Zone.js.
  • Постарайтесь рендерить меньше компонентов, используя различные подходы, вроде виртуального скроллинга и ленивого рендеринга.
  • Не используйте слишком много прослушивателей событий. Оформляйте подписки только на события видимых элементов, подписывайтесь только на один глобальный прослушиватель событий.

Уважаемые читатели! Как вы ищете и решаете проблемы с производительностью, сталкиваясь с медленной работой Angular-приложений?

RUVDS.com
RUVDS – хостинг VDS/VPS серверов

Комментарии 39

    –3
    после прочтения хочется добавить в итоги — не используйте ангуляр. и будет быстро.
      0
      А вы что предложите? React или vue? Как будто они быстрее работают. Свежие версии показывают примерно одинаковые результаив. Angular — это отличный вариант для больших проектов. React больше подходит для небольших и средних. Vue знаю не очень, но судя по отзывам, максимум для средних средних пооектоа
        0

        А где сравнительные бенчмарки посмотреть можно? Это не наезд, мне правда интересно.

            0
            Любопытная конечно табличка, но не следует забывать что в живых условиях к фреймворку так же будет прилагаться куча сопутствующих либ (а React в этом плане рекордсмен), те же Styled Components чего стоят, в Angular или Vue это уже в комплекте, но не факт, что как-то учтено в этом бенчмарке.
            И от качества ui-библиотеки многое зависит.
        –3
        много занудства
        на момент написания #comment_21225090
        карма было -35
        на момент написания данного комента
        после стала -37
        голосов по href=«https://habr.com/ru/company/ruvds/blog/485642/#comment_21225090»> #comment_21225090
        за 1
        против 4
        получается что из 4 против — двое залезли и проминусовали карму (или ещё хуже — двое мимо проходящих — просто слили карму)
        вот тех кто просто против — я понимаю — мнения могут различаться, но вот тех кто и в карму лезет это уже просто свинство, подлость, затыкание рта, боязнь чужого мнения.
        что я нарушил в том комменте? кого-то обидел?
        или для тупых надо указывать, что это сарказм?
        а если я действительно считаю так и мои проекты не тормозят, потому что я не использую ангуляр и ему подобных? поэтому надо затыкать рот?

        ну давайте минусуйте карму…
        для этого много смелости не надо
        тем более, что и ответить не смогу. благодаря трусливым минусаторам кармы
        Ps
        на момент отправки этого комента голоса изменились. есть согласные и не согласные — это их право. НО! минусаторы кармы г… ы! (по другому не могу их назвать)
          –1
          ну конечно, любители нагадить всегда есть. и обязательно в карму. трусы — самое мягкое название.
          0

          Хочется ответить: https://github.com/kelseyhightower/nocode
          А если серьезно: не умеете использовать инструмент, не используйте. Половина описаных проблем касается не Ангуляра, а клиентской разработки в целом. И Ангуляр, при правильном подходе, вполне себе успешно их решает абсолютно прозрачным для разработчика способом.

          +3
          <режим зануды>а почему на фото тахометр если мы говорим о скорости? :)</режим зануды>
            0
            Я бы добавил про использование структурных директив, они также могут добавить производительности. В стеке с mobx появляются возможности частичного рендеренга компонента. Отпадает необходимость асинхронных пайпов. Computed свойства могут заменить частные пайпы
              0
              есть конкретные данные ускорерия приложения с помощью mobx?
              Просто внутри оно почти так же работает, как асинхронный пайп.
                +1
                На async пайпах тоже можно писать производительный код, но гораздо сложнее — нужно не забывать правильно расставлять операторы distinctUntilChanged и share. Тут более подробное сравнение. Пример на RxJS:
                const displayStream$ = combineLatest(this.nickname$, this.firstname$, this.lastname$)
                  .pipe(
                      map(([nickname, firstname, lastname]) => nickname ? nickname : firstname + " " + lastname),
                      distinctUntilChanged()
                  )
                

                Аналогичный пример на Mobx:

                @computed get displayname() {
                   return this.nickname ? this.nickname : this.firstname + ' ' + this.lastname
                }
                

                Второй пример проще и не требует вручную указывать зависимости вычисляемого значения — зависимости вычисляются автоматически. Mobx запомнит зависимости displayname и пересчитает его тогда, когда вызванные внутри геттера observable значения поменяются. Отвечая на ваш вопрос — на RxJS тоже можно писать код с минимальным количеством ререндеров компонента, но на Mobx это делать проще, так как меньше возможностей ошибиться.
                  0
                  ну это какой-то притянутый за уши (для меня) пример,
                  во-первых вовсе не обязательно собирать весь результат через combineLatest, поток nickname переключает итоговый поток в зависимости от своего значения — это место для switchMap.
                  во-вторых в чистом виде rxjs для состояния не очень, или пишешь свой класс-стейт или берешь готовую Akita, а там уже не нужно «не забывать правильно расставлять операторы distinctUntilChanged и share», все уже сделали за вас.

                  Мне интересен mobx, но пока уже года полтора никак не могу увидеть никаких плюсов для него в Angular. Наоборот, одни минусы, он самовольно модифицирует объекты и вносит лишнюю магию (если бы мне это нравилось, я бы на Vue писал).
                  А вот по поводу производительности никаких данных нет, и сам серьезных бенчмарков я не делал.
                  Правда я ни разу настолько не упирался в производительность, просто пишу на rxjs нормально сразу.

                  Кстати, с Ivy может будет поинтересней, насколько я понимаю сейчас уже можно отказаться от этой директивы angular-mobx и перенести привязку с запуску markForCheck в декоратор на классе компонента.
                    +1
                    Mobx упрощает код и его поддержку. Спавнивая с redux и подобным намного приятнее работать). Минус mobx инициализация, далее все обрабптывается быстро. Rxjs библиотека, которая упрощает работу с ассинхронным кодом, использовать для кправления синхронным потоком не очень
                      0
                      Сравнивая с redux — да, проще.
                      А вот rxjs способен очень на многое, это его фича — универсальность. И асинхронщина, и распространение изменений.
                      0

                      Помучился я с этими mobX и Rx и в итоге написал свою библиотечку. В в ней можно написать вот так:


                      @WithAsync('keyword').Debounce(1000)
                      async static keyWordSearch(getState: ()=> State): Promise<Partial<State>>{
                            const initialState = getState();
                            const items = await initialState.api.request(initialState.keyword);
                            return {items: items};
                      }
                        0
                        честно говоря не очень понятно в чем профит, и читаемость страдает.
                        Смущают промисы и статики.
                          0

                          Промисы — это опционально. Основной режим это, конечно, синхронные изменения.


                          Пример, приведенный выше, выглядел бы вот так:


                          @With('nickname','firstName', 'lastName')
                          static getDispalyName(state: State): Partial<State>{
                                return { dispalyName: state.nickname 
                                            ? state.nickname 
                                            : state.firstname + ' ' + this.lastname };
                          }

                          или


                          @Calc(
                               ['nickname','firstName', 'lastName'], 
                               state=> state.nickname 
                                            ? state.nickname 
                                            : state.firstname + ' ' + this.lastname 
                          )
                          readonly displayName: string = "";

                          "статики" гарантируют, что не будет сайд эффектов

                            0
                            Вы просто любите велосипеды )
                      +1
                      Async пайп по своей сути используется в случаях, когда не хочется реализовывать подписку на observable. Сам факт, что код выглядит проще и красивее, уже лучше. Также, если меняются наблюдаемые свойства, computed перевычислится, что тоже удобно. В случае с rxjs ради маленькой фичи столько кода писать). Честно ужасно(. Чем меньше кода, тем лучше
                  0
                  Раньше причиной медленной работы был flash, а теперь столько разных причин. От того что у юзера не hiend-pc до описанных тут.
                  Обычно медленная работа начинает напрягать когда оборудование не вытягивает, но учитывая что у разработчиков топовое железо, проблема обычно откладывается. Всегда же можно порекомендовать обновить ос, баузер и железо.
                    0
                    Профилировщик ещё не завезли в этот мир?
                      0
                      У меня тут два вопроса без шуток и подоплёк

                      1) Почему даже большие проекты мигрируют с ангуляра на реакт? Но не наоборот…

                      2) Про скорость: Если взять джуна на ангуляре и джуна реактора как вы думаете — какое приложение им написанное будет работать быстрее (при одних и тех же спецификациях и требований конечно)? Про скорость разработки мне ответ известен.

                      Я год работал на реакте и полгода ангулярщик. После введений модных хуков еще больше полюбил реакт. В целом сам ангуляр мне показался тяжелый, как многим по наслышке.
                        +1
                        А есть примеры миграции? И что подразумевается под большими проектами?
                        2 — джуну на ангуляре будет работаться сложнее, angular требует более высокого уровня понимания архитектуры построения приложений. Но все эти сложности дают плюсы в крупных проектах(например DI). Это можно сравнить с управлением автомобиля на механике ). Да и сомнительное дело допускать в работу джуна в крупные проекты ). Тестов не проводил, но меня мучает вопрос производительности VDOM в крупных проектах. Читая документацию react, понимаю что за ширмой огромное количество проверок. Они и могут быть камнем преткновения. В различных статьях пролетали рекомендации не использовать react там, где много drag-and-drop. Когда стоит вопрос создания интернет магазина, то я всеми руками за react. Но если задача стоит создать некий конструктор сайта(как wix), то, как по мне, angular.
                          0
                          Вот пример миграции — habr.com/ru/post/468063
                          По опыту работы над разными Angular проектами скажу, что писать плохо можно на любом фреймворке и Angular тут не лучше React. Да, есть DI, но неопытный разработчик будет инжектить по 9 сервисов в компонент и фреймворк это не запретит. В одном проекте нормальной практикой были раздутые компоненты по 600-700 строк TS + столько же HTML, отсутствие отписок и очень плохая типизация всего. Ангуляр по умолчанию использует максимально щадящий режим TS и позволяет программировать толком без типов. В create-react-app по умолчанию выставлен strict: true, который, по моему опыту, стараются не выключать. Вывод — в долгосрочной перспективе нужно выбирать не фреймворк, а людей.
                            0
                            Ваша ссылка не показывает причин перехода от angular на react. Как выше писал, angular для больших приложений, сомнительное дело давать задачи джуну в таком проекте. Оба не лучше, просто у них своя зона использования.
                            У React используются одни компоненты, а у Angular есть директивы, уменьшающие дублирование кода. DI позволяет подкидывать разные реализации сервисов (web, node.js), в react это будет if..., if..., if… Angular позволяет делить html и код компонента по разным файлам, давая возможность уменьшить код. А в react все в одной куче. По поводу строгости согласен, есть косяк. Вот вышел angular 9, где стало лучше. Думаю вопрос времени сделать идеальный вариант, ограничений не вижу. Программисты важнее согласен, но ограничения движка тоже играют роль.

                              +1
                              Ну вот мы мигрируем. У нас большой и старый (12+ лет местами) проект, ангулярЖС. Мы попробовали уйти на Ангуляр (с беты второго до релиза 7 продержались). Сейчас в итоге переходим на Реакт по многим причинам, главные из которых (сорри, что местами туманно) —

                              1) недостаточно разработчиков на нашем «суммарном» стеке — нам не только ангуляр нужен.

                              2) начиная с версии 6 стало очень неудобно пользоваться сторонним сборщиком. Он у нас сильно большой и сильно хитрый, потому что легаси, и отказаться от него нельзя по разным важным причинам, но в итоге CLI мы использовать не можем никак. С определённого момента ангуляровцы выпилили некоторые возможности API вебпака (я упрощаю) и часть нашего важного функционала сборки стала вообще технически невозможной. Чтоб хоть немного конкретики — например, предобработка исходника скрипта.

                              3) несколько технических и организационных нюансов, в которые я вдаваться не буду, но которые в сумме хорошо так склонили чашу в сторону «не ангуляр».

                              По реальному опыту переходов — с реактом сильно проще и удобнее во многих аспектах. Меньше «энтерпрайза ради энтерпрайза», так сказать, плюс по своей природе реакт позволяет строить из мелких блоков и тонко тюнить процесс. С ангуляром — проще контролировать девелоперов и не давать им натворить совсем уж фигни, что в реакте приходится решать больше организационными мерами.

                              По производительности решения в принципе равны, да и по возможности контроля качества кода я бы не сказал, что кто-то реально побеждает — везде есть нюансы. По личным же предпочтениям… после 7 или около того лет ангуляра я теперь предпочитаю реакт.
                          0
                          Даст ли ускорение переход на ES-2015? Я использую create-react-app, на выходе «старый» js (нет ни «let», ни "=>"). Где бабелям и вебпакам сказать, что я хочу ES-2015? Я бы сравнил и рассказал. У меня в одном прикольном проекте около 40000 кнопок на странице (36000 скрыты, 4000 видны). Заказчик так приказал. Летает и на десктопах, и на смартфонах.
                            0
                            Хотел бы видеть ваш проект ). Заказчик монстр). А если серьезно, и что с того?.. В проекте, в котором участвую, на странице отображается под миллион тэгов, может и больше). И не тормозит, на angular)
                              0
                              Касательно Ангуляра, у него сейчас два бандла формируется, для es5 и es2015. По скорости особой разницы нет, размер es2015 меньше на пару сотен килобайт (в зависимости от объема проекта конечно).
                                0
                                У меня весь проект 260 кб, прикольно будет, если в es2015 останется 60.
                                Если серьезно, то я завидую вашему cli для ангуляра. Может и в create-react-app это можно легко настроить, знать бы как. Спросил у stackoverflow — никто не ответил.
                                  0
                                  cli настолько суров, что я до сих пор толком его не освоил. Писал свои простые схематики, но там столько возможностей что не знаешь с чего подступиться. И документации ко всему этому добру вообще нет, только исходники читать. Я искренне надеюсь что они доведут schematics до ума и сделают киллер фичей.
                                  Можно творить что угодно с кодом при компиляции, можно встроить свою кодогенерацию. А вот человек выше говорил что в вебпак неудобно влезть :)
                                    0
                                    После es2015 у вас будет ~240кб, а не 60. У Xuxicheta, видимо, очень большой проект. Правильнее было бы называть разницу в процентах. Вот какие бандлы генерирует один из моих проектов на Angular 9:

                                    image

                                    Ну и с Ангуляром ваш бандл никогда не будет весить 260кб, вот что показывает анализатор бандла у меня в проекте:

                                    image

                                    Тут из 566кб нужно вычесть 126кб angular/cdk и 8 angular/firebase, итого получаем 432кб.
                                      0
                                      у меня main это 2.2/2.3 мб.
                                      В лейзимодулях разница совсем небольшая меджу бандлами, 5-20кб, но их много, поэтому набежит наверно килобайт 300.
                                      Ну и плюс polyfills дает еще 100кб.
                                      Т.е. в общей сумме худеет примерно на полмегабайта. Это проект на восьмом, на девятку считаю рановато еще, но новый проект начал на девятке.
                              0
                              Когда стоит вопрос создания интернет магазина, то я всеми руками за react.

                              Жесть! Откуда ж эти убеждения у всех беруться?
                              Всегда интересовало, кто и при каких обстоятельствах принимает решение писать интернет магазин как spa..(
                                0
                                ssr). Это лишь был пример уровня сложности приложения, а не конечный выбор. Разумеется в большинстве случаев проще использовать готовые движки, скажем на php. Какой бы выбор не сделать, он должен удовлетворить заказчика)
                                  0
                                  Когда уже знаком с инстументом можно и средний проект быстро накидать. Там и писать то особо нечего, весь бойлерплейт выполняет автоматика, руками пишешь гораздо меньше, чем в реакте.
                                  А если не знаком за тяжелый браться не стоит.
                                    0
                                    Единственное что стоит помнить, react простой в обучении с малым количеством механизмов и их вариации настроек. Новичок быстрее освоит react нежели angular. Один лишь бойлерплейт не поможет)
                                      0
                                      сам реакт — простой, да.
                                      Но его мало для построения приложения.
                                      В экосистеме Реакт хватает раных перлов, типа такого www.type-route.org/docs/guides/page-layout
                                      Пока все оценишь и попробуешь…

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое