Pull to refresh

Comments 39

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

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

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

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

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

<режим зануды>а почему на фото тахометр если мы говорим о скорости? :)</режим зануды>
Я бы добавил про использование структурных директив, они также могут добавить производительности. В стеке с mobx появляются возможности частичного рендеренга компонента. Отпадает необходимость асинхронных пайпов. Computed свойства могут заменить частные пайпы
есть конкретные данные ускорерия приложения с помощью mobx?
Просто внутри оно почти так же работает, как асинхронный пайп.
На 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 это делать проще, так как меньше возможностей ошибиться.
ну это какой-то притянутый за уши (для меня) пример,
во-первых вовсе не обязательно собирать весь результат через combineLatest, поток nickname переключает итоговый поток в зависимости от своего значения — это место для switchMap.
во-вторых в чистом виде rxjs для состояния не очень, или пишешь свой класс-стейт или берешь готовую Akita, а там уже не нужно «не забывать правильно расставлять операторы distinctUntilChanged и share», все уже сделали за вас.

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

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

Помучился я с этими 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};
}
честно говоря не очень понятно в чем профит, и читаемость страдает.
Смущают промисы и статики.

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


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


@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 = "";

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

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

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

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

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

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

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

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

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

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

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

image

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

image

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

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