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

require.js + r.js для сборки, или LMD, или еще какой менеджер зависимостей.

Вообще angular поддерживает ленивую подгрузку, так что соблюдать порядок не обязательно. Если же вам нужно все скрипты добавить, что бы избавить себя от рутины, то можно просто добавить в шаблон index.html конструкцию scripts.forEach, и передавать туда все доступные скрипты.

Так же посмотрите на ngbuild

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

Reactphp + libevent, и готов ваш маленький node.js. Смысла в этом на самом деле не так много, только если у вас слишком много кода на php, который нужно использовать, но и тут есть решения. Зависит от задачи.

В плане эффективности асинхронных штуковин - эффективнее взять golang.

Можно конечно. Как делать - зависит от задачи. Можно просто сделать так, что бы нода слушала все запросы на конкретный порт, но это имеет свои недостатки в случае если нужно и статику отдавать. Можно поставить проксирование запросов через какой nginx например, что бы статику отдавал он, а все остальное обрабатывала уже нода.

А что будет если не успеет JS? Из описанного вами, издержки на доставку данных будут в десятки раз привышать издрержки на вычисления. Для начала стоит понять что setInterval не гарантирует того, что функция будет вызвана именно через одну секунду, там тоже будут свои флюктуации в силу однопоточности JS. Как с этим бороться, сходу не подскажу, все зависит от логики приложения.

10 000 одновременных запросов к серверу (именно отдельных запросов, а не через WebSockets) могут положить небольшой сервер. Для этого существует нагрузочное тестирование.

TCP гарантирует отсутствие потери данных, собственно по этому в реалтаймовых штуках TCP используется только в случае, если UDP дает большую потерю пакетов (например UDP трафик режется или что-то в этом духе). То есть когда сервер отправляет пакет, от откладывает его в буфер до подтверждения его получения клиентом. Если сервер в течении определенного времени не получает по ICMP подтверждения о том что пакет был отправлен, он заново начинает отправлять весь буфер. Когда буфер полон - новые пакеты вы отправить уже не можете пока не освободится, насколько я помню, хотя бы половина. В реалтайме же вас не должна смущать ситуация с потерей пакетов (если данные помещаются в один пакет конечно), так как у них не так много времени, что бы нести "актуальные данные". проще послать следующий пакет. чем переотправлять уже не актуальные данные. Но WebSockets не работают с UDP.

ситуацию на рынке труда можно погуглить. При желании работой себя можно обеспечить.

Что до node.js - на рынке труда очень востребован javascript, от того серверный он или на клиенте разницы не так много. Более того, node.js может вам пригодиться для организации своей инфраструктуры и т.д. Скажем в описанном вами кейсе со сборкой статики для проекта на php вам никто не мешает поставить node.js для сборки, настроить и иметь свой профит. У меня на проектах для сборки фронтэнда всегда используется gulp/grunt + куча плагинов + livereload, и это не мешает мне писать на php. Админки я сейчас вообще стараюсь делать как single-page-apps так что тут вообще отдельное приложение целиком на js+restfull api на php.

Да и с экосистемой в php все довольно хорошо, особенно последние пару лет. Скажем я не могу сходу сказать есть ли у Composer явные минусы по сравнению с pip/bundler/bower/npm. Создавался он все же с оглядкой на все грабли, через которые прошли и pip и easy-install и npm и т.д. Думаю виной тому использование инструментов среднего качества, обратите внимание на серьезные решения аля Symfony2/Zend2/Silex.

Ну и да, расширяйте кругозор. Стало скучно писать на php - попишите на node.js. В целях обучения - сделайте какой инструмент для организации своей работы, или что еще. Когда почувствуете уверенность - найдите проект на ноде и балуйтесь. Всегда нужно пытаться привносить какое-то разнообразие в работу.

1. Удалять товары в категориях тогда, когда вы удаляете только категорию, это не хорошо. Я просто обычно выкидываю товары из данной категории и в большинстве случаев отправляю их в архив. Уведомить пользователя о том что что-то такое произошло довольно сложно, да и он сам это обнаружит когда обновит страницу ибо эти товары просто пропадут из корзины. А можно написать что мол "извините, этого товара больше нету". Либо через websockets, раз уж у вас все на node.js.

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

чем это dependency injection и deferred objects в контексте js необычны?

А так пишите конечно, но постарайтесь раскрыть все по подробнее, зачем применять то и то и профит от этого. Описать inversion of control в js, особенностях там всяких... примеры... Статья туториал как писать это не так интересно, тут скорее статья разбор готового приложение с подробным описанием этих практик. Ну и что бы люди могли на реальном примере посмотреть.

Передача файла всеравно происходит двумя способами: отправка формы в скрытом iframe (или же просто отправка формы), или же XMLHttpResuest2. Ну и за этим всем обычный HTTP POST. И все... А все остальное - это разработка UI, контролов и т.д. И да, реализаций подобных море.

1) зависит от того чем вы будете заниматься. Если верстка то как минимум встретите дроби и возможно когда-нибудь дорастете до простенькой тригонометрии (анимации, трансформации и т.д.). Так же тригонометрия может пригодиться при работе с canvas, webgl и т.д. Есть еще audio api с дискретными рядами фурье, свертками, фильтрами (справедливо и для canvas, как как обработка изображений на клиенте так же есть). Словом математику знать полезно, но обычно проблема решается по мере ее поступления. Если будете работать с этим часто то все придет со временем. Если же нет - то и учить смысла особо нету, главное умение разбираться.

2) Это проблема системы образования. Отсутствия желания заинтересовать абитуриента/студента в том, что знания ему могут пригодиться. В итоге учатся все спустя рукава и бывает узнают о том что предмет был полезным и в перспективе интересным уже после окончания этого курса а то и вообще университета. Те же ряды, индегралы и т.д. применяются при обработке сигналов, а стало быть аудио, видео и просто изображений. Делать там фильтрики для инстаграмма на клиенте... все такое прочее. Это как пример.

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