Почему React — различия между версиями

Текущая версия на 17:59, 31 августа 2016

Почему React? Потому, что а) JSX — это круто б) он легковесный, там есть только компоненты и в) компоненты — это правильный вариант View в MVC/MVVM. По большей части, там вообще нет ничего ни про модель, ни про контроллер, и уж конечно там нет никакого DI. И это прекрасно, потому что при наличии requirejs DI нафиг не нужен (даже для тестов), а для реализации контроллеров и моделей есть куча прекрасных вариантов, например, реактивные Flux и Redux.

А почему компонент — это правильное View? Потому что он ставит крест на всех сомнениях, связанных с тем, нужен ли View свой отдельный контроллер, должен ли он «готовить» данные для View, должен ли он ставить обработчики событий или это должно делать само View… из которых растут ноги вариаций с ViewModel’ами, ViewController’ами, презентерами и так далее. Короче, мы все чётко знаем, где начинается View и где начинается Model, а вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, объединяя View со всем, что к нему относится (ViewModel, ViewController) и называя это компонентом. MVVM и MVWhatever резко сдуваются, а контроллер в MVC наконец начинает заниматься тем, чем должен — только обработкой «действий», полностью отвязанных от View. Концепция очень простая и понятная.

Что мне гипотетически немного не нравится в реакте — это некоторая излишняя «явная иерархичность». Проблема в том, что скорость рендера сильно зависит от иерархии компонентов, собственно, чем они мельче, тем лучше, ибо компонент — это и есть минимальная «единица» обновления. При обновлении компонент, по сути, перерисовывается целиком с поправкой на Virtual DOM — и хоть это, конечно, быстрее, чем тупо поменять ему весь innerHTML [:)], всё равно нет ничего хорошего в том, чтобы обновлять и diff’ать, например, всю таблицу при изменении одной строки. Поэтому кроме компонента «таблица» обязательно приходится делать ещё и компонент «строка таблицы». Хотя хз, может это зато заставляет писать более структурированный код.

В общем-то понятно, откуда всё это произрастает. Все новые фреймворки в каком-то смысле — просто JS-шаблонизаторы на стероидах, решающие задачу динамического обновления содержимого страницы при изменении входных данных. Angular, Ember, Knockout выбрали прямолинейный путь с реализацией собственных языков шаблонов и привязки их динамических частей к данным (каюсь, я сам хотел подобное сделать для своего шаблонизатора), а React просто сказал «нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?!» и реализовал шаблонизацию прямо внутри кода на основном языке. Получилось нечто, немного напоминающее PHP/ASP, только гораздо грамотнее, потому что используется только во view и поэтому не провоцирует на написание макарошек вместо кода.

Понятно, что при таком подходе код шаблонов не особо-то разберёшь на отдельные биндинги («что поменяется, если…»). Отсюда Virtual DOM и diff’инг, и отсюда же разбиение на мелкие компоненты. Зато сам код шаблонов писать УДОБНО и ПРОСТО. Например, цикл в разных фреймворках выглядит так (пример из статьи с аналогичными рассуждениями):

Ember: {{# each}}
Angular 1: ng-repeat
Angular 2: ngFor
Knockout: data-bind="foreach"
React: ПРОСТО ИСПОЛЬЗУЙТЕ JS :)

Кроме того, JSX оценят любители IDE, потому что в нём работает подсветка синтаксиса, подсказки и проверки типов.

А вот, кстати, как показывает библиотека Incremental DOM — Virtual DOM не так уж и обязателен, потому что скорость рендера в JS зависит не только от непосредственно количества операций, которые этот рендер делает, а также и от того, как много он гадит в память — чем больше объектов создаётся, тем чаще приходит GC (сборщик мусора) и тем меньше времени остаётся на собственно рендер. В итоге получается, что при быстром рендере и частом GC субъективное ощущение от производительности может быть хуже, чем при чуть более медленном рендере с редким GC.

Ещё заметка по поводу скорости других VirtualDOM’ов типа Bobril — многие из них, в отличие от React, не сохраняют вручную добавленные элементы.

Небольшая заметка по поводу событий в React: оно по ходу не просто оборачивает события, а зачем-то ставит обработчики на window и само их доставляет… в итоге если поставить глобальный нативный обработчик на document.body и react-овский обработчик на элемент — глобальный обработчик запускается ДО react-овского! (видимо, для производительности)

Ещё заметка: React можно юзать с SVG и даже с Canvas. Ну и с React Native, ага.

И ещё controlled/uncontrolled inputs.

А ещё есть вот такая штука https://facebook.github.io/draft-js/

Минутка юмора nodejs: globParent -> is-glob -> is-extglob

А я смотрел. Не штырит :) React выглядит гораздо аккуратнее и красивее архитектурно.

Вот соображения по поводу React, очень похожие на мои:

https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51

Мне понравилось как они это описали: все ангуляры, эмберы и нокауты, по сути, остались HTML-центричными (расширяют HTML с помощью яваскрипта), а React сделан JS-центричным (расширяет JS HTML’ем). В ангулярах и т. п. шаблон — это отдельный файл на отдельном языке, по сути, строковой литерал. А в React в JSX даже подсказки и проверки типов в IDE работают (!)

