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

Если вы используете HTTP2 - то не обязательно, но это врядли.

если загрузить асинхронно 10 файлов по 100кб то это будет быстрее чем один 1МБ файл

А если загружать по 80 файлов по 10кб то это будет медленнее чем 10 файлов по 100кб, так как расходы на установление соединения будут больше чем время ожидания доставки очередной порции данных.

Браузер делает запросы за ресурсами паралельно (можете в дебагере браузера посмотреть, там же информация о том кто блокирует загрузку), так что загрузка нескольких файлов будет быстрее загрузки одного большого. Но, даже с учетом keep alive, браузер не может реюзать полноценно при таком раскладе соединения, и он будет их плодить в большом количестве, и чем больше их, тем больше нагрузка на сервер, тем медленнее будет получаться статика. Так что нужно найти баланс.

Я бы предложил разделить все на:
- angular.js
- vendor.bundle.js - все сторонние модули и прочее
- app.bundle.js - все файлики приложения.

тогда да. асинхронная загрузка будет быстрее.

что бы быть full stack вы должны понимать что происходит на каждом уровне вашего приложения. от кнопочек которые вы верстаете, до того как обрабатываются запросы на сервере, в плодь до взаимодействия с базой данных через все прослойки.

Вне зависимости от выбранного языка или фреймворка, принципы остаются примерно те же. С Symfony мы можем говорить о гексагональной архитектуре, луковой архитектуре, data mapper и т.д. С nodejs мы тоже можем обо всем этом говорить но там не особо развиты идеи data mapper (на данный момент). Приходится жить с active record или dbal. Ну и опять же управление зависимостями в js и в php по разному организованы, хотя суть (dependency inversion) остается той же.

Единственный совет дам - не распыляйтесь. Старайтесь не переключаться между фронтэндом и бэкэндом слишком часто, это уменьшит скорость обучения. Большая часть знаний в принципе спокойно мигрирует из одной сферы в другую, так что не переживайте.

Для начала разберитесь с принципами объектно-ориентированного и функционального программирования. Штуки вроде "почему высокая связанность кода это плохо, зачем нужны MVC и т.д."

Паралельно можете поразбираться с типичными шаблонами проектирования под js: largescalejs.ru

Ну и еще - ES2015, активное использование модулей и штук вроде jspm/webpack для сборки. По сути все проблемы в js - кривое управление зависимостями (вся соль ООП в принципе состоит в инверсии зависимостей, функциональные подходы делают все еще лучше). Сейчас ситуация с этим всем намного лучше чем была скажем еще года 4 назад.

Опять же, когда речь идет о реально больших проектах, следует перестать писать на каждый чих свой велосипед. Нужна библиотека для организации маршрутизации - берем готовую. Нужно работать с датами - берем moment.js и т.д. Сборщики вроде того же jspm умеют выдерать из популярных библиотек то что можно (если можно так сделать, скажем с angular2 выдрать только нужные модули можно. а вот с angular1 нет).

Нужно ли знать русский язык чтобы написать этот вопрос?

Конечно нужно, вы же будете на JS писать. Фреймворки дают вам только инфраструктуру, это второстепенная часть приложения, хоть и бывает так что она занимает 95% приложения.

Нужно знать и понимать:
- основные конструкции, циклы, условия и т.д.
- функции, контекст вызова функции, скоупы
- объектная модель в JS, представление о том какие типы данных в JS есть и что все есть объект
- прототипное наследование
- event loop или асинхронность в контексте javascript-а.
- было бы неплохо годик попрактиковаться прежде чем делать кому-то проекты.

А еще было бы неплохо знать HTTP, базы данных и прочие радости жизни.

теряем возможность работы с куки и сессиями

Ну не совсем, с куками вы все так же можете работать и через куки хранить сессии, другое дело что это в 99% не нужно. А токены - JWT решает все проблемы.

не очень удобно и не привычно работать с JS MVC

Привыкните, учитывая то что JS MVC это то, чем должно быть MVC.

сео оптимизация

Тут есть варианты:
- гугловский краулер поддерживает JS нынче, на счет остальные не вкурсе.
- генерация снапшетов (phantomjs например) и Ajax crawling
- server-side рендринг, актуально при втором пункте.

везде нужно тягать токен туда сюда

Большая часть фреймворков делают это прозрачно для разработчика, так что это то же самое что туда-сюда тягать куки.

и к нему можем написать клиент на любом php фраэмворке в классическом виде

