Юрий Ярош

node --v8-options | grep "in progress"

В принципе есть поддержка es6 модулей через --harmony флаг, но лучше использовать полифилы или SystemJS.

Если вы упоротый рубист, стоит реализовать сервер на основе
faye/faye-websocket-ruby или imanel/websocket-ruby с воркерами на sidekiq. В качестве окружения я лично предпочитаю JRuby. Ещё я видал как люди гоняли рубисткий sock.js. Я даже не представляю почему у него популярность ниже того же socket.io, а поддержка в разы лучше.

Также обязательно нужно написать fallback на Server-sent events и long polling.
Хотя можно вообще на заморачиваться с websocket'aми - его может будет достаточно, и для чатов с большим количеством народу производительность у него будет выше чем у Websocket'ов.

А так, в соседней вселенной, я обычно использую Vert.x и местный sock.js с откатом на sse.

Atom / Sublime обычно покрывает все потребности.
Хотя для вёрстки часто использую Brackets.
Сейчас занимаюсь портированием работы с PSD'шками с Brackets в Atom - не нравится как работает Avocode в Atom'e.

Если используется deflate - смысла пережимать нету.
Можно поиграться с JSZip, но это создаст дополнительную нагрузку.
Если хотите создать эффективный протокол - лучше использовать protobuf.

На стороне сервера в процессе сборки и упаковки.
Обычно использовал gulp-angular-templatecache и gulp-jade соответственно.

Когда люди называют 1Гбит динамического http трафика highload'ом - это вызывает у меня довольно нелепую ухмылку.

Сравнивать php / python / ruby более-менее целесообразно так как это полностью интерпретируемые языки с кэшированием байткода, иногда с оптимизациями, как в случае с jRuby и Project Graal. Обычно такие вещи помирают на 14-17К запросов в секунду с пустыми ответами... В общем на одном гигабите трафика тут обычно всё и заканчивается. Node.js по производительности более корректно сравнивать с JVM языками типа Groovy или Scala, но никак не с самой Java. На практике через Netty на Disruptor'е под offheap'ом и Terracotta можно пропустить и 40Гбит живого трафика, без статики, - главное правильно профилировать и писать прямо pfRing.

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

Если вы хотите строить что-то действительно стоящее - стоит смотреть в сторону CQRS-ES'a и реактивных приложений в рамках SOA. Возможно внедрение микросервисных архитектур если нет требований к задержкам на выполнение запросов. Но, учитывая что вы задаёте здесь вопросы о том "что лучше node.js или python" не думаю что у вас хватит опыта для построения подобных вещей.

Можно пробовать golang - яндекс слез с python'a на golang по причине слоупочности оного, и довольно хорошо так слез. В golang'е сейчас самый лучший RAD, гораздо круче того же node.js. Идеоматичность самого языка решает достаточно много потенциальных проблем ещё на этапе разработки. Да и сообщество сейчас довольно активно пилит его runtime - внедряют многопоточный gc и ещё пару вкусностей. Даже не умея всех этих асинхронностей и прочей лабуды с golang'ом можно получить довольно хороший выхлоп. Правда меня немного смущает отсутствие нормальных datamapper'ов и scaffolding'a под golang.

Вопрос очень плохо сформулирован, не ясно какую задачу нужно реализовать подобным образом.
Берём и читаем как настраивается rewrite в nginx'е и Apache.

Если нужна асинхронность и push-нотификации в РНР - проще уж прикрутить ворекров для очередей типа Gearmand / Beanstalk.