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

Материал из YourcmcWiki
Перейти к: навигация, поиск
м
м
 
(не показано 15 промежуточных версий этого же участника)
Строка 1: Строка 1:
−
Почему React? Потому, что а) JSX и б) это правильный вариант View (в MVC/MVVM?). По большей части, там вообще нет ничего про модель или контроллер, есть только компоненты. То есть, он не ограничивает вас в выборе реализации контроллера и модели. Почему это правильно? Потому, что в части контроллера, связанной с View, всегда куча вопросов, начиная с того, нужен ли вообще отдельный контроллер для каждого View? Должен ли он подавать на вход View готовые проецированные данные для элементов или полную модель? Должен ли контроллер ставить обработчики событий на элементы View? Отсюда все вариации с ViewModel’ами, ViewController’ами, презентерами и так далее. Короче, мы все чётко знаем, где начинается View и где начинается Model, а вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, объединяя View со всем, что к нему относится (ViewModel, ViewController) и называя это компонентом. Концепция очень простая и понятная.
+
Почему React? Потому, что а) JSX — это круто б) он легковесный, там есть только компоненты и в) компоненты — это правильный вариант View в MVC/MVVM. По большей части, там вообще нет ничего ни про модель, ни про контроллер, и уж конечно там нет никакого DI. И это прекрасно, потому что при наличии requirejs DI нафиг не нужен (даже для тестов), а для реализации контроллеров и моделей есть куча прекрасных вариантов, например, реактивные Flux и Redux.
  
−
Что мне гипотетически не очень нравится в реакте — это некоторая излишняя «явная иерархичность». Проблема в том, что скорость рендера сильно зависит от иерархии компонентов, собственно, чем они мельче, тем лучше, ибо компонент — это и есть минимальная «единица» обновления. При обновлении компонент, по сути, перерисовывается целиком с поправкой на Virtual DOM — и хоть это, конечно, быстрее, чем тупо поменять ему весь innerHTML [:)], всё равно нет ничего хорошего в том, чтобы обновлять и diff’ать, например, всю таблицу при изменении одной строки. Поэтому кроме компонента «таблица» обязательно приходится делать ещё и компонент «строка таблицы». Хотя хз,
+
А почему компонент — это правильное View? Потому что он ставит крест на всех сомнениях, связанных с тем, нужен ли View свой отдельный контроллер, должен ли он «готовить» данные для View, должен ли он ставить обработчики событий или это должно делать само View… из которых растут ноги вариаций с ViewModel’ами, ViewController’ами, презентерами и так далее. Короче, мы все чётко знаем, где начинается View и где начинается Model, а вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, объединяя View со всем, что к нему относится (ViewModel, ViewController) и называя это компонентом. MVVM и MVWhatever резко сдуваются, а контроллер в MVC наконец начинает заниматься тем, чем должен — только обработкой «действий», полностью отвязанных от View. Концепция очень простая и понятная.
  
−
В общем-то понятно, откуда всё это произрастает. Все новые фреймворки, по сути, в каком-то смысле — JS-шаблонизаторы, решающие задачу динамического обновления содержимого страницы при изменении входных данных. Angular, Ember, Knockout выбрали прямолинейный путь с реализацией собственных языков шаблонов и привязки их динамических частей к данным, а React просто сказал "нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?!" и реализовал шаблонизацию прямо внутри кода на основном языке. Получилось нечто, немного напоминающее PHP/ASP, только гораздо грамотнее, потому что не провоцирует на написание макарошек вместо кода.
+
Что мне гипотетически немного не нравится в реакте — это некоторая излишняя «явная иерархичность». Проблема в том, что скорость рендера сильно зависит от иерархии компонентов, собственно, чем они мельче, тем лучше, ибо компонент — это и есть минимальная «единица» обновления. При обновлении компонент, по сути, перерисовывается целиком с поправкой на Virtual DOM — и хоть это, конечно, быстрее, чем тупо поменять ему весь innerHTML [:)], всё равно нет ничего хорошего в том, чтобы обновлять и diff’ать, например, всю таблицу при изменении одной строки. Поэтому кроме компонента «таблица» обязательно приходится делать ещё и компонент «строка таблицы». Хотя хз, может это зато заставляет писать более структурированный код.
  
−
Понятно, что при таком подходе код шаблонов не особо-то обратишь. Отсюда Virtual DOM и diff'инг, и отсюда же разбиение на мелкие компоненты. Зато сам код шаблонов писать УДОБНО и ПРОСТО. Например, цикл в разных фреймворках выглядит так (пример из [https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51 статьи] с аналогичными рассуждениями):
+
В общем-то понятно, откуда всё это произрастает. Все новые фреймворки в каком-то смысле — просто 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>
 
<pre>
Строка 12: Строка 14:
 
Angular 2: ngFor
 
Angular 2: ngFor
 
Knockout: data-bind="foreach"
 
Knockout: data-bind="foreach"
−
React: JUST USE JS. :)
+
React: ПРОСТО ИСПОЛЬЗУЙТЕ JS :)
 
</pre>
 
</pre>
  
−
Правда, как показывает библиотека Incremental DOM — Virtual DOM не так уж и обязателен, потому что скорость рендера в JS зависит не только от непосредственно количества операций, которые этот рендер делает, а также и от того, как много он гадит в память — чем больше объектов создаётся, тем чаще приходит GC (сборщик мусора) и тем меньше времени остаётся на собственно рендер. В итоге получается, что при быстром рендере и частом GC субъективное ощущение от производительности может быть хуже, чем при чуть более медленном рендере с редким GC.
+
Кроме того, 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), ну и сам язык немного странный, например отступы вместо фигурных скобок — наркоманство

Источник — «https://yourcmc.ru/wiki/index.php?title=Почему_React&oldid=11153»