Как я перестал беспокоиться и полюбил React

[@Fesor]

Супер набор… а, это перевод…

[@xGromMx]

По поводу быстроты React. Это не та фича на которой стоит акцентировать свое внимание blog.500tech.com/is-reactjs-fast

[@serf]

Был доклад какой-то по angular 2, там в демках реакт сильно проиграл angular 2, в котором принципиально переработаны многие вещи.

Но вообще если реакт не быстр, то зачем он вообще такой громоздкий и не особо удобный нужен.

[@xGromMx]

Посмотрите на jsblocks.com

[@serf]

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

ps 2к звезд на гитхабе, серьзено, а я не слышал даже о jsblocks раньше.

[@Fesor]

Все дело в концепции. Скажем как бы я не любил Angular, он потворствует плохим решениям (во всяком случае первая версия). Кто не видел deep-watch-ей в контроллерах? Кто не видел в принципе ватчей в контроллерах? Или еще веселее — в сервисах. Или кучи условий в шаблонах и т.д. Некоторые в шаблоны логику выборок пихают и т.д.

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

Что до «доклад какой-то», были доклады где реакт рвал ангуляр первый на рендринге таблиц за счет виртуального DOM, но добавление track by в ng-repeat меняло ситуацию в другую сторону (виртуальный DOM добавляет свои накладные расходы, но позволяет не париться, а ангуляр надо оптимизировать зная как меняются данные, что не круто но эффективнее).

[@Imbolc]

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

[@Imbolc]

Не, это о другом. Да, в райот можно на сервере отрендерить хтмл. Но этот хтмл никак ни синхронизируется с вашим клиентским js. А реакт рендерит на сервере, а потом на клиенте подхватывает состояние. Гляньте хтмл отрендеренный реактом, там айдишники в каждом теге как раз для этого.

[@nuit]

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

[@k12th]

У вас есть вся мощь JavaScript для описания пользовательского интерфейса: циклы, функции, скоупы, композиции, полноценный язык шаблонов.

Ага, а почему бы просто не взять полноценный язык шаблонов? Собственно, в Ractive так и сделали, в результате код отдельно, разметка отдельно, виртуальный DOM есть.

[@xGromMx]

Не знаю как Ractive, но сейчас быстые обороты популярности набирает этот фреймфорк(который еще и позволяет использовать его на server side) jsblocks.com

[@Arilas]

Это чем он оборот набирает? Тем что он представляет собой класический RFP без какой либо очереди изменений? Он вообще ничего не привнес нового, все уже было. Берем задачу, изменить 1000 элементов на странице, во время правок, нам нужно (допустим) делать синхронный запрос на сервер, что мы получаем? Правильно, юзер видит незаконченные данные на странице. Виртуальный DOM лучше обычной идеи «ячеек» тем, что он позволяет применять правки практически мгновенно, после всей логики, которая выполняется.

[@Arilas]

FRP, опечатался)

[@xGromMx]

Уж если FRP c VDOM то есть вот такой проект github.com/staltz/cycle и его альтернатива с React github.com/pH200/cycle-react

[@Imbolc]

А что, jsblocks может полноценный пререндеринг на сервере? В их seeds ничего такого не видно.

[@lega]

Чем он хорош? Используется observable подход — а это шаг назад (когда надо двигаться в сторону Object.observe), для получения значений используется оператор «with», что очень не рекомендуется и снижает производительность.
Добавил его в простой бенчмарк.

[@nwalker]

почему бы просто не взять полноценный язык шаблонов?

Потому что он не нужен.
Он все равно скомпилируется все в тот же JS, но при этом у него будет довольно ущербная семантика с костылями и медсестрами.
Это дополнительные усилия, дополнительные абстракции и дополнительное время на обучение. Зачем?

[@k12th]

А, то есть JSX не компилируется в JS с костылями и медсестрами.

[@nwalker]

JSX это очень чистый синтаксический сахар без своей семантики. Он транслируется в JS один-в-один, предельно прямолинейно, костыли и медсестры предоставляются JS.

[@Quilin]

Про Knockout.js:

Откуда ViewModel должна получить свое состояние? Откуда она знает что модель изменилась? Интересные вопросы.

Ну, а ответы на них почему не даны? Исходники открытые. Я понимаю, что статья про реакт, но немного провокационно получается упомянуть нокаут и сделать вид, что там что-то непрозрачно и непонятно.

Computed-property вычисляются при своей инициализации и биндятся на все прочие ko.observable и ko.computed, которые были вызваны при этом вычислении, если что.

[@aldefalco]

В «реакте» смущает и напрягает гибридность кода и верстки. Очень часто верстка меняется а значит нужно переписывать каждый раз код. Так?

[@KIVagant]

Если Facebook запилил это под свои задачи, то у них смена вёрстки явно не слишком частое явление. Видимо, они жертвуют универсальностью в пользу скорости.

[@k12th]

Просто почаще говорите себе (и другим), что JSX — это не разметка в джаваскрипте. Многим помогает (вот сейчас в комменты набегут).

[@Aetet]

Нет, не нужно, если уметь его готовить. Если верстка часто меняется то можно выделять компоненты, что-то типа:

<Navigation>
  <ClickableNavlink />
</Navigation>

<Navigation>
  <NotSoClickableNavlink />
</Navigation>

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

[@Sunify]

«Верстка» и есть код.
Аргументация реакта такая — разделение на «логику [отображения]» и «шаблоны» — это разделение технологий, а не отвественности. Ответственность у них одна — отображать интерфейс. Мешать бизнес-логику в компоненты, конечно же не стоит.

[@KIVagant]

Воспоминание о 2 проблемах с перерендериванием целого приложения при смене состояния?

Прошло.

Говорение автора русский язык вот так? Нормалды.

[@nuit]

Таким образом React способен вычислить минимальное количество изменений, необходимых для обновления DOM.

React Reconciliation

Generating the minimum number of operations to transform one tree into another is a complex and well-studied problem. The state of the art algorithms have a complexity in the order of O(n3) where n is the number of nodes in the tree.
…
Since an optimal algorithm is not tractable, we implement a non-optimal O(n) algorithm...

[@serf]

Ай да ладно никому кроме фейсбука не нужен этот React, пиар не поможет.

[@a_l]

Вы серьёзно?

[@serf]

Не совсем серьезно.

Видимо фейсбук им доплатил :)

[@StreetStrider]

Использую Mithril. В основе лежит та же идея Virtual DOM. Нареканий нет, пока всё нравится.

[@nuit]

исходники мифрила — наглядный пример того как не стоит писать на жаваскрипте. Самая корявая и тормозная реализация виртуального дома из всех существующих.

[@StreetStrider]

Ага, это правда, там и кривовато и недостаток абстракций. Но в интерфейсном плане отличная либа.