Комментарии 43
В оригинальной статье можно найти ссылку на фреймворк jsblocks. Было бы интересно узнать чем он так быстрее реакта у ангуляра. Так же jsblocks имеет библиотеку которая быстрее underscore'а, здесь тоже интересно узнать в чем причина.
Как ни странно, чем меньше функционала и «синтаксического сахара», тем быстрее работают различные фреймворки или языки программирования, так что причина вполне очевидна.
Это безусловно так. Но все же… хотелось бы на примере увидеть в чем заключается такой прирост. Может из-за того что в реакте используется своя реализация классов, что замедляет работу кода, может из-за еще чего то… не хочется гадать, хочется знать наверняка.
Ну отпрофилировать эти тесты надо и всё.
Если jsblock'овые тесты запустить на IE, реакт должен выиграть ;)
Вообще очень сложно сравнивать производительность различных подходов для датабайндинга, как например реакт и ангулар. Зная о том как внутри устроены оба фрэймворка, можно с лёгкостью сделать тест кэйсы на которых один фрэймворк будет очень сильно отставать по производительности от другого и наоборот.
Вообще очень сложно сравнивать производительность различных подходов для датабайндинга, как например реакт и ангулар. Зная о том как внутри устроены оба фрэймворка, можно с лёгкостью сделать тест кэйсы на которых один фрэймворк будет очень сильно отставать по производительности от другого и наоборот.
В этом треде автор jsblocks рассказывает за счёт чего происходит прирост в скорости по сравнению с lodash/underscore.
«Скандалы, интриги, расследования — показать всё, что скрыто» lol
Ну сколько можно уже мотаться с этой статьей? Не думаю, что неоспоримые преимущества перебиваются этими жалкими миллисекундами, если даже не брать в рассчет, что людям, которые во всю юзают Реакт не до холеваров.
Ну сколько можно уже мотаться с этой статьей? Не думаю, что неоспоримые преимущества перебиваются этими жалкими миллисекундами, если даже не брать в рассчет, что людям, которые во всю юзают Реакт не до холеваров.
из-за этих жалких миллисекунд и появляются фреймворки с виртуальным DOM.
>людям, которые во всю юзают Реакт не до холеваров.
конечно нет, им нужно поддерживать мешанину HTML внутри JS
>людям, которые во всю юзают Реакт не до холеваров.
конечно нет, им нужно поддерживать мешанину HTML внутри JS
> конечно нет, им нужно поддерживать мешанину HTML внутри JS
Но это же не правда.
Но это же не правда.
Ну если взглянуть на get started на сайте реакта, то именно html внутри js и виден :)
В этом плане подход ангуляра проще, поскольку он работает внутри самой html страницы из коробки. И если чисто теоретически какой-то умный человек отключит js то хотя бы на странице останется хоть что-то из html, что будет показано.
В этом плане подход ангуляра проще, поскольку он работает внутри самой html страницы из коробки. И если чисто теоретически какой-то умный человек отключит js то хотя бы на странице останется хоть что-то из html, что будет показано.
Ну если взглянуть на get started на сайте реакта, то именно html внутри js и виден :)В jsx, строго говоря, никакого html нету. Этот syntaxic sugar транслируется в js (
React.createElement(...)), что объясняется, в том числе, и в tutorial'е.В этом плане подход ангуляра проще, поскольку он работает внутри самой html страницы из коробки. И если чисто теоретически какой-то умный человек отключит js то хотя бы на странице останется хоть что-то из html, что будет показано.Только каркас, без контента. В случае реакта будет то же самое, т. к. он встраивается в существующий каркас (при использовании
React.render(...).Ну JSX опять же таки javascript. Да и под него ещё и скрипт надо тянуть отдельный сверху. Но это скажем так скорее вопрос кто как любит склеивать библиотеки, кто-то всё в кучу кто-то отдельно. А синтаксический цукерман почти у всех схож))
Напомню, вы написали, что
именно html внутри js и виденКак это коррелирует с
Ну JSX опять же таки javascript.мне не очень понятно.
Да и под него ещё и скрипт надо тянуть отдельный сверху.Можно его преобразовывать jsx в js на сервере, можно на клиенте (тогда подключаются скрипт-транслятор и text/jsx), можно сразу писать js, без использования jsx. Эти три варианта эквивалентны.
Читал статью в оригинале. «Шо то отличный фреймворк, шо это отличный фреймворк». Но, как мне кажется, Angular с лёгкостью выигрывает в удобстве использования в рамках как и больших, так и малых приложений. Интереснее было бы сравнение с Polymer, так как он уже намного больше похож на React.
Ну полимер это как бы всё же «чисто» веб компоненты. Никакого больше волшебства фреймворка в нём не происходит. Ангуляр предоставляет больше в данном случае. Сравнивать скорее надо polymer и директивы ангуляра, но опять таки одним лёгким движением руки директива попадает под полный digest cycle агуляра в большинстве случаев, и жить отдельно без него просто не в состоянии. Так что тоже сравнение с трамвайной ручкой получается.
В моём проекте ангуляр с лёгкостью проиграл реакту еще на стадии прототипирования.
Вброс засчитан. Чем проиграл?
Битвами с digest-loop-ами, чудовищной многословностью, нагромождением концепций (директива, контроллер, шаблон, резолвы и т.п. и т.д.) и всё это сразу. Когда на странице происходит сразу много всего, ангуляр начинает постоянно мешаться, а не помогать.
p.s. К тому же, у нас cljs и om был естественным решением :)
p.s. К тому же, у нас cljs и om был естественным решением :)
Вот именно, ангуляр полностью замодостаточен, дает все что нужно и при этом использовать его достаточно удобно (что бы не писали начинающие о некой его сложности), а теперь еще мифы о скорости развенчаны. Реакт не нужен, разве что для каких-то специфических вещей.
React нужен не для скорости, он нужен из-за компонентов. А вот HTML — пережиток прошлого, когда большая часть интерфейса была простым текстом, сейчас же гораздо больше активных элементов на странице, а данные изменяются локально, а не при перезагрузке страницы. Именно поэтому рождаются web-компоненты, именно поэтому Angular 2.0 их содержит. Поэтому шаблоны Angular содержат JS и различные байндинги, отсюда идея JSX (по сути, отказ от HTML). Да, JS тоже слабо подходит в качестве языка разметки, но зато в нем уже есть объекты ({{user.name}}), вызовы функций, математические, логические операции и т.д., которые давно используются во всех шаблонизаторах (т.е. по сути сообщество признало эти вещи декларативными).
Возможно, когда (или если) HTML разовьется в более полноценный язык разметки интерфейса, с поддержкой наследования, привязки данных и др., JS для этого станет не нужен, но может быть появится и что-то новое, как JSX, только без смешения парадигм и языков.
Возможно, когда (или если) HTML разовьется в более полноценный язык разметки интерфейса, с поддержкой наследования, привязки данных и др., JS для этого станет не нужен, но может быть появится и что-то новое, как JSX, только без смешения парадигм и языков.
> JSX (по сути, отказ от HTML)
Повеселили, по сути наоборот наоборот, возврат к спагетти коду (разметка html в коде, php style фейсбук ведь). Тогда уже и древние фреймворки называйте компонентными, там обычно уйма готовы виджетов (подобие компонентов).
Повеселили, по сути наоборот наоборот, возврат к спагетти коду (разметка html в коде, php style фейсбук ведь). Тогда уже и древние фреймворки называйте компонентными, там обычно уйма готовы виджетов (подобие компонентов).
Хотите готовые компоненты вам сюда:
react-components.com
Подскажите мне, пожалуйста, почему разметка в html-коде это плохо? Вот только не надо заливать про разделение ответственности. html-код в jsx это шаблоны, которые динамически изменяются в зависимости от поданных переменных. По сути каждый реактовый виджет это просто чистая функция, которой на вход подаешь данные, она тебе возвращает верстку. Так почему это плохо? Почему
это нормально, а в реакте использовать все возможности javascript для построения шаблонов плохо.
Как правило сами шаблоны не переиспользуются, а вот виджеты которые используют эти шаблоны переиспользуются, так зачем же их разделять?
react-components.com
Подскажите мне, пожалуйста, почему разметка в html-коде это плохо? Вот только не надо заливать про разделение ответственности. html-код в jsx это шаблоны, которые динамически изменяются в зависимости от поданных переменных. По сути каждый реактовый виджет это просто чистая функция, которой на вход подаешь данные, она тебе возвращает верстку. Так почему это плохо? Почему
<div>{{name}}</div>
это нормально, а в реакте использовать все возможности javascript для построения шаблонов плохо.
Как правило сами шаблоны не переиспользуются, а вот виджеты которые используют эти шаблоны переиспользуются, так зачем же их разделять?
> Подскажите мне, пожалуйста, почему разметка в html-коде это плохо?
Как раз разметка в html коде это не плохо, но там смесь JS и HTML (этот ваш jsx).
Что только не придумают лишь бы не использовать ангуляр.
Как раз разметка в html коде это не плохо, но там смесь JS и HTML (этот ваш jsx).
Что только не придумают лишь бы не использовать ангуляр.
Я, например, уже давно html не использую. MaskJS имеет более лаконичный синтаксис, поддерживает декларацию компонент, наследование, merge шаблонов, модули — импорт/экспорт компонент, scope компонент; загрузка данных, скриптов и стилей; друсторонний байндиг, и много всего другого.
Быстрый фреймворк — не тот, на котором можно сделать быстро, а тот, на котором нельзя сделать медленно :-)
Тут же я вижу описание костылей, которые нужно вставить, чтобы хотя бы догнать реакт.
Пример с таймаутом я так и не понял. В чём отличие первого кода от второго? Каким образом ручная реализация поведения $timeout поможет увеличить скорость?
Тут же я вижу описание костылей, которые нужно вставить, чтобы хотя бы догнать реакт.
Пример с таймаутом я так и не понял. В чём отличие первого кода от второго? Каким образом ручная реализация поведения $timeout поможет увеличить скорость?
Быстрый фреймворк — не тот, на котором можно сделать быстро, а тот, на котором нельзя сделать медленно :-)
Медленно можно сделать не только на любом фреймворке, но и на любом языке программирования.
Тут же я вижу описание костылей, которые нужно вставить, чтобы хотя бы догнать реакт.
Т.е. продуманное и правильное написание кода, вы считаете костылями? С каких пор добавление индекса — костыль?!
Пример с таймаутом я так и не понял. В чём отличие первого кода от второго? Каким образом ручная реализация поведения $timeout поможет увеличить скорость?
Тут в $digest() фишка. В данном случае биндинг не нужен.
Вопрос в том, насколько сложно сделать медленно :-)
Фреймворк должен упрощать написание кода, а не заставлять заниматься продумыванием каждой мелочи и не проглатывать исключения.
Где тут биндинг? $timeout всё, что делает — это вызывает отложенно функцию и запускает после этого $digest
Фреймворк должен упрощать написание кода, а не заставлять заниматься продумыванием каждой мелочи и не проглатывать исключения.
Где тут биндинг? $timeout всё, что делает — это вызывает отложенно функцию и запускает после этого $digest
Сделать медленно можно без проблем НА ЛЮБОЙ технологии, если знаете где это не так, буду благодарен узнать.
У меня были подозрения на то, что прелести реакт преувеличены. Было лень копаться, пока не назрело и всегда получалось простым анализом кода улучшить производительность приложения на ангулар до нужного уровня.
Я вижу здравое зерно в идее виртуального дома — тяжелые операции можно производить используя workers, т.е. паралельно основному потоку. Но насколько эта идея работает надо проверять.
Я вижу здравое зерно в идее виртуального дома — тяжелые операции можно производить используя workers, т.е. паралельно основному потоку. Но насколько эта идея работает надо проверять.
Начало статьи похоже на рекламу вроде «Шок! Всего 2 капли этого и....»
Правильно ли я понимаю что Ember со своими очередями и отложенным обновлением DOM это почти то же что и diff в реакте? Может кто-то растолковать?
главное преимущество diff/patch'а в том что не нужно реализовывать никакого шаблонизатора и при этом получить immediate mode api с возможностью сохранять внутреннее состояние.
апдэйты теоретически возможно сделать быстрее с техникой, которая используются в глиммере(на практике пока у них это как-то не особо получается), рендеринг новых компонентов будет медленее. Например в фэйсбуке гораздо важнее скорость рендеринга, тк основная операция — это переход между страницами, и при переходе нужно быстро удалить почти всю деревяшку и вставить новую.
апдэйты теоретически возможно сделать быстрее с техникой, которая используются в глиммере(на практике пока у них это как-то не особо получается), рендеринг новых компонентов будет медленее. Например в фэйсбуке гораздо важнее скорость рендеринга, тк основная операция — это переход между страницами, и при переходе нужно быстро удалить почти всю деревяшку и вставить новую.
По поводу «следующего проекта»: а куда в таком случае смотреть после backbone и голого jquery?
setTimeout(function() {
$scope.status.isSearching = false;
$scope.status.searchResults = ...
$scope.$digest();
.......
Серьезно?
Я этот спиппет буду скидывать народу, когда будут говорить о «простоте» ангуляра.
Да Реакт можно полюбить только за то что не приходиться писать такие магические вещи в коде, которые нигде не описаны. Лично у меня сразу возникло 100 вопросов в духе, а почему именно setTimeout а не $timeout и почему там должен быть $digest и почему он в setTimeout
Не спорю Агулярчик может быть неплох, если подпилить напильником, но он не ок по дефлоту.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Так ли быстр ReactJS?