Переход с PHP на …?

В гугле не забанен, но может расскажете в двух словах, почему предлагаете эти технологии?

crizis, они действительно другие язык, функциональщина, асинхронность, совсем другой опыт

Ну очень вкратце.

Scala это Java, но с продуманным, современным синтаксисом, асинхронный подход, продвигающий функциональное программирование. В довесок вы получаете совместимость со всеми Java либами. Единственный минус — Java VM.

NodeJs, опять же асинхронный подход, не обычная OOP модель (прототипная), возможность применять один код как на серверной стороне так и на клиентской. Минусы, на мой взгляд, асинхронность сыровата, не так много библиотек, скорость.

Так же можете посмотреть в сторону Go с Revel фреймворком. Правда последователи языка Go, называют Revel — неверным, но мне было легче знакомится с чем-то, что работает по MVC. Минус, (субъективный) Go другой язык в котором нет OOP, но есть сахар для структур, нет try-catch, где-то медленнее Java (правда память ест в разы меньше).

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

Я не считаю, что лучше чем-то одним заниматься, но для выбора нового инструмента всё-таки решил спросить аргументов. Тем более, что речь не о простом изучении документации, а о разработке вполне конкретного веб-приложения. Пока на основе комментариев склоняюсь всё-таки к Ruby + RoR — исключительно в силу большой компонентной базы, которая позволит решить поставленную задачу + по верхам пройдусь по языку, а где-то, вероятно, нужно будет разобраться поглубже.

Как позвольте разработка на ноде поможет в разработке на PHP? В PHP не так уж и много асинхронных операций, там разве что с сокетами можно работать через select/epol.

Даже с mysql уже можно работать ассинхронно, есть ещё pntl, мультикурлы, в 5.5 появились генераторы
Есть очереди.
Кроме ассинхронности, ещё учишься стоить конвееры из функций, вместо ООП стиля, что очень здорово при кэшировании или AOP.
Да и другие фреймворки и организация их апи — это всегда хорошо.

Разумеется, я смотрел и на то и на другое. И я, безусловно, с удовольствием освоил бы оба этих инструмента.

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

В таком случае, не думаю что комментарии здесь сильно повлияют на Ваше решение. Может быть только подтолкнут к отказу от XSLT :)

От него можно отказаться только в том случае, когда он не поддерживается инструментом, на котором идёт разработка. В случае же с PHP я не могу придумать причины, по которой я не захотел бы с ним работать, или полноценной замены. Ну да речь сейчас не об этом. :)

1) валидация всегда происходит на сервере. Даже если она дублируется на клиенте, то на сервере она всеравно должа быть. Компоненты для валидации есть и в руби, и в PHP и в питоне, так что по этому пункту без разницы на чем писать.

2) не HEAD запросы, а держать через WebSockets соединение и в реалтайме обмениваться актуальными данными с минимальными задержками. Тут к слову не все однозначно. NodeJS хорош, но там нету доступа к API самих сокетов, только через обертку. В итоге для простого обмена данными все хорошо, но если серверная логика уже посложнее и ограничения ноды не позволяют достаточно оптимизировать все, стоит уже использовать Python (есть опять же куча готовых серверов и оберток) и руби (туда же), под которые можно написать очень оптимизированные push-сервера под ваши нужды. PHP тут на последнем месте в виду отсутствия других механизмов паралельной обработки соединений помимо select.

3) Restfull api — тут вообще плевать что выбирать из предложенных вариантов.

Будущее за нормально построенными клиент-серверными приложениями, stateless серверами, но никак не за JS. JS это один из вариантов, и там не все так просто.

1)Валидация, очистка — и на сервере и на клиенте. Я не говорил, что клиентом нужно ограничиваться
2)Websockets — да, будущее, но еще не настоящее. IE9.

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

согласен golang интересен во всех аспектах

На основе комментариев всё-таки склоняюсь к Ruby. Странно, кстати, что ни одного адепта Python для участия в данном опросе не появилось. Очень жаль.

Спасибо за совет.

Ещё один язык для написания TCP Hello World?

Эм… Зачем мне ссылка на мануал?