То есть изначально они же все, по сути, решают одну и ту же задачу — всё это JS-шаблонизаторы на стероидах, которые хотят при изменении входных данных менять вёрстку. Ангуляр и прочие к этой задаче подошли втупую, действительно написав по шаблонизатору, а реакт сказал «нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?» и просто встроили HTML в яваскрипт.

Например, как сделать цикл?

Ember: {{# each}}
Angular 1: ng-repeat
Angular 2: ngFor
Knockout: data-bind="foreach"
React: ПРОСТО ИСПОЛЬЗУЙТЕ JS :) (обычный for или Array.map())

От синтаксиса шаблонов Angular 2 впечатление у меня вообще плохое. А на JSX оч удобно на самом деле писать и HTML-безопасно.

По скорости тоже — Angular2 бесспорно гораздо лучше Angular1 (они его оптимизировали путём «обрубания лишних проводочков» — разделили явно 1-way и 2-way биндинги, большая часть у тебя всегда 1-way, поэтому стало всё сильно быстрее), но реакт он всё равно не делает: https://auth0.com/blog/2016/01/07/more-benchmarks-virtual-dom-vs-angular-12-vs-mithril-js-vs-the-rest/

По некоторым замерам только последние версии Ember.js чуть быстрее React’а, но опять-таки — это только из-за того, что там явно шаблон делится на «статические» и «динамические» части, которые описываются в разном синтаксисе.

По инструментарию тоже, подсказок по ВСЕМУ для React куча, поддержка IDE есть (я говорю, даже подсказки в JSX работают), поддержка инструментов разных — server-side rendering (кстати Netflix это юзает именно на React’е), hot reload, отладочный режим и даже профилировка. Даже тот же TypeScript можно юзать с JSX-вставками, если хочется, такое тоже есть.

А вот остальные компоненты, которые в Angular есть — ИМХО не особо нужны. DI и прочий мусор отлично берётся из внешних библиотек и есть стандартные решения. Собственно, сейчас вообще-то уже и ангуляровцы пришли к тому, что надо что-то реактивное для архитектуры юзать (store -> view -> action -> dispatcher -> store, строго в одну сторону), в итоге берут RxJS, Angular2+RxJS = 900 килобайт minified. В React же есть отличные Flux и Redux, которые тоже гораздо чище и проще RxJS. Redux = 6.7 Кб minified, RxJS = 150 Кб minified (потому что RxJS — это общая реализация реактивности, которую «натягивают» на архитектуру, а Redux — это именно априори state container). Тот же Redux позволяет очень легко таскать состояние между сервером и клиентом при server-side рендере, делать вариации «undo» и сохранять состояние при hot reload (это когда ты код обновляешь, а у тебя в браузер сама новая версия приложения подтягивается, при этом ОСТАВАЯСЬ НА ТОМ ЖЕ view).

Про DI я вообще не уверен, что он там нужен, потому что есть requirejs (через который хоть модуль делай, хоть сервис-синглтон), а для юниттестов есть jest, который эти модули автоматом все на mock’и заменяет.

Ну и собственные модули в Angular — тоже непонятно, нафига нужны, когда есть стандартный requirejs.

Анимации вообще делаются на CSS. Правда, если хочется, в React тоже для них компоненты есть.

Короче, мне в React нравится именно его архитектурная красота, архитектурная красота сопутствующих компонентов типа Redux, и отсутствие лишнего.

а почему нода? на ноде всякие прикольные темы можно мутить. асинхрон же. клёво типа.

собсно просто пишешь на js и понимаешь, что а нафига нужны все эти python, perl, php, WHATEVER, когда это по сути всё одно и то же и когда яваскрипт по сути покрывает фичи их всех?

причём он настолько нахватался фич со всех языков, что часть по-моему чуть не из C# взята. а для упоротых по статической типизации есть даже типизированный typescript (есть и другие язычки поверх яваскрипта, но ts самый живой) — то есть получается, что в принципе js чуть ли не вообще потребности ВСЕХ удовлетворяет

ruby какие-то там и т.п… нах всё это надо?

и система модулей адекватнее с самого начала и нет идиотских тяжёлых фреймворков, как в пхп — скопипащенных с java (типа Zend == Spring). то есть фреймворки-то есть, просто они сильно поприличнее, не вот это вот г..но

а composer php’шный скопипастен с npm. только разница в том, что в npm-то всё ок, а в php-то вся эта нереальная куча говна, поставленная с композера, будет инициализироваться каждый запрос заново, то есть априори будет тормозить. а в js — как в нормальных языках, инициализируется всё один раз… есть конечно phpdaemon (https://github.com/kakserpom/phpdaemon, у чувака емейл кстати как и ник — kak.serpom.po.yaitsam@gmail.com) — но возникает вопрос… а нахуа? если есть nodejs :)

и perl ноде тоже проигрывает: система модулей там, конечно, ок, и приложение нормально живёт (не один запрос), но

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

python поновее, с асинхронщиной чуть получше (есть twisted), но всё-таки менее популярный и система модулей тоже на костылях (virtualenv), ну и сам язык немного странный, например отступы вместо фигурных скобок — наркоманство