Изменения

Почему React? Потому, что а) JSX — это круто б) он легковесный, там есть только компоненты и в) компоненты — это правильный вариант View в MVC (или /MVVM?). Который, по По большей части, не MVCтам вообще нет ничего ни про модель, а "MC" (Model-Component) + внешний ни про контроллер , и уж конечно там нет никакого DI. И это прекрасно, потому что при наличии requirejs DI нафиг не нужен (даже для тестов), а для реализации контроллеров и моделей есть куча прекрасных вариантов, например, Dispatcher в случае реактивные Fluxи Redux. А почему компонент — это правильное View? Потому что он ставит крест на всех сомнениях, связанных с тем, нужен ли View свой отдельный контроллер, должен ли он «готовить» данные для View, должен ли он ставить обработчики событий или это должно делать само View… из которых растут ноги вариаций с ViewModel’ами, ViewController’ами, презентерами и так далее. Короче, мы все чётко знаем, где начинается View и где начинается Model, а вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, объединяя View со всем, что к нему относится (ViewModel, ViewController)и называя это компонентом. MVVM и MVWhatever резко сдуваются, который занимается а контроллер в MVC наконец начинает заниматься тем, чем должен — только обработкой действий «действий», полностью отвязанных от View. Концепция очень простая и обновлением моделейпонятная. Внутри самого React нет деления  Что мне гипотетически немного не нравится в реакте — это некоторая излишняя «явная иерархичность». Проблема в том, что скорость рендера сильно зависит от иерархии компонентов, собственно, чем они мельче, тем лучше, ибо компонент — это и есть минимальная «единица» обновления. При обновлении компонент, по сути, перерисовывается целиком с поправкой на V Virtual DOM — и Cхоть это, конечно, быстрее, чем тупо поменять ему весь innerHTML [:)], всё равно нет ничего хорошего в том, чтобы обновлять и diff’ать, например, всю таблицу при изменении одной строки. Почему Поэтому кроме компонента «таблица» обязательно приходится делать ещё и компонент «строка таблицы». Хотя хз, может это правильнозато заставляет писать более структурированный код. В общем-то понятно, откуда всё это произрастает. Все новые фреймворки в каком-то смысле — просто JS-шаблонизаторы на стероидах, решающие задачу динамического обновления содержимого страницы при изменении входных данных. Angular, Ember, Knockout выбрали прямолинейный путь с реализацией собственных языков шаблонов и привязки их динамических частей к данным (каюсь, я сам хотел подобное сделать для своего шаблонизатора), а React просто сказал «нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования? Потому!» и реализовал шаблонизацию прямо внутри кода на основном языке. Получилось нечто, немного напоминающее PHP/ASP, только гораздо грамотнее, потому что деление используется только во view и поэтому не провоцирует на самомнаписание макарошек вместо кода. Понятно, что при таком подходе код шаблонов не особо-то деле искусственноеразберёшь на отдельные биндинги («что поменяется, если…»). Мы все чётко знаемОтсюда Virtual DOM и diff’инг, где Viewи отсюда же разбиение на мелкие компоненты. Зато сам код шаблонов писать УДОБНО и ПРОСТО. Например, цикл в разных фреймворках выглядит так (пример из [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, потому что в нём работает подсветка синтаксиса, подсказки и все чётко знаемпроверки типов. А вот, где Modelкстати, как показывает библиотека 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 ----- А я смотрел. То ли правильное View отражает состояние модели Не штырит :) React выглядит гораздо аккуратнее и красивее архитектурно. Вот соображения по поводу React, очень похожие на мои: https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51 Мне понравилось как они это описали: все ангуляры, эмберы и нокауты, по сути, остались HTML-центричными (общаясь расширяют HTML с ней напрямуюпомощью яваскрипта), то ли всё состояние должен проецировать контроллер а React сделан JS-центричным (расширяет JS HTML’ем). В ангулярах и т. п. шаблон — это отдельный файл на отдельном языке, по сути, строковой литерал. А в React в JSX даже подсказки и тогда проверки типов в IDE работают (!) То есть изначально они же все, по сути, решают одну и ту же задачу — всё это ViewModelJS-шаблонизаторы на стероидах, которые хотят при изменении входных данных менять вёрстку. Ангуляр и прочие к этой задаче подошли втупую, действительно написав по шаблонизатору, а реакт сказал «нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?» и просто встроили HTML в яваскрипт. Например, как сделать цикл? <pre>Ember: {{# each}}Angular 1: ng-repeatAngular 2: ngForKnockout: 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 (это когда ты код обновляешь, презентера у тебя в браузер сама новая версия приложения подтягивается, ViewControllerпри этом ОСТАВАЯСЬ НА ТОМ ЖЕ view). Про DI я вообще не уверен, ViewModel что он там нужен, потому что есть requirejs (через который хоть модуль делай, хоть сервис-синглтон), а для юниттестов есть jest, который эти модули автоматом все на mock’и заменяет. Ну и так далеесобственные модули в Angular — тоже непонятно, нафига нужны, когда есть стандартный requirejs. Вроде контроллер  Анимации вообще делаются на CSS. Правда, если хочется, в React тоже для них компоненты есть. Короче, мне в React нравится именно его архитектурная красота, архитектурная красота сопутствующих компонентов типа Redux, и отсутствие лишнего. ----- а почему нода? на ноде всякие прикольные темы можно мутить. асинхрон же. клёво типа. собсно просто пишешь на js и понимаешь, что а нафига нужны все эти python, perl, php, WHATEVER, когда это по сути всё одно и то же и когда яваскрипт по сути покрывает фичи их всех? причём он настолько нахватался фич со всех языков, что часть по-моему чуть не из C# взята. а для упоротых по статической типизации есть даже типизированный typescript (или ViewModel) должен обеспечивать заменяемость Viewесть и другие язычки поверх яваскрипта, но по факту 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), ну и сам язык немного странный, например отступы вместо фигурных скобок — наркоманство [[Категория:Разработка]]