## Первый тезис:

Полностью декларативный код не работает, всегда начинаются проблемы с расширением и выразительностью, и вместо простоты получается каша из костылей, где под каждый случай — кастомная хуета. С этим становится сложнее разбираться, поддерживать и работать.

Есть множество примеров где это не удалось:
1. Все исключительно декларативные валидаторы (в основном северные, типа встроенные в симфони2 валидаторы, или теже формы из симфони2, в каждой большой серверной хуете есть что то такое) показывают большие проблемы на хоть сколько нибудь сложных проектах.
2. Все исключительно декларативные шаблонизаторы становится использовать сложно, даже на проектах размером с twitterовскую веб морду (смотри mustache, да даже handlerbars, который "чуть менее декларативный" становится сложно использовать), из за тех же причин что описаны выше.

Есть альтернативная "реализация" декларативности — функциональное реактивное программирование, где по сути из композиции императивных (хотя подразумевается что они "чистые") функций собирается декларативное дерево изменения состояния.

Реакт – что то среднее. Он частично реализует ФРП, так как обладает вполне ограниченным flow (ну если без хаков) данных и соответственно детерменированностью обновления интерфейса, при этом позволяет декларативный подход к описанию интерфейса средствами JSX (аргумент про то, что JSX компилируется в императивный код — не аргумент. ВСЕ декларативные шаблонизаторы, валидаторы и прочее декларативное описание так или иначе компилируются в императивный код.)

Should component update это вещь, которая очень помогает с кэшированием, чего например лишены 3D движки. К чему 3D движки тут? Читай следующий тезис.

## Второй тезис:

Держать прямую связанность объектов и отображения, или полностью реактивная связанность почти всегда (за исключением редких случаев когда это у тебя входит в сам язык, в его свойства, и он умеет это оптимизировать (по разному) см. elm, haskell), на больших объемах всегда ДОРОЖЕ чем пересчитать дерево объектов интерфейса (не будем говорить про конкретно DOM в браузерах) полностью! Из за этого любой UI требующий большой скоростью (будь то отображение состояния игрового мира в игре, или быстро изменяющиеся графики в браузере) почти всегда пересчитываются с нуля! И это будет большой удачей и удобством, что бы ЕЩЕ дополнительно ускорить это за счет какого то слоя кэширования, который появляется исключительно из свойств используемой технологии. В реакте это — быстрые дифы (они не полные и достаточно быстрые) и shouldComponentUpdate, которые позволяют сказать браузеру, что надо обновлять, а что нет.

При этом реакт тебя не учит никакому псевдосинтаксису для итерирования, для логических выражений, и не вынуждает писать хаки для случаев когда тебе нехватает выразительности, надо сделать сложное условие, разделить код, при этом пробрасывая нужные данные. Ты просто пользуешься функциями и передаешь в них аргументы. Да тут ожидается что ты будешь писать "чистые функции", и немножко переучивать людей приходится, но зато это дает более просто тестируемый код, так что это улучшение которое полезно _не только для реакта_.

Никаких сомнений нет, в том что реакт заменится как нибудь на что нибудь более лучшее.

Извиняюсь за некоторую сумбурность мыслей, но еще работать как то надо, пойду поработаю.