aen

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

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

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

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

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

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

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

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

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

Если коротко, то "быть". Это вам позволит избежать кучи граблей, на которые наткнетесь при разработке.

upd: Вот вам подборка для изучения https://github.com/instanceofpro/awesome-marionette

Если вам нужно, чтобы ваша коллекция работала и была доступна всегда, то нет никакого смысла хранить ее в модуле, в котором есть что-то еще. Она отдельная сущность, доступ к которой вам нужно организовать через шину событий, которую вам даст Backbone.Wreqr.

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