born_to_surf9 июн 2015 в 15:52

Так ли быстр ReactJS?

3 мин

36K

Angular * ReactJS *

Из песочницы

+25

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

dangreen 9 июн 2015 в 16:17

В оригинальной статье можно найти ссылку на фреймворк jsblocks. Было бы интересно узнать чем он так быстрее реакта у ангуляра. Так же jsblocks имеет библиотеку которая быстрее underscore'а, здесь тоже интересно узнать в чем причина.

youlose 9 июн 2015 в 18:23

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

dangreen 9 июн 2015 в 18:27

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

youlose 10 июн 2015 в 04:56

Ну отпрофилировать эти тесты надо и всё.

nuit 10 июн 2015 в 07:17

Если jsblock'овые тесты запустить на IE, реакт должен выиграть ;)

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

scalavod 10 июн 2015 в 15:20

В этом треде автор jsblocks рассказывает за счёт чего происходит прирост в скорости по сравнению с lodash/underscore.

dangreen 10 июн 2015 в 15:21

Спасибо!

AlexeyFrolov 9 июн 2015 в 17:52

«Скандалы, интриги, расследования — показать всё, что скрыто» lol

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

vitvad 9 июн 2015 в 19:23

из-за этих жалких миллисекунд и появляются фреймворки с виртуальным DOM.

>людям, которые во всю юзают Реакт не до холеваров.
конечно нет, им нужно поддерживать мешанину HTML внутри JS

zw0rk 9 июн 2015 в 19:29

> конечно нет, им нужно поддерживать мешанину HTML внутри JS

Но это же не правда.

Apx 9 июн 2015 в 21:09

Ну если взглянуть на get started на сайте реакта, то именно html внутри js и виден :)
В этом плане подход ангуляра проще, поскольку он работает внутри самой html страницы из коробки. И если чисто теоретически какой-то умный человек отключит js то хотя бы на странице останется хоть что-то из html, что будет показано.

grossws 9 июн 2015 в 21:24

Ну если взглянуть на get started на сайте реакта, то именно html внутри js и виден :)

В jsx, строго говоря, никакого html нету. Этот syntaxic sugar транслируется в js (React.createElement(...)), что объясняется, в том числе, и в tutorial'е.

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

Только каркас, без контента. В случае реакта будет то же самое, т. к. он встраивается в существующий каркас (при использовании React.render(...).

Apx 9 июн 2015 в 21:44

Ну JSX опять же таки javascript. Да и под него ещё и скрипт надо тянуть отдельный сверху. Но это скажем так скорее вопрос кто как любит склеивать библиотеки, кто-то всё в кучу кто-то отдельно. А синтаксический цукерман почти у всех схож))

grossws 9 июн 2015 в 21:56

Напомню, вы написали, что

именно html внутри js и виден

Как это коррелирует с

Ну JSX опять же таки javascript.

мне не очень понятно.

Да и под него ещё и скрипт надо тянуть отдельный сверху.

Можно его преобразовывать jsx в js на сервере, можно на клиенте (тогда подключаются скрипт-транслятор и text/jsx), можно сразу писать js, без использования jsx. Эти три варианта эквивалентны.

Benjaminabel 9 июн 2015 в 21:05

Читал статью в оригинале. «Шо то отличный фреймворк, шо это отличный фреймворк». Но, как мне кажется, Angular с лёгкостью выигрывает в удобстве использования в рамках как и больших, так и малых приложений. Интереснее было бы сравнение с Polymer, так как он уже намного больше похож на React.

Apx 9 июн 2015 в 21:39

Ну полимер это как бы всё же «чисто» веб компоненты. Никакого больше волшебства фреймворка в нём не происходит. Ангуляр предоставляет больше в данном случае. Сравнивать скорее надо polymer и директивы ангуляра, но опять таки одним лёгким движением руки директива попадает под полный digest cycle агуляра в большинстве случаев, и жить отдельно без него просто не в состоянии. Так что тоже сравнение с трамвайной ручкой получается.

serf 10 июн 2015 в 04:19

в 2.0 обсерверы используются, digest loop уже не проблема

zw0rk 10 июн 2015 в 00:23

В моём проекте ангуляр с лёгкостью проиграл реакту еще на стадии прототипирования.

KIVagant 10 июн 2015 в 21:53

Вброс засчитан. Чем проиграл?

zw0rk 10 июн 2015 в 23:16

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

p.s. К тому же, у нас cljs и om был естественным решением :)

serf 10 июн 2015 в 04:12

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

sferrka 10 июн 2015 в 04:52

React нужен не для скорости, он нужен из-за компонентов. А вот HTML — пережиток прошлого, когда большая часть интерфейса была простым текстом, сейчас же гораздо больше активных элементов на странице, а данные изменяются локально, а не при перезагрузке страницы. Именно поэтому рождаются web-компоненты, именно поэтому Angular 2.0 их содержит. Поэтому шаблоны Angular содержат JS и различные байндинги, отсюда идея JSX (по сути, отказ от HTML). Да, JS тоже слабо подходит в качестве языка разметки, но зато в нем уже есть объекты ({{user.name}}), вызовы функций, математические, логические операции и т.д., которые давно используются во всех шаблонизаторах (т.е. по сути сообщество признало эти вещи декларативными).
Возможно, когда (или если) HTML разовьется в более полноценный язык разметки интерфейса, с поддержкой наследования, привязки данных и др., JS для этого станет не нужен, но может быть появится и что-то новое, как JSX, только без смешения парадигм и языков.

serf 10 июн 2015 в 05:14

> JSX (по сути, отказ от HTML)
Повеселили, по сути наоборот наоборот, возврат к спагетти коду (разметка html в коде, php style фейсбук ведь). Тогда уже и древние фреймворки называйте компонентными, там обычно уйма готовы виджетов (подобие компонентов).

