Юрий Ярош

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

Адекватным способом решения этой проблемы является исспользование случайных префиксов/суффиксов в именах ресурсов, и изменение в последующих версиях.
Работает с коробки в yeoman и angular-generator. Таким образом не нужно полностью чистить кэш и блокировать сервер в момент деплоя. Максимум - подчистить кэш от index'a.

Nginx vs Apache... "Крайне неефективный способ управления проектами"
Какое отношение вэб-сервер имеет к средствам деплоя и управления проектов ?

Разберитесь нормально с nginx'ом - для статики он на много лучше.

В общем Angular деплоиться как и любой другой проект.
Портируете проект на Yeoman
Заводите Gitlab или хостите где-нить (github/bitbucket)
Пишите post-receive хук для Git на чём удобно
Деплой через git pull

ИМХО Node.js не подходит для типовых веб-проектов

"Новомодные" но ужасно нестабильные и сырые плюшки.
От версии до версии никакой обратной совместимости кроме как у "дефакто" решений
(читайте - прикладных утилит: yeoman, grunt, bower, stylus, sailsjs).
Баги фиксятся месяцами, а важные фичи могут внедрятся годами...
Сужу по backbone / angular / ember / meteor

Serverside JS не торт. Максимум - prerender фронтенда.
Сишные функции для оптимизации в node просто дикий шлак:
на вызов тратится больше времени чем на выполнение.

Вот из клиентского сейчас нормально работает Angular.
В остальных случаях проявляются "детские болезни" обратной совместимости (у Angular их меньше) и утечки памяти в браузере (хотел бы я что бы это была шутка).

"Java под вэб" это не страшный зверь, скорее игривый котёнок.
Не стоит обобщать и принимать все за чистую монету.
Не энтерпрайсом единным.

Поедание оперативки лечится offheap кэшированием модели, все остальное без проблем.

Серверная сишка это хорошо, но небезопасно и сложноподдерживаемо в долгосрочной перспективе.

Гляньте Grails если так страшно за порог вхождения.
Сам пишу на Play2, коим очень доволен.
Правда там ещё нужно использовать Jooq и liquibase.

Для отрисовки интерфейсов можно использовать ZK или Vaadin.

Java выучить можно за 2 недели, причём первого тома CoreJava будет достаточно для вэба.
JS тоже можно выучить на том же codecademy за 2 недели.

Android это вообще отдельная тема, его API никак не связано с вэбом.
Но и базовых знаний Java должно быть достаточно для освоения.
Можно почитать вот это.

p.s. почти мой шаблонный ответ на вопрос "а что учить после PHP?"

JS Rich-фронтед лучше потому что у клиента не перегружаются страницы и ресурсы - меньше трафика, быстрее скорость отклика.

Допустим можно сделать на Angular.js или Backbone и реализовать JSON RESTful API, для его документирования смотреть в сторону Swagger - есть привязки к tastypie. И проганять весь фронтенд на node.js через prerender.io что бы была у роботов возможность индексировать нормально страницы.

Вот "серверная или клиентская шаблонизация" тут уже было много-много холиваров.
Люди пытались писать гетерогенные шаблонизаторы которые исполняются и на сервере и на клиенте, Jade к примеру. Поддерживать такое бывает довольно сложно, но никто не запрещает попробовать. Поисковые роботы индексируют "без JS", либо гугл 2-3 раза в неделю "с JS", что собственно полная лажа для SEO. Я пошёл путём наименьшего сопротивления, сначала делал prerender в phantomjs, а потом вышел prerender.io и счастью моему не было придела.

Важно понимать что node.js в таком случае не резиновый, и при больших нагрузках важно обеспечить хорошее http кэширование - расстановку if-modified-since, и etag'ов. Для этого я использую специально допиленный кэширующий плагин nginx. Вообще поддержка http кэширования в rich frontend'ах сейчас очень больная тема. Её просто нет, и это вызывает много проблем.

В случае с С/C++ есть большая проблема - и это стандарты, читайте Шилдта 1, 2, 3, 4.
Qt лучше начать изучать с книг Макса Шлее, для получения навыков Qt не нужно быть гуру С++. Есть ещё Бланшет, но мне она не понравилась, и уже успела постареть.

Обязательно разберитесь с таким винигретом как Boost - там есть куча хаков для решения многих проблем самого языка. Для вас всякие SFINAE и constant cast'ы не должны быть проблемой. Есть ещё книжка "Священные знания" тоже можно почитать.

Не кидайтесь на Александреску и Страуструпа... Страуструп книги плохо пишет, а вот Александреску это PRO-уровень.

Я не пишу под форточки. Но как минимум нужно разобраться с WPF/WCF.

По jQuery ничего не могу сказать конкретного, разве что вот это можно пройти. Там же можно обучится многим вэб-полезностям.

Ещё было бы не плохо почитать на досуге по паттернах что-то: 1, 2
Для проверки навыков можно глянуть этюды: 1, 2, 3

По личному опыту реализации Rich-frontend'ов могу сказать что тут есть несколько важных моментов про которые частенько забывают - в backbone-подобных фреймворках часто наблюдаются утечки памяти при интенсивных загрузках / обновлении контента. Был опыт реалзизации проектов где "все в одном JS и html файлике" в буквальном смысле, с обновлением контента в реальном времени через socket.io... и там утечки памяти были основной проблеммой.

Пробовал knockout, ember, meteor, spine, backbone... но вот лучше всех себя в этом плане показал Angular, хотя принципы и скорость рендеринга в нем пока что оставляют желать лучшего. Есть на свете минимум 2-3 форка (ремейка) backbone которые призваны спасти своего прародителя от утечек.

Из истории: twitter как-то реализовал весь свой сервис подобным образом, через время им пришлось разбить все постранично, что бы форсировать сборку мусора.

Вот в rest интерфейсах меня больше всего сейчас волнует отсутствие нормальной поддержки http кеширования - поддержки тегов if-modified-since, и etags.
Из того что есть ... есть restangular и он очень сырой. Встроенный в angular resource модуль, пока очень сильно порезан, и ему конкретно не хватает фич, но для ваших задач должно хватить.

Не уверен что angular будет оправданным выбором в случае с single-page, возможно стоит взглянуть в сторону spine + handlebars / jade.

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