Изменения

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

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

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

В общем-то понятно, откуда всё это произрастает. Все новые фреймворки, по сути, в каком-то смысле — JS-шаблонизаторы, решающие задачу динамического обновления содержимого страницы при изменении входных данных. Angular, Ember, Knockout выбрали прямолинейный путь с реализацией собственных языков шаблонов и привязки их динамических частей к данным, а React просто сказал «нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?!» и реализовал шаблонизацию прямо внутри кода на основном языке. Получилось нечто, немного напоминающее PHP/ASP, только гораздо грамотнее, потому что не провоцирует на написание макарошек вместо кода. Понятно, что при таком подходе код шаблонов не особо-то обратишь. Отсюда Virtual DOM и diff'ингdiff’инг, и отсюда же разбиение на мелкие компоненты. Зато сам код шаблонов писать УДОБНО и ПРОСТО. Например, цикл в разных фреймворках выглядит так (пример из [https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51 статьи] с аналогичными рассуждениями):

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