Изменения

Почему React? Потому, что правильная концепция: а) JSX — это не круто б) он легковесный, там есть только компоненты и в) компоненты — это правильный вариант View в MVC/MVVM. По большей части, а "MC" там вообще нет ничего ни про модель, ни про контроллер, и уж конечно там нет никакого DI. И это прекрасно, потому что при наличии requirejs DI нафиг не нужен (Model-Componentдаже для тестов) фреймворк. Нет деления на V , а для реализации контроллеров и Cмоделей есть куча прекрасных вариантов, например, реактивные 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 просто сказал «нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?!» и тогда это ViewModelреализовал шаблонизацию прямо внутри кода на основном языке. Получилось нечто, немного напоминающее 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-repeatAngular 2: ngForKnockout: 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 работают (!) То есть изначально они же все вариации: контроллер, презентерпо сути, ViewControllerрешают одну и ту же задачу — всё это JS-шаблонизаторы на стероидах, ViewModel которые хотят при изменении входных данных менять вёрстку. Ангуляр и так далеепрочие к этой задаче подошли втупую, действительно написав по шаблонизатору, а реакт сказал «нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?» и просто встроили HTML в яваскрипт. Вроде контроллер Например, как сделать цикл? <pre>Ember: {{# each}}Angular 1: ng-repeatAngular 2: ngForKnockout: data-bind="foreach"React: ПРОСТО ИСПОЛЬЗУЙТЕ JS :) (обычный for или ViewModelArray.map())</pre> От синтаксиса шаблонов Angular 2 впечатление у меня вообще плохое. А на JSX оч удобно на самом деле писать и HTML-безопасно. По скорости тоже — Angular2 бесспорно гораздо лучше Angular1 (они его оптимизировали путём «обрубания лишних проводочков» — разделили явно 1-way и 2-way биндинги, большая часть у тебя всегда 1-way, поэтому стало всё сильно быстрее) должен обеспечивать заменяемость View, но реакт он всё равно не делает: 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), ну и сам язык немного странный, например отступы вместо фигурных скобок — наркоманство [[Категория:Разработка]]