React препятствует задачам упрощения разработки уже сейчас и задачам по улучшению производительности в ближайшей перспективе.
Первое (по сути не имеет отношение, но позволяет понять последовательность и глубину комплексного подхода к решению проблем): архитектор заявляет что любит javascript и всякие выдуманные синтаксисы использовать не любит. Предлагает использовать JSX. OK
Второе: что важно отметить это то, что разработчики вводят в заблуждение, заявляя что реакт - декларативный.
По настоящему декларативный инструмент позволяет анализировать ожидаемый результат и делать оптимизации для его получения. Такими инструментами можно назвать SQL (во множестве случаев) или запросы в datomic. В реакте же невозможно программно проанализировать от каких состояний зависит та или иная часть DOM дерева, какое состояние может его кардинально поменять и т.д. В реакте декларативен только результат выполнения функции render(), но это не очень интересно потому что он меняется в зависимости от состояний.
В связи с этим react не знает как конкретно DOM связан с данными поэтому они выполняют дорогие сравнения virtual dom (Ради решения этой проблемы они предлагают использовать immutable)
Третье: отдельно отмечены архитектором react
После этого вдруг, откуда ни возьмись, неожиданно и несправедливо, без объявления войны, с вертушки выясняется что счётчик непрочитанных сообщений показывает неверное число.
Решение проблемы радикально: выкинуть MVC подход и использовать flux, который позволяет немного систематизировать ручное обновление данных.
Уже сейчас, в результате отказа от настоящей декларативности, умышленного отказа от наблюдения/реакции на изменения данных для реакта стоновится проблемой производительность и помощь в организации кода.
Уже сейчас и в ближайщем будущем фиктивная декларативность препятствует другой задачи, которую ставят перед собой архитекторы react: эффективное взаимодействие с сервером. Есть graphql, но запросы разработчик должен писать сам, хотя они могли бы генерироваться автоматически - используемую структуру данных нетрудно вычислить из шаблонов.
По настоящему декларативные шаблоны (а не так как в реакте - тысячи генерируемых на лету деклараций DOM дерева).
Из которых понятны взаимосвязь с данными. А значит можно выполнять атомарные изменения-реакции в DOM на изменения данных без промежуточных шагов. На основе которых можно построить все варианты состояний DOM, благодаря чему анализировать css и делать приоритезацию тяжелых, влияющих на reflow/repaint изменений.
Когда браузер понимает как будет меняться DOM он может сделать много крутых оптимизаций.
Взаимосвязи между данными описываются декларативно. Структуры взаимосвязей данных, а также используемые в шаблонах структуры склеиваются.
Для основных объектов приложения у сервера спрашивается:
"У нас тут в приложении есть статьи такой-то структуры. Как бы эффективно у тебя, сервер, забирать статьи и всё что с ними связано?"
{
props: ['full_text', 'date'],
related: {
author: {
props: ['firstName', 'lastName'],
related: {
avatarUrl: ['url', 'width', 'height']
}
}
}
}
А сервер такой говорит: "ну ты можешь запрашивать посты и получать такую структуру по этому url /api/135H49VXUHN/"
Приложение когда надо запрашивает /api/135H49VXUHN/24234234?author.avatarUrl.width=320&author.avatarUrl.width=240. Сервер отвечает
Сервер складывает вместе одинаковые стукруры об эффективности которых просят разные клиентские приложения. Складывает и мониторит - какие структуры создают большую нагрузку на сервер и показывает их программисту. А программист либо отключает структуруры (клиент получает редирект на структуры попроще) либо начинает жестко оптимизировать их, добавлять индексы, улучшать алгоритмы.
Это кардиранольное улучшение разработки может быть выполнено в атоматическом режиме, для этого шаблоны должны быть декларативными как и взаимосвязи между состояниями моделей и сервером.