vasIvas: это называется "маркетинг". Вообще то что вы описали это классическое MVC, где вью и модель связано обзервабл связью (не совсем события в контексте реакта, в ангуляре эту задачу обрабатывают байндинги, за реакт говорить не берусь). И да, этой штуке уже 35 лет.
vasIvas: события это плохо, и давайте не будет начинать холивар. Для игрушек и там где состояние системы можем меняться асинхронно много раз в секунду события хорошо, для приложений события это не так удобно и разработчики предпочитают явный поток данных в одну сторону.
jack3d: можно настроить изолированный скоуп и передавать туда данные. Пример сделать не выйдет так как ngModel создает свой изолированный скоуп и в этом случае у вас единственный способ запросить какие-то выражения - это $parse.
как уже ответили выше - parse это не eval, это крайне изолированная штука которая работает только в том контексте который вы ему предоставили. В этом плане $parse очень даже безопасен.
Назар Мокринский: вот только с flex-direction: colum такое сделать не выйдет. Во всяком случае я сходу не могу придумать как это можно сделать таким образом. Ладно еще row + flex-wrap но и то будет не совсем такой результат так как последний ряд растянется.
Никита Гущин: я так же обычно все делаю на angular, но так как у меня обычно не сайты мне проще. В большинстве случаев это какие-то внутренние приложения, а если надо что бы фронтэнд индексировался - добавляется один простенький httpInterceptor который говорит phantomjs-у когда запросы заканчиваются, после чего phantom ждет окончания $digest циклов и рендрит страницу. Естественно есть готовые реализации этого всего.
Что до backbone/jqyery + twig - давно уже не видел и счастлив. И да действительно удобнее и проще.
Никита Гущин: что значит MV** "плохо показало"... MV** означает что можно так и эдак, MVC, HMVC, MVVM... на ваш выбор. От MVVM Angular2 судя по всему отказывается в пользу православного HMVC.
vasIvas: хз, я не парюсь и использую angular + phantomjs на случай поисковиков. У меня не настолько медленно стартует фронтэнд пока что бы нужно было сервер-сайд рендрингом страдать, хотя конечно полезно было бы.
vasIvas: справедливости ради стоит заметить, что если смотреть под этим углом, то разница между server-side рендрингом для react и для angular только в производительности первого - сгенерить строку проще чем отрендрить DOM. В общем и целом все примерно одинаково, можно спокойно поставить какой phantom.js на сервак и не париться. Но это если для поисковиков.
Для конечного пользователя профит от server-side рендринга - он мгновенно получит страницу, а пока он тупит и смотрит на нее проинициализируется само приложение и плавненько так статическая страничка станет динамической.
vasIvas: грубо говоря у вас reactjs все так же будет общаться с апишкой написанной на laravel или хоть на баше, просто вместо браузера будет node.js который будет продьюсить html, который уже будет грузиться на клиент и там реакт уже подхватит то состояние которое выплюнул сервер и продолжит работать как ни в чем не бывало.
В случае поисковиков просто будет продьюситься готовый HTML который можно индексировать.
Единственное что придется сделать правила машрутизации, скажем все запросы вида /api пихаем на laravel а все остальные на ноду которая будет генерить html.
