Сергей Протько

Переходите на es6 модули и babel.js. при разработке можно пересобирать только измененный файл а подгружать все через es6-module-loader (+ компилить все в один бандл для продакшена).

Для начала, MVC чисто UI-ая архитектура. Об этом как-то скучно, но если интересно почитайте про action-domain-responder

мы рассматриваем архитектуру клиент серверного приложения. У нас есть клиент (то что отдается браузеру + сам браузер) и сервер (то что обрабатывает запросы). С этой точки зрения как не посмотри у нас и там и там - два приложения. Разница может быть только в том, насколько они связаны.

Классический случай клиент-серверной архитектуры - single page application. С точки зрения WEB же частенько у нас клиента как такового почти и нет, почти всю роль клиента забирает браузер а на JS написаны разного рода украшательства и свистоперделки. Короче клиент и сервер сильно перемешаны (то есть сервер слишком много знает о клиенте).

На клиенте MVC позволяет из view работать с моделью через контроллер, который является эдаким промежуточным слоем, который разделяет view и model между собой. На сервере же, такой подход не жизнеспособен в большинстве случаев. Там поток данных идет строго вниз, запрос -> контроллер -> получение данных в контроллере (из сервисов или еще как) -> формирование представления данных (шаблонизация, сериализация, что угодно) -> отправка ответа. То есть из view возвращаться обратно в контроллер уже не хорошо, у него уже должно быть все что ему нужно, а всякие хелперы и утилиты - часть presentation layer. Иногда это неудобно и спасает HMVC, когда из view layer мы можем инициализировать запрос на другой контроллер, и тогда мы как бы не нарушаем цепочку и вроде как удобно.

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

алиасы?

Почему нужно так извращаться в Yii2?

Потому что люди могут.

Windows Store и не надо выдумывать.

читать книжки, больше кодить. Прочитал - попробовал.

это не название, вы явно задаете конструктор но у прототипа, что интересно. Зачем - а вот тут не скажу. Сейчас модно вообще пользоваться Object.create.

да что за народ то пошел... Если можно что-то в шаблонах делать то все пытаются там делать.

angular.module('app').filter('join', function () {
    return function (arr, glue) {
         if (!Array.isArray(arr)) {return arr;}
         return arr.join(glue);
    };
});

<strong>{{store.product.genres | join : ', '}}</strong>

так как не вижу смысла он и сам по себе уже шаблон.

Пока у людей пишущих на php появляются такие мысли, над php будут продолжать смеяться. Единственная причина по которой вы можете использовать php как шаблонизатор - возможность открывать и закрывать теги, отмечая зону действия скрипта. Причем уже довольно давно (лет так 8 точно) в цивилизованном мире принято использовать один открывающий тег на файл и даже не закрывать его. В целом PHP плохой шаблонизатор. Более того, недалек тот день, когда можно будет отключить вообще эти открывающие/закрывающие теги.

А как происходит дело в NodeJS ?

А никак, js это js, html это html. Хочется извращений - можно хранить все в js в виде строк и работать с ними. Но лучше всегда использовать шаблонизаторы. Это как минимум будет вас ограничивать в том, что можно пихать в шаблоны а что нет. В идеале запрос данных не должен происходить из шаблона выше по слоям, только вниз. Скажем концепции типа HMVC родились именно из этого ограничения, при этом мы не нарушаем правило, о том что поток данных идет сверху вниз вместо прямого обращения из view к логике.