aen

По сути разницы нет. AppRouter из марионетки просто позволит вам указать контроллер, который будет обрабатывать ваши роуты. То есть вы сможете вынести логику обработки роутов в отдельную сущность и ей манипулировать.

У марионетки нет серверного рендеринга, потому говорить о изоморфных приложениях не приходится. Вам на бекенде надо реализовывать REST API, а с роутами разберется сама марионетка.

Есть вот такой канал тыц и есть вот такая серия статей тыц.
А еще есть гайд, который еще не дописан. Тыц.
А можно еще в гиттер зайти, там всегда помогут. Тыц.

Представления (виды) имеют свой контейнер. Div это или иной тег, решать вам, для этого есть свойство `tagName`, которое по умолчанию как раз таки равно `div`. Так же полезно будет упомянуть и про свойство `className`, благодаря которому вы сможете задать значение атрибута `class` для своего представления. Используйте эти два свойства. Если у вас в шаблоне есть какой-то корневой контейнер, то именно его и надо описать этими свойствами.

А регион в DOM-дереве это просто контейнер, куда можно что-то вывести.

PS: если приведете пример, то я попробую его исправить.

https://github.com/rajdee/redux-in-russian

Попробуйте использовать не $, а this.$ при поиске по селектору. Во втором случае поиск будет вестись внутри this.$el представления, которое к моменту вызова коллбека onShow еще не вставлено в DOM, а потом ваши селекторы $( ".cols-div" ), $('.drag-el-container .col-div') не срабатывают.

childView - это ссылка на класс, а не на инстанс. Уберите new.

Все зависит от того, как вы организовали каскад представлений. Допустим у вас есть некоторое LayoutView с парой регионов. Вы можете сначала его отрендерить, а потом уже рендерить представления внутри регионов. Тогда вам нужно будет ловить момент рендеринга вьюх в каждом регионе. Но если вы будете использовать хук onBeforeShow(), внутри которого пропишите рендеринг вьюх в регионе, то вам нужно будет ловить момент рендеринга только LayoutView, так как оно вставится в DOM одним куском вместе с вложенными представлениями.

В plumber же можно передать функцию-обработчик ошибки. Пробовали?

Вам нужно один раз только синхронизировать время на сервере и на клиенте. Какой смысл его постоянно передавать? Один раз получили смещение, запомнили, а потом в запросах просто учитываете это смещение.