Почему React — различия между версиями
м |
м |
||
(не показано 17 промежуточных версий этого же участника) | |||
Строка 1: | Строка 1: | ||
− | Почему React? Потому, что это правильный вариант View | + | Почему 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’инг, и отсюда же разбиение на мелкие компоненты. Зато сам код шаблонов писать УДОБНО и ПРОСТО. Например, цикл в разных фреймворках выглядит так (пример из [https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51 статьи] с аналогичными рассуждениями): | ||
+ | |||
+ | <pre> | ||
+ | Ember: {{# each}} | ||
+ | Angular 1: ng-repeat | ||
+ | Angular 2: ngFor | ||
+ | Knockout: data-bind="foreach" | ||
+ | React: ПРОСТО ИСПОЛЬЗУЙТЕ JS :) | ||
+ | </pre> | ||
+ | |||
+ | Кроме того, 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 в яваскрипт. | ||
+ | |||
+ | Например, как сделать цикл? | ||
+ | |||
+ | <pre> | ||
+ | Ember: {{# each}} | ||
+ | Angular 1: ng-repeat | ||
+ | Angular 2: ngFor | ||
+ | Knockout: data-bind="foreach" | ||
+ | React: ПРОСТО ИСПОЛЬЗУЙТЕ JS :) (обычный for или Array.map()) | ||
+ | </pre> | ||
+ | |||
+ | От синтаксиса шаблонов 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), ну и сам язык немного странный, например отступы вместо фигурных скобок — наркоманство | ||
+ | |||
+ | [[Категория:Разработка]] |
Текущая версия на 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), ну и сам язык немного странный, например отступы вместо фигурных скобок — наркоманство