Почитайте про гексагональную архитектуру, например. HTTP API и классический WEB UI это лишь два интерфейса к одной и той же логике, которая инкапсулирована в сервисы. Разница лишь в том, как DTO из сервисного слоя будет юзаться для формирования представления (будь то json или html).

https://www.youtube.com/watch?v=ajhqScWECMo - вот вам посмотреть на досуге.

читается как "Примени вызов функции (которая хранится в этом свойстве) с таким контекстом вызова и такими аргументами"

Далее гуглить что такое контекст вызова.

Самый простой и, на мой взгляд, правильный способо - директивы. Вы можете изолировать все что связано с одним постов внутри директивы.

<x-single-post post="post" ng-repeat="post in posts"></x-single-post>

Внутри этой директивы вы можете уже выводить комментарии, у вас есть доступ к самому посту и т.д. Проблему со спиннерами можно решить через сервисы - передавать делегат директивы внутрь другой... или общаться через контроллеры... тут уже масса вариантов, кому как больше нравится.

Если вы используете angular 1.4 то директива будет выглядеть как-то так:

function singlePostViewDirective () {
    return {
        templateUrl: 'post.template.html',
        bindToController: {
            data: '=post' 
        },
        controller: function () {
             var vm = this;
             vm.addComment = function (comment) {
                 // do stuff
             }
        },
        controllerAs: 'post'
    }
}

ну и в шаблоне будет что-то в духе

<form ng-submit="post.addComment(commentText)">
<textarea ng-model="commentText"></textarea>
<input type="submit" />
</form>

Ну можно еще на директивы подробить, тут как вам удобнее. Скажем форму добавления комментария можно в еще одну директиву запихнуть, которая будет только управлять UI и делигировать через колбэки само сохранение на уровень выше... Соль в том что бы разбить все на директивы соблюдая принципы единой ответственности и уменьшая между ними связанность (конечно надо соблюдать баланс, иначе для простой задачи можно нагородить много чего лишнего), тогда будет меньше боли.

Да, именно так, на момент вызова console.log колбэк еще не отработал. Добро пожаловать в callback hell. Альтернативы:
- промисы, позволяют уменьшить вложенность колбэков
- корутины - сложно но можно писать асинхронный код в синхронном стиле, повторюсь это сложно
- async/await - еще не запилили в js.

для чего нужны директивы

Для всего. Директивы дают вам инструмент, позволяющий изолировать элементы UI-я в самодостаточные компоненты, расширять HTML, добавлять новые элементы со своим поведением, расширять поведение имеющихся элементов новыми атрибутами... Директивы ангуляра послужили прообразом стандарта о web-компонентов, это очень гибкая штука, которая позволяет полностью избавиться от выборок элементов и навешивания на нее логики, за счет чего код сильно упрощается.

где их применять

Везде где только можно, весь UI следует строить на иерархии директив, как если бы вы просто верстали. Я бы даже сказал что использовать только контроллер, как например можно увидеть в примерах для ngRoute/uiRouter и шаблон - это плохо, контроллеры и шаблоны использовать можно, но только для того что бы определить какие в рамках этого роута/стэйта будут использоваться директивы и передать туда параметры. То есть по максимуму все запихивать в директивы. Правда это может быть первое время сложно делать, потому лучше постепенно увеличивать степень дробления UI на директивы. Главная сложность сделать так, что бы директивы были независимы от контекста использования. Ну или явно определить этот контекст (параметр require директивы может определять что директива A может быть использована или должна быть использована только в контексте B). Ну и еще по началу может быть сложно определиться что должно быть в link и что должно быть в контроллере, должен ли вообще у директивы быть link или контроллер.

ng-inject

вы про галповский плагин или все же про ng-include? если последнее, как комбинация ng-include + ng-controller, то это тип... для ленивых. При помощи этих двух директив мы можем создать какой-то элемент, присобачить ему поведение и шаблон, да, но оно не будет изолированным, реюзать такое уже не выйдет. Если это вам надо временно, и вам лень - то можно и так, но лучше сделать полноценную директиву, тогда ее можно будет реюзать в рамках проекта и устранить дублирование. Ну и опять же, вариант с ng-include+ng-controller можно покрыть только E2E тестами, что не удобно. Директивы же просто и удобно покрываются юнит тестами, что делает поддержку системы намного проще и дешевле.

в каком виде правильно и разумно применять директивы

Посмотрите на polymer, это то чем должны были бы стать директивы а ангуляре (и в angular2 оно почти так), там больше ограничений и более понятно как использовать web-компоненты и как следствие - директивы.