Aetet 10 июн 2015 в 06:43

Хотите готовые компоненты вам сюда:
react-components.com

Подскажите мне, пожалуйста, почему разметка в html-коде это плохо? Вот только не надо заливать про разделение ответственности. html-код в jsx это шаблоны, которые динамически изменяются в зависимости от поданных переменных. По сути каждый реактовый виджет это просто чистая функция, которой на вход подаешь данные, она тебе возвращает верстку. Так почему это плохо? Почему

<div>{{name}}</div>

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

serf 10 июн 2015 в 06:46

> Подскажите мне, пожалуйста, почему разметка в html-коде это плохо?

Как раз разметка в html коде это не плохо, но там смесь JS и HTML (этот ваш jsx).

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

wheercool 10 июн 2015 в 07:24

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

Можно подумать, что ангуляр пуп земли.
Обычно такое высказывание свидетельствует об ограниченном кругозоре и скорее знакомство автора с reactJs свелось к беглому просмотру примеров на главной странице

serf 10 июн 2015 в 07:27

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

tenbits 10 июн 2015 в 19:45

Я, например, уже давно html не использую. MaskJS имеет более лаконичный синтаксис, поддерживает декларацию компонент, наследование, merge шаблонов, модули — импорт/экспорт компонент, scope компонент; загрузка данных, скриптов и стилей; друсторонний байндиг, и много всего другого.

vintage 10 июн 2015 в 06:23

Быстрый фреймворк — не тот, на котором можно сделать быстро, а тот, на котором нельзя сделать медленно :-)
Тут же я вижу описание костылей, которые нужно вставить, чтобы хотя бы догнать реакт.
Пример с таймаутом я так и не понял. В чём отличие первого кода от второго? Каким образом ручная реализация поведения $timeout поможет увеличить скорость?

andrewiWD 10 июн 2015 в 06:54

Быстрый фреймворк — не тот, на котором можно сделать быстро, а тот, на котором нельзя сделать медленно :-)

Медленно можно сделать не только на любом фреймворке, но и на любом языке программирования.

Тут же я вижу описание костылей, которые нужно вставить, чтобы хотя бы догнать реакт.

Т.е. продуманное и правильное написание кода, вы считаете костылями? С каких пор добавление индекса — костыль?!

Пример с таймаутом я так и не понял. В чём отличие первого кода от второго? Каким образом ручная реализация поведения $timeout поможет увеличить скорость?

Тут в $digest() фишка. В данном случае биндинг не нужен.

vintage 10 июн 2015 в 08:12

Вопрос в том, насколько сложно сделать медленно :-)

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

Где тут биндинг? $timeout всё, что делает — это вызывает отложенно функцию и запускает после этого $digest

born_to_surf 10 июн 2015 в 11:21

Тут фишка в том, что $timeout по умолчанию вызывает $apply, который в свою очередь вызывает $digest для рутового скоупа, что приводит к пересчету всех ячеек

В представленной демо, функция $timeout вызывается для каждой ячейки, поэтому достаточно вызвать $digest только для текущего скоупа

vintage 10 июн 2015 в 11:30

Теперь ясно. Костыль же :-)

youlose 10 июн 2015 в 13:34

Сделать медленно можно без проблем НА ЛЮБОЙ технологии, если знаете где это не так, буду благодарен узнать.

vintage 10 июн 2015 в 13:50

Ок, раз вы всё так буквально понимаете, ответьте, пожалуйста, на пару вопросов:
1. Как нужно поправить код на реакте, чтобы он стал столь же медленным, что и ангуляр без костылей?
2. Зачем может потребовать делать именно так?

TedBeer 10 июн 2015 в 18:37

У меня были подозрения на то, что прелести реакт преувеличены. Было лень копаться, пока не назрело и всегда получалось простым анализом кода улучшить производительность приложения на ангулар до нужного уровня.
Я вижу здравое зерно в идее виртуального дома — тяжелые операции можно производить используя workers, т.е. паралельно основному потоку. Но насколько эта идея работает надо проверять.

zw0rk 10 июн 2015 в 21:31

Прелести реакта совсем не в скорости работы скриптов, а в простоте концепции — они не зря всё время цитату Дийкстры про таймлайн приводят, выстрадали.

nomn 11 июн 2015 в 13:58

Начало статьи похоже на рекламу вроде «Шок! Всего 2 капли этого и....»

zim32 12 июн 2015 в 22:24

Правильно ли я понимаю что Ember со своими очередями и отложенным обновлением DOM это почти то же что и diff в реакте? Может кто-то растолковать?

nuit 13 июн 2015 в 04:06

главное преимущество diff/patch'а в том что не нужно реализовывать никакого шаблонизатора и при этом получить immediate mode api с возможностью сохранять внутреннее состояние.

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

zim32 13 июн 2015 в 09:04

Ну реакт это сам по себе один сплошной шаблонизатор )

e_asphyx 12 ноя 2015 в 14:02

По поводу «следующего проекта»: а куда в таком случае смотреть после backbone и голого jquery?

Artemis4You 21 янв 2016 в 14:45

setTimeout(function() {
    $scope.status.isSearching = false;
    $scope.status.searchResults = ...
    $scope.$digest();
    .......

Серьезно?

Я этот спиппет буду скидывать народу, когда будут говорить о «простоте» ангуляра.
Да Реакт можно полюбить только за то что не приходиться писать такие магические вещи в коде, которые нигде не описаны. Лично у меня сразу возникло 100 вопросов в духе, а почему именно setTimeout а не $timeout и почему там должен быть $digest и почему он в setTimeout

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий