@jsunderhood Хорошее объяснение тут gist.github.com/staltz/868e7e9… . Еще полезно глянуть этот спич youtube.com/watch?v=DqMFX9…
Действительно интересно почитать. Кстати gist от создателя cycle.js.org @andrestaltz twitter.com/__fro/status/6…
Но даже в простейших примерах FRP прослеживается главный его недостаток: необходимость учитывать время, даже там где это не нужно.
Поэтому "FRP как архитектура всего приложения" не очень хорошая идея на мой взгляд. Для анимаций, наверное, самое-то.
Хорошие абстракции должны изолировать время и асинхронность.
В React/Flux архитектуре время изолируется в хранилищах вместо того, чтобы утекать в UI. UI — отображение определенного момента времени.
Redux от @dan_abramov реализует управление состоянием лучше чем Flux: вместо изменяющегося состояния есть "рецепт как изменить состояние"
Что, кстати, уже снова близко к FRP, но есть чувство что там это оправдано: где-то время нужно учиывать. Главное делать это контролируемо.
Возможно последний твит это все-же результат моего непонимания FRP (или понимания? :-)
Следующий шаг в управлении изменяющемся состоянии это CRDT структуры данных где порядок операций значения не имеет. Прячет время ещё